از طریق منوی جستجو مطلب مورد نظر خود در وبلاگ را به سرعت پیدا کنید
چگونه وب سایت خود را برای سرعت بهینه سازی کنیم، و چرا هنوز باید
سرفصلهای مطلب
چگونه وب سایت خود را برای سرعت بهینه سازی کنیم، و چرا هنوز باید
از زمان ایجاد اینترنت، اندازه متوسط فایل ها به طور پیوسته در حال رشد بوده است. چیزی که با کیلوبایت شروع شد به مگابایت (بله، جمع) پیشرفت کرده است، و فایلهای ما همچنان در حال رشد هستند. اگرچه این پدیده در نگاه اول نگران کننده نیست، اما تاثیری که دارد روی عملکرد و قابلیت نگهداری افتضاح است. دستگاههای قدیمی، محدودیتهای پهنای باند یا به طور کلی سرعتهای آهسته را اضافه کنید و مشکل بسیار بزرگتری خواهیم داشت. خوشبختانه، ما نه تنها بر اندازه فایلهایمان، بلکه بر روش نمایش صفحاتمان در مرورگر نیز کنترل داریم. این نوع کنترل به توسعه دهندگان وب مانند خودمان این فرصت را می دهد که به رفع این مشکل کمک کنند و کد ما را برای عملکرد بهتر در بهینه سازی کنند. process.
چرا زحمت؟
زمانی که این روزها اکثر اتصالات اینترنتی در ایالات متحده نسبتاً سریع هستند، من کاملاً عدم علاقه را درک می کنم. منظورم این است که اگر همه چیز در حال حاضر خوب کار می کند، چرا زحمت بکشیم؟ عملکرد و بهینه سازی بیشتر از سرعت دانلود محتوا است. همچنین با صرف زمان برای مشاهده کدهای ما، مزایای سئو و UX زیادی وجود دارد. ناگفته نماند، کاهش اندازه فایل ها با بهینه سازی کد ما برای عملکرد بهتر، امتیاز اضافی کاهش هزینه های پهنای باند ما به عنوان میزبان، و کاهش استفاده از پهنای باند را دارد (به ISP/کاه داده های سلولی فکر کنید) روی سطح کاربر نیز
ماژولار فکر کردن اولین قدم است
کد ماژولار معمولاً bloat را در قالب گزینه های بیشتری اضافه می کند. در اینجا، ما میخواهیم ماژولار را از نظر ترکیب هرچه بیشتر قطعات رایج کدمان در نظر بگیریم. اگر بتوانیم دو کلاس CSS را در یک کلاس ترکیب کنیم و از کد کمتری برای ارائه همان نتیجه استفاده کنیم، باید. وقتی صحبت از HTML و CSS اولیه می شود، ماژولار بودن آنقدر مهم نیست، اما وقتی وارد دنیای پیچیده تر جاوا اسکریپت می شوید، نفخ بیش از حد می تواند به شما آسیب برساند – به خصوص روی سیار.
HTTP و درخواست های وابستگی را به حداقل برسانید
درخواست های وابستگی تا حد زیادی بزرگترین عامل در کاهش سرعت بیشتر هستند page سرعت های بارگذاری هر درخواست اضافی bloat و لایه دیگری از پیچیدگی را به تجزیه و دانلود اضافه می کند process. فراموش کردن این موضوع که فراخوانی تصاویر از شیوه نامه شما نیز بسیار آسان است، اغلب آسان است، بنابراین حتماً آنها را محدود کنید و در صورت امکان از روش های بهینه سازی جایگزین مانند sprites یا SVG استفاده کنید. در حالی که ما هستیم روی موضوع وابستگی های خارجی، اگر وب سایت شما به اندازه کافی بزرگ است که حداقل به چند ده درخواست نیاز دارد… ممکن است زمان آن رسیده باشد که از CDN استفاده کنید. استفاده از CDN برای توزیع محتوای شما اندازه فایل و/یا زمان بارگذاری را به اندازه حذف درخواستهای اضافی HTTP با هم کاهش نمیدهد، اما احتمالاً میتواند اتصالات کند سرور را حداقل از معادله حذف کند.
مبانی کد محیط تولید در مقابل توسعه
هنگام مقایسه پایه های کد توسعه و سطح تولید شما باید تفاوت بسیار فاحشی وجود داشته باشد. انجام این مرحله به تنهایی گاهی اوقات می تواند بیشترین کاهش را در اندازه فایل ها در سراسر صفحه مشاهده کند. امروزه معمول است که ببینیم توسعهدهندگان به محیط «تولید» یا «توسعه» خود اشاره میکنند روی پروژه های در مقیاس بزرگ اما این نیز مفید است روی پایان کوچکتر چیزها نیز. بزرگترین تفاوت بین این دو محیط را می توان با فشرده سازی تصویر و کوچک سازی/فشرده سازی کد مشاهده کرد. در پایان، ما میخواهیم محیط تولید ما تا حد امکان نازک و سریع باشد در حالی که محیط توسعه ما باید یکسان باشد، فقط منهای بهینهسازی فشردهسازی تصویر/کد. استفاده از ابزارهای داخلی مانند فشرده سازی “Save for web” فتوشاپ می تواند نقطه شروع خوبی برای تصاویر باشد. انبوهی از دانش وجود دارد در جای دیگر کاوش کرد و همچنین با مکالمات روی فرمت های تصویر، الگوریتم های فشرده سازی، کنترل کیفیت و بهترین شیوه ها. برای کد، بهترین استفاده از فشرده سازی معمولا بستگی دارد روی زبانی که با آن کار می کنید همچنین این که فشرده سازی کد به افرادی که سعی در درک کد شما دارند کمک می کند یا به آنها آسیب می رساند، بسیار قابل بحث است، اما این یک مکالمه برای زمان دیگری است. وقتی صحبت از HTML و CSS ساده می شود، از خدماتی مانند استفاده می کنم کمپرسور html گوگل و کمپرسور YUI برای CSS
کد هوشمندتر و خواناتر بنویسید
گاهی اوقات همان کدی که می نویسیم کندترین حلقه در زنجیره است. CSS ناکارآمد یا جاوا اسکریپت متورم می تواند به بارگذاری بیشتر از آنچه فکر می کنید آسیب برساند. این موزیلا پست به جزئیات زیادی در مورد اهمیت نوشتن انتخابگرهای ناب CSS و توضیح اینکه مرورگرها چگونه آنها را ارائه می دهند، می پردازد. به طور خلاصه، نوشتن مسیر دقیق در زنجیره ای از انتخابگرها بسیار کمتر از استفاده ساده از کوچکترین انتخابگر قابل شناسایی منحصر به فرد به جای آن است. هر دوی آنها استایل را به یک عنصر هدایت می کنند، دومی به سادگی کار را بسیار بسیار سریعتر انجام می دهد. جاوا اسکریپت می تواند حتی بدتر از CSS ضعیف باشد و در بسیاری از موارد به راحتی نادیده گرفته می شود. چند بار یک کتابخانه JS خارجی را بدون نگاه کردن عمیق به خود منبع، در پروژه خود کپی و جایگذاری کرده اید؟ Typekit مثال فوقالعادهای از این موضوع است، زیرا وقتی سرورهای آنها متوقف میشوند، میتوانند یک صفحه وب را با استفاده از فونتهای خود به زانو درآورند و باعث 30 ثانیه یا حتی دقیقه زمان بارگذاری اضافی شوند. خوشبختانه، چنین رویدادهایی به ندرت اتفاق میافتند، اما همچنان تمرین خوبی است که در صورت امکان، جاوا اسکریپت را آخرین بار فراخوانی کنید، همانطور که در مورد Google Analytics چنین است. انجام این کار به مرورگر اجازه میدهد تا فایلهای اصلی (CSS، درخواستهای HTTP و غیره) را تجزیه کند و نشانهگذاری را نمایش دهد، قبل از اینکه جاوا اسکریپت شروع به کاهش سرعت کند.
HTML را بسیار ساده نگه دارید
در راستای هدف ما برای نوشتن انتخابگرهای CSS نازکتر و به حداقل رساندن نفخ، نوشتن HTML کارآمد نیز باید در اولویت باشد. تنظیم مجدد CSS اغلب هدف قرار می گیرد همه عناصر مشترک و اجرای یک ظاهر طراحی “تنظیم مجدد”. روی آنها را بنابراین حتی اگر آن div اضافی را هدف قرار نمیدهید، احتمالاً با حداقل بازنشانی padding و margin، سرعت کار را کاهش میدهد. به طور معمول، یک یا دو div اضافی واقعاً به چیزی آسیب نمی رساند. فقط زمانی که با ده ها نفر از آنها پایان می دهید، همه چیز دیوانه می شود. با معرفی عناصر بیشتر در مشخصات HTML5، در این زمینه نیز انعطاف پذیری بسیار بیشتری داریم.
وقتی ما کد پاکتری مینویسیم، گوگل آن را دوست دارد
گوگل این را در اولویت قرار داده است که اینترنت را به صورت جمعی شکل دهد. به منظور اشغال موقعیت های برجسته در نتایج جستجوی خود، اکنون صفحات باید به بسیاری از ویژگی های مختلف در مورد روش ارائه آنها توجه جدی داشته باشند. فراخوانی بیش از حد منابع خارجی، داشتن تصاویر غیرمعمول بزرگ، یا حتی داشتن جاوا اسکریپت ضعیف می تواند رتبه سایت را پایین بیاورد. خوشبختانه، همه اینها با نیت خوب است زیرا الزامات آنها برای رتبه بندی جستجوی خوب بر اساس شیوه های توسعه خوب ساخته شده است. گوگل همچنین ارائه می دهد راهنمای بسیار عمیق برای بهینهسازی جنبههای مختلف سایت خود برای سئوی بهتر – که اتفاقاً به طور همزمان رویههای توسعه فوقالعاده را نیز ترویج میکند.
نتیجه
هنگام بهینه سازی کد خود، نه تنها باید به اندازه فایل فکر کنیم، بلکه باید روش خواندن آن را نیز در نظر بگیریم. یا توسط مرورگرها یا حتی انسان های دیگر. استفاده از تلفن همراه نیز باید مورد توجه قرار گیرد، زیرا بسیاری از ارائه دهندگان خدمات این روزها محدودیت های بسیار محدودی برای داده اعمال می کنند. بنابراین اگرچه ممکن است انجام این همه بهینه سازی زمان بیشتری نیاز داشته باشد، اما مطمئناً تلاش ارزشمندی است زیرا نه تنها عملکرد بهتری را در مرورگر و روی تلفن همراه، اما همچنین این شانس را دارد که شیوه های توسعه بهتری را ترویج کند و حتی محتوای شما را رتبه بالاتری کسب کند روی موتورهای جستجو مانند گوگل دفعه بعد که برای راه اندازی آماده می شوید، تصاویر خود را در یک موتور فشرده سازی بیندازید… ممکن است تعجب کنید که چند مگابایت می تواند از بین برود!
تصویر شاخص، تصویر سرعت مدولار از طریق Shutterstock.
(برچسبها برای ترجمه )خوب
منتشر شده در 1403-01-14 21:57:03
منبع نوشتار