در کنار حذف دانلودهای غیرضروری منابع، بهترین کاری که می توانید برای بهبود سرعت بارگذاری صفحه انجام دهید این است که با بهینه سازی و فشرده سازی منابع باقیمانده، حجم کلی دانلود را به حداقل برسانید.
فشرده سازی داده ها 101
هنگامی که وب سایت خود را برای جلوگیری از بارگیری منابع بلااستفاده راه اندازی کردید، گام بعدی فشرده کردن منابع واجد شرایط باقی مانده است که مرورگر باید دانلود کند. بسته به نوع منبع - متن، تصاویر، فونت ها و غیره - تکنیک های مختلفی برای انتخاب وجود دارد: ابزارهای عمومی که می توانند در سرور وب فعال شوند، بهینه سازی های پیش پردازش برای انواع محتوای خاص، و بهینه سازی های خاص منابع که نیاز به ورودی از توسعه دهنده دارند.
ارائه بهترین عملکرد مستلزم ترکیبی از تمام تکنیک های زیر است:
- فشرده سازی فرآیند رمزگذاری اطلاعات با استفاده از بیت های کمتر است.
- حذف داده های غیر ضروری همیشه بهترین نتایج را به همراه دارد.
- تکنیک ها و الگوریتم های فشرده سازی مختلفی وجود دارد.
- برای رسیدن به بهترین فشرده سازی به تکنیک های مختلفی نیاز دارید.
فرآیند کاهش حجم داده ها فشرده سازی داده ها است. بسیاری از افراد الگوریتمها، تکنیکها و بهینهسازیهایی را برای بهبود نسبت فشردهسازی، سرعت فشردهسازی و حافظه مورد نیاز الگوریتمهای فشردهسازی مختلف ارائه کردهاند.
بحث کامل در مورد فشرده سازی داده ها فراتر از محدوده این راهنما است. با این حال، درک نحوه عملکرد فشرده سازی و تکنیک هایی که می توانید برای کاهش اندازه دارایی های مختلفی که صفحات شما به آن نیاز دارند، در سطح بالا درک کنید.
برای نشان دادن اصول اصلی این تکنیک ها، فرآیند بهینه سازی یک قالب پیام متنی ساده را که فقط برای این مثال ابداع شده است، در نظر بگیرید:
# Below is a secret message, which consists of a set of headers in
# key-value format followed by a newline and the encrypted message.
format: secret-cipher
date: 08/25/16
AAAZZBBBBEEEMMM EEETTTAAA
- پیام ها ممکن است حاوی حاشیه نویسی های دلخواه باشند - که گاهی اوقات به عنوان نظرات شناخته می شوند - که با پیشوند "#" نشان داده می شوند. حاشیه نویسی بر معنای پیام یا رفتارهای آن تأثیر نمی گذارد.
- پیامها ممکن است حاوی سرصفحههایی باشند که جفتهای کلید-مقدار هستند (در مثال قبل با
":"
از هم جدا شدهاند) که در ابتدای پیام ظاهر میشوند. - پیام ها دارای محموله های متنی هستند.
برای کاهش اندازه پیام قبلی که از 200 کاراکتر شروع می شود، چه کاری می توان انجام داد؟
- کامنت جالب است اما تاثیری در معنای پیام ندارد. هنگام انتقال پیام آن را حذف کنید.
- تکنیک های خوبی برای رمزگذاری هدرها به شیوه ای کارآمد وجود دارد. به عنوان مثال، اگر میدانید که همه پیامها دارای «فرمت» و «تاریخ» هستند، میتوانید آنها را به شناسههای عدد صحیح کوتاه تبدیل کنید و فقط آنها را ارسال کنید. با این حال، ممکن است این درست نباشد، بنابراین بهتر است فعلا آن را به حال خود رها کنید.
- محموله فقط متنی است. در حالی که ما نمی دانیم محتوای آن واقعاً چیست (ظاهراً از یک
"secret-cipher"
استفاده می کند)، فقط نگاه کردن به متن نشان می دهد که افزونگی زیادی در آن وجود دارد. شاید به جای ارسال نامه های مکرر، فقط بتوانید تعداد حروف تکراری را بشمارید و آنها را با کارایی بیشتری رمزگذاری کنید. به عنوان مثال،"AAA"
به"3A"
تبدیل می شود که نشان دهنده دنباله ای از سه A است.
ترکیب این تکنیک ها نتیجه زیر را به همراه دارد:
format: secret-cipher
date: 08/25/16
3A2Z4B3E3M 3E3T3A
پیام جدید 56 کاراکتر است، به این معنی که شما پیام اصلی را 72٪ فشرده کرده اید. این کاهش قابل توجهی است!
این یک مثال اسباب بازی است که نشان می دهد چگونه الگوریتم های فشرده سازی می توانند در کاهش اندازه انتقال منابع مبتنی بر متن موثر باشند. در عمل، الگوریتمهای فشردهسازی بسیار پیچیدهتر از نمونههای قبلی هستند، و در وب، الگوریتمهای فشردهسازی میتوانند برای کاهش قابل توجه زمان دانلود منابع استفاده شوند. با اعمال فشرده سازی برای دارایی های مبتنی بر متن، یک صفحه وب می تواند زمان کمتری را برای بارگذاری منابع صرف کند، به طوری که کاربران می توانند اثرات آن منابع را زودتر از آنچه که فشرده سازی نمی کنند، ببینند.
کوچک سازی: پیش پردازش و بهینه سازی های خاص زمینه
اولین تکنیکی که در اینجا مورد بحث قرار می گیرد کوچک سازی است. در حالی که کوچکسازی صرفاً یک الگوریتم فشردهسازی نیست، اما راهی برای حذف کاراکترهای غیرضروری و اضافی مورد استفاده در کد منبع است تا منابع را برای انسان خواناتر کند. با این حال، این خوانایی برای حفظ عملکرد آن کد منبع در وبسایتهای تولیدی ضروری نیست و میتواند بارگذاری منابع را در وب به تأخیر بیندازد.
کوچکسازی نوعی بهینهسازی محتوای خاص است که میتواند به میزان قابلتوجهی حجم منابع ارائهشده را کاهش دهد و بهینهسازیها به بهترین شکل به عنوان بخشی از فرآیند ساخت و استقرار شما اعمال میشوند. برای مثال، باندلرها نوعی نرمافزار پرکاربرد هستند که میتوانند بهطور خودکار منابع را درست قبل از استقرار کد تولید جدید در یک وبسایت کوچکسازی کنند.
بهترین راه برای فشرده سازی داده های اضافی یا غیر ضروری حذف آن ها است. با این حال، شما نمی توانید فقط داده های دلخواه را حذف کنید. با این حال، در برخی زمینهها که ما دانش خاص محتوا از قالب داده و ویژگیهای آن داریم، میتوان به میزان قابلتوجهی اندازه بار را کاهش داد بدون اینکه بر معنی یا قابلیتهای واقعی آن تأثیر بگذارد.
<html>
<head>
<style>
/* awesome-container is only used on the landing page */
.awesome-container {
font-size: 120%;
}
.awesome-container {
width: 50%;
}
</style>
</head>
<body>
<!-- awesome container content: START -->
<div>
This is my awesome container, and it is <em>so</em> awesome.
</div>
<!-- awesome container content: END -->
<script>
awesomeAnalytics(); // Beacon conversion metrics
</script>
</body>
</html>
قطعه HTML قبلی و سه نوع محتوای متفاوتی که شامل آن است را در نظر بگیرید:
- نشانه گذاری HTML
- CSS برای سفارشی کردن ارائه یک صفحه.
- جاوا اسکریپت برای تقویت تعاملات و سایر قابلیت های صفحه پیشرفته.
هر یک از این انواع محتوا قوانین متفاوتی برای محتوای معتبر، قوانین متفاوت برای تعیین نظرات و غیره دارد. سوالی که باقی می ماند این است که "چگونه می توان اندازه این صفحه را کاهش داد؟"
- نظرات کد بهترین دوست یک توسعه دهنده هستند، اما مرورگر به آنها نیاز ندارد! حذف نظرات CSS (
/* ... */
)، HTML (<!-- ... -->
)، و جاوا اسکریپت (// ...
) حجم کل انتقال صفحه و منابع فرعی آن را کاهش می دهد. - یک کمپرسور CSS «هوشمند» میتواند متوجه شود که ما از روشی ناکارآمد برای تعریف قوانین برای
.awesome-container
استفاده میکنیم و دو اعلان را بدون تأثیر بر سبکهای دیگر جمع میکنیم و بایتهای بیشتری را ذخیره میکنیم. در مجموعه بزرگی از قوانین CSS، حذف این نوع افزونگی میتواند اضافه شود – اما ممکن است چیزی نباشد که بتوان آن را به شدت اعمال کرد، زیرا انتخابکنندهها اغلب لزوماً در زمینههای مختلف، مانند پرسوجوهای رسانهای، کپی میشوند. - Spaces و برگهها امکانات توسعهدهنده در HTML، CSS و JavaScript هستند. یک کمپرسور اضافی می تواند تمام زبانه ها و فضاها را از بین ببرد. برخلاف سایر تکنیکهای کپیسازی، این نوع بهینهسازی را میتوان به طور نسبتاً تهاجمی اعمال کرد، تا زمانی که چنین فضاها یا برگههایی برای ارائه صفحه ضروری نباشند - به عنوان مثال، شما میخواهید فضاهای داخل متن را در یک سند HTML حفظ کنید. ، زیرا آنها خوانایی محتوایی را که کاربران واقعاً می بینند تضمین می کنند.
<html><head><style>.awesome-container{font-size:120%;width:50%}</style></head><body><div>This is my awesome container, and it is <em>so</em> awesome.</div><script>awesomeAnalytics()</script></body></html>
پس از اعمال مراحل قبلی، صفحه از 516 کاراکتر به 204 کاراکتر می رسد که نشان دهنده صرفه جویی تقریباً 60 درصدی است. درست است که خیلی خوانا نیست، اما برای قابل استفاده بودن لازم نیست. روشهای توسعه مدرن همچنین به شما این امکان را میدهد که نسخههای قالببندی شده و قابل خواندن کد منبع خود را جدا از کدهای بهینهسازی شدهای که برای تولید ارسال میکنید، نگه دارید. همراه با نقشههای منبع - که نمایشی قابل خواندن از کد تولید تغییر یافته شما را ارائه میدهد و به شما امکان میدهد راحتتر باگهای تولید را عیبیابی کنید - میتوانید هم تجربه توسعهدهنده خوبی داشته باشید و هم عملکرد را به خاطر تجربه کاربر بهینه کنید.
مثال قبلی یک نکته مهم را نشان می دهد: یک کمپرسور همه منظوره - مثلاً یک کمپرسور طراحی شده برای فشرده سازی متن دلخواه - می تواند کار بسیار خوبی در فشرده سازی صفحه در مثال قبلی انجام دهد، اما هرگز نمی داند که نظرات را حذف کند، CSS را جمع کند. قوانین، یا دهها بهینهسازی محتوای خاص دیگر. به همین دلیل است که پیش پردازش، کوچک سازی و سایر بهینه سازی های آگاه از زمینه مهم هستند.
به طور مشابه، تکنیک هایی که در بالا توضیح داده شد را می توان فراتر از دارایی های مبتنی بر متن گسترش داد. تصاویر، ویدیوها و سایر انواع محتوا همگی دارای فرمهای متادیتا و بارهای مختلف هستند. به عنوان مثال، هر زمان که با دوربین عکس می گیرید، فایل آن معمولاً اطلاعات اضافی زیادی را در خود جای می دهد: تنظیمات دوربین، مکان و غیره. بسته به برنامه شما، این داده ها ممکن است حیاتی باشند (به عنوان مثال، یک سایت اشتراک گذاری عکس) یا ممکن است کاملاً بی فایده باشند. باید در نظر بگیرید که آیا ارزش برداشتن آن را دارد یا خیر. در عمل، این ابرداده می تواند تا ده ها کیلوبایت برای هر تصویر اضافه کند.
به طور خلاصه، به عنوان اولین گام در بهینهسازی کارایی داراییهای خود، فهرستی از انواع محتوای مختلف بسازید و در نظر بگیرید که چه نوع بهینهسازیهای خاص محتوا را میتوانید برای کاهش اندازه آنها اعمال کنید. سپس—بعد از اینکه فهمیدید چیست، این بهینهسازیها را با افزودن آنها به مراحل ساخت و انتشار خود بهطور خودکار انجام دهید تا اطمینان حاصل کنید که بهینهسازیها به طور مداوم برای هر نسخه جدید برای تولید اعمال میشوند.
فشرده سازی متن با الگوریتم های فشرده سازی
گام بعدی برای کاهش اندازه دارایی های مبتنی بر متن، اعمال یک الگوریتم فشرده سازی برای آنها است. این امر با جستجوی تهاجمی الگوهای تکرارپذیر در محمولههای متنی پیش از ارسال آنها به کاربر، و پس از رسیدن به مرورگر کاربر، از حالت فشرده خارج میشود. نتیجه کاهش بیشتر و قابل توجه این منابع و متعاقباً زمان دانلود سریعتر است.
- gzip و Brotli الگوریتمهای فشردهسازی معمولی هستند که بهترین عملکرد را در داراییهای مبتنی بر متن دارند: CSS، JavaScript، HTML.
- همه مرورگرهای مدرن از فشردهسازی gzip و Brotli پشتیبانی میکنند و پشتیبانی از هر دو را در هدر درخواست HTTP
Accept-Encoding
تبلیغ میکنند. - سرور شما باید برای فعال کردن فشرده سازی پیکربندی شود. نرم افزار وب سرور اغلب ماژول ها را قادر می سازد تا منابع مبتنی بر متن را به طور پیش فرض فشرده کنند.
- هم gzip و هم Brotli را می توان برای بهبود نسبت تراکم با تنظیم سطح فشرده سازی به خوبی تنظیم کرد. برای gzip، تنظیمات فشرده سازی از 1 تا 9 متغیر است که 9 بهترین است. برای Brotli، این محدوده 0 تا 11 است که 11 بهترین است. با این حال، تنظیمات فشرده سازی بالاتر به زمان بیشتری نیاز دارد. برای منابعی که به صورت پویا فشرده می شوند - یعنی در زمان درخواست - تنظیمات در وسط محدوده تمایل دارند بهترین مبادله بین نسبت تراکم و سرعت را ارائه دهند. با این حال، فشرده سازی استاتیک امکان پذیر است، یعنی زمانی که پاسخ زودتر از موعد فشرده می شود و بنابراین می توان از تهاجمی ترین تنظیمات فشرده سازی موجود برای هر الگوریتم فشرده سازی استفاده کرد.
- شبکه های تحویل محتوا (CDN) معمولاً فشرده سازی خودکار منابع واجد شرایط را ارائه می دهند. CDN ها همچنین می توانند فشرده سازی پویا و ایستا را برای شما مدیریت کنند و یک جنبه کمتر از فشرده سازی را برای نگرانی در اختیار شما قرار دهند.
gzip و Brotli کمپرسورهای رایجی هستند که می توانند روی هر جریانی از بایت ها اعمال شوند. در زیر هود، آنها برخی از محتویات قبلاً بررسی شده یک فایل را به خاطر می آورند و متعاقباً تلاش می کنند تا قطعات داده تکراری را به روشی کارآمد پیدا و جایگزین کنند.
در عمل، هر دو gzip و Brotli در محتوای مبتنی بر متن بهترین عملکرد را دارند و اغلب به نرخ فشردهسازی تا ۷۰ تا ۹۰ درصد برای فایلهای بزرگتر دست مییابند. با این حال، اجرای این داراییهای الگوریتمهایی که قبلاً با استفاده از الگوریتمهای جایگزین فشرده شدهاند - مانند اکثر فرمتهای تصویری که از تکنیکهای فشردهسازی بدون تلفات یا با اتلاف استفاده میکنند - باعث بهبود کمی میشود.
همه مرورگرهای مدرن پشتیبانی از gzip و Brotli را در هدر درخواست HTTP Accept-Encoding
تبلیغ می کنند. با این حال، این مسئولیت ارائه دهنده میزبانی است که اطمینان حاصل کند که سرور وب به درستی پیکربندی شده است تا در صورت درخواست مشتری، منبع فشرده را ارائه دهد.
فایل | الگوریتم | اندازه فشرده نشده | اندازه فشرده | نسبت تراکم |
---|---|---|---|---|
angular-1.8.3.js | بروتلی | 1,346 کیلوبایت | 256 کیلوبایت | 81% |
angular-1.8.3.js | gzip | 1,346 کیلوبایت | 329 کیلو بایت | 76% |
angular-1.8.3.min.js | بروتلی | 173 کیلوبایت | 53 کیلو بایت | 69% |
angular-1.8.3.min.js | gzip | 173 کیلوبایت | 60 کیلو بایت | 65% |
jquery-3.7.1.js | بروتلی | 302 کیلوبایت | 69 کیلوبایت | 77% |
jquery-3.7.1.js | gzip | 302 کیلوبایت | 83 کیلوبایت | 73% |
jquery-3.7.1.min.js | بروتلی | 85 کیلوبایت | 27 کیلوبایت | 68% |
jquery-3.7.1.min.js | gzip | 85 کیلوبایت | 30 کیلو بایت | 65% |
lodash-4.17.21.js | بروتلی | 531 کیلوبایت | 73 کیلوبایت | 86% |
lodash-4.17.21.js | gzip | 531 کیلو بایت | 94 کیلوبایت | 82% |
lodash-4.17.21.min.js | بروتلی | 71 کیلوبایت | 23 کیلو بایت | 68% |
lodash-4.17.21.min.js | gzip | 71 کیلو بایت | 25 کیلو بایت | 65% |
جدول قبلی صرفه جویی هایی را نشان می دهد که فشرده سازی Brotli و gzip می توانند برای چند کتابخانه معروف جاوا اسکریپت فراهم کنند. بسته به فایل و الگوریتم، میزان صرفه جویی از 65٪ تا 86٪ متغیر است. برای مرجع، حداکثر سطح فشرده سازی برای هر فایل برای Brotli و gzip اعمال شد. تا جایی که ممکن است، Brotli را به gzip ترجیح دهید.
فعال کردن فشرده سازی یکی از ساده ترین و موثرترین بهینه سازی ها برای پیاده سازی است. اگر وب سایت شما از مزایای آن استفاده نمی کند، فرصت بزرگی را برای بهبود عملکرد کاربران خود از دست می دهید. خوشبختانه، بسیاری از وب سرورها تنظیمات پیشفرضی را ارائه میکنند که این بهینهسازی مهم را امکانپذیر میسازد، و بهویژه CDNها در پیادهسازی آن به نحوی که سرعت و نسبت فشردهسازی را متعادل میکند، بسیار مؤثر هستند.
یک راه سریع برای مشاهده فشردهسازی در عمل این است که Chrome DevTools را باز کنید، پانل شبکه را باز کنید، صفحه دلخواه خود را بارگیری کنید و قسمت پایین پانل شبکه را مشاهده کنید.
مانند تصویر قبل، شما باید یک تفکیک از موارد زیر را ببینید:
- تعداد درخواست ها، که تعداد منابع بارگذاری شده برای صفحه است.
- اندازه انتقال همه درخواست ها این نشان دهنده اثربخشی فشرده سازی اعمال شده در هر یک از منابع صفحه است.
- اندازه منابع همه درخواست ها این نشان می دهد که منابع صفحه بعد از فشرده سازی چقدر بزرگ است.
تأثیرات بر روی Core Web Vitals
بهبود عملکرد را نمی توان اندازه گیری کرد مگر اینکه معیارهایی وجود داشته باشد که این پیشرفت ها را منعکس کند. ابتکار Core Web Vitals برای ایجاد و افزایش آگاهی از معیارهایی که تجربه واقعی کاربر را منعکس می کند وجود دارد. این برخلاف معیارهایی است - مثلاً زمان بارگذاری ساده صفحه - که به وضوح به کیفیت تجربه کاربر ترجمه نمی شود.
هنگامی که بهینهسازیهای ذکر شده در این راهنما را برای منابع موجود در وبسایت خود اعمال میکنید، تأثیرات آن بر Core Web Vitals میتواند بر اساس منابع بهینهسازی شده و معیار(های) مربوطه متفاوت باشد. با این حال، در اینجا مواردی وجود دارد که در آنها استفاده از این بهینه سازی ها می تواند Core Web Vitals وب سایت شما را بهبود بخشد:
- منابع HTML که کوچک و فشرده می شوند می توانند بارگذاری آن HTML، قابلیت کشف منابع فرعی آن را بهبود بخشند و در نتیجه بارگذاری آنها را بهبود بخشند. این می تواند برای بزرگترین رنگ محتوای صفحه (LCP) مفید باشد. در حالی که از نکات منبع مانند
rel="preload"
می توان برای تاثیرگذاری بر قابلیت کشف منابع استفاده کرد، استفاده بیش از حد از آنها می تواند مشکلاتی را در بحث پهنای باند ایجاد کند. با اطمینان از فشرده شدن پاسخ HTML برای درخواست ناوبری، منابع موجود در آنها را می توان در اسرع وقت توسط اسکنر پیش بارگذاری کشف کرد. - برخی از نامزدهای LCP نیز می توانند با استفاده از فشرده سازی زودتر بارگذاری شوند. به عنوان مثال، تصاویر SVG که کاندید LCP هستند، می توانند مدت بار منبع آنها را از طریق فشرده سازی مبتنی بر متن کاهش دهند. این متفاوت از بهینهسازیهایی است که برای انواع دیگر تصاویر انجام میدهید - که ذاتاً از طریق روشهای فشردهسازی دیگر فشرده میشوند - مانند اینکه چگونه تصاویر JPEG از فشردهسازی با اتلاف استفاده میکنند.
- علاوه بر این، گره های متنی نیز می توانند کاندید LCP باشند. اینکه چگونه تکنیک های توضیح داده شده در این راهنما به این بستگی دارد که آیا از فونت وب برای متن در صفحات وب خود استفاده می کنید یا خیر. اگر از فونت وب استفاده میکنید، بهترین روشهای بهینهسازی فونت وب اعمال میشود. با این حال، اگر از فونتهای وب استفاده نمیکنید - بلکه از فونتهای سیستمی استفاده میکنید که بدون نیاز به بارگذاری منبع نمایش داده میشوند، به حداقل رساندن و فشردهسازی CSS این مدت زمان را کاهش میدهد، به این معنی که رندر گرههای متنی LCP بالقوه میتواند زودتر رخ دهد.
نتیجه گیری
اینکه چگونه رمزگذاری و انتقال داراییهای مبتنی بر متن را بهینه میکنید، یک مفهوم عملکرد پایه است - اما این مفهومی است که تأثیر زیادی دارد. مطمئن باشید که تمام تلاش خود را انجام می دهید تا اطمینان حاصل کنید که منابع واجد شرایط برای کوچک سازی و فشرده سازی از این بهینه سازی ها سود می برند.
مهمتر از آن، مطمئن شوید که این فرآیندها خودکار هستند. برای کوچکسازی، از یک بستهکننده برای اعمال کوچکسازی برای منابع واجد شرایط استفاده کنید. مطمئن شوید که پیکربندی وب سرور شما از فشرده سازی پشتیبانی می کند، اما بیشتر از آن، از موثرترین فشرده سازی موجود استفاده کنید. برای اینکه این امر تا حد امکان پیش پا افتاده باشد، از CDN ها برای خودکارسازی فشرده سازی برای شما استفاده کنید، زیرا آنها نه تنها می توانند منابع را برای شما فشرده کنند، بلکه می توانند این کار را خیلی سریع نیز انجام دهند.
با تثبیت این مفاهیم عملکرد پایه در معماری وبسایت خود، میتوانید اطمینان حاصل کنید که تلاشهای بهینهسازی عملکرد شما بر پایه خوبی است و بهینهسازیهای بعدی میتواند بر پایهای محکم از شیوههای پایه خوب باشد.