در کنار حذف دانلودهای غیرضروری منابع، بهترین کاری که میتوانید برای بهبود سرعت بارگذاری صفحه انجام دهید، به حداقل رساندن حجم کلی دانلود با بهینهسازی و فشردهسازی منابع باقیمانده است.
فشردهسازی دادهها ۱۰۱
پس از اینکه وبسایت خود را طوری تنظیم کردید که از دانلود هرگونه منبع بلااستفاده جلوگیری کند، مرحله بعدی فشردهسازی هرگونه منبع واجد شرایط باقیمانده است که مرورگر باید دانلود کند. بسته به نوع منبع - متن، تصاویر، فونتها و غیره - تکنیکهای مختلفی برای انتخاب وجود دارد: ابزارهای عمومی که میتوانند روی سرور وب فعال شوند، بهینهسازیهای پیشپردازش برای انواع محتوای خاص و بهینهسازیهای مختص منابع که نیاز به ورودی از توسعهدهنده دارند.
ارائه بهترین عملکرد مستلزم ترکیبی از تمام تکنیکهای زیر است:
- فشردهسازی فرآیند رمزگذاری اطلاعات با استفاده از بیتهای کمتر است.
- حذف دادههای غیرضروری همیشه بهترین نتیجه را به همراه دارد.
- تکنیکها و الگوریتمهای فشردهسازی مختلفی وجود دارد.
- برای رسیدن به بهترین فشردهسازی، به تکنیکهای متنوعی نیاز خواهید داشت.
فرآیند کاهش اندازه دادهها، فشردهسازی دادهها است. افراد زیادی الگوریتمها، تکنیکها و بهینهسازیهایی را برای بهبود نسبتهای فشردهسازی، سرعت فشردهسازی و حافظه مورد نیاز الگوریتمهای فشردهسازی مختلف ارائه دادهاند.
بحث کامل در مورد فشردهسازی دادهها فراتر از محدوده این راهنما است. با این حال، درک چگونگی عملکرد فشردهسازی - در سطح بالا - و تکنیکهایی که میتوانید برای کاهش اندازه فایلهای مختلف مورد نیاز صفحات خود استفاده کنید، مهم است.
برای نشان دادن اصول اصلی این تکنیکها، فرآیند بهینهسازی یک قالب پیام متنی ساده را که دقیقاً برای این مثال اختراع شده است، در نظر بگیرید:
# 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
- پیامها ممکن است حاوی حاشیهنویسیهای دلخواه باشند - که گاهی اوقات به عنوان کامنت شناخته میشوند - که با پیشوند "#" مشخص میشوند. حاشیهنویسیها بر معنای پیام یا رفتارهای آن تأثیری ندارند.
- پیامها ممکن است حاوی سرآیند (headers ) باشند که جفتهای کلید-مقدار (که در مثال قبل با
":"از هم جدا شدهاند) هستند و در ابتدای پیام ظاهر میشوند. - پیامها حامل دادههای متنی هستند.
برای کاهش اندازه پیام قبلی که از ۲۰۰ کاراکتر شروع میشود، چه کاری میتوان انجام داد؟
- این نظر جالب است، اما تاثیری بر معنای پیام ندارد. هنگام انتقال پیام، آن را حذف کنید.
- تکنیکهای خوبی برای رمزگذاری هدرها به شیوهای کارآمد وجود دارد. برای مثال، اگر میدانید که همه پیامها دارای «قالب» و «تاریخ» هستند، میتوانید آنها را به شناسههای صحیح کوتاه تبدیل کنید و فقط آنها را ارسال کنید. با این حال، ممکن است این درست نباشد، بنابراین بهتر است فعلاً آن را به حال خود رها کنید.
- محتوای این بدافزار فقط متن است. اگرچه ما نمیدانیم محتوای واقعی آن چیست (ظاهراً از یک
"secret-cipher"استفاده میکند)، اما فقط نگاه کردن به متن نشان میدهد که افزونگی زیادی در آن وجود دارد. شاید به جای ارسال حروف تکراری، بتوانید تعداد حروف تکراری را بشمارید و آنها را به طور کارآمدتری رمزگذاری کنید. به عنوان مثال،"AAA"به"3A"تبدیل میشود که نشان دهنده توالی سه حرف A است.
ترکیب این تکنیکها نتیجه زیر را به همراه دارد:
format: secret-cipher
date: 08/25/16
3A2Z4B3E3M 3E3T3A
پیام جدید ۵۶ کاراکتر دارد، به این معنی که شما پیام اصلی را ۷۲٪ فشرده کردهاید. این کاهش قابل توجهی است!
این یک مثال ساده از چگونگی تأثیر الگوریتمهای فشردهسازی در کاهش حجم انتقال منابع مبتنی بر متن است. در عمل، الگوریتمهای فشردهسازی بسیار پیچیدهتر از مثال قبلی هستند و در وب، میتوان از الگوریتمهای فشردهسازی برای کاهش قابل توجه زمان دانلود منابع استفاده کرد. با اعمال فشردهسازی بر روی منابع مبتنی بر متن، یک صفحه وب میتواند زمان کمتری را صرف بارگذاری منابع کند، به طوری که کاربران میتوانند اثرات آن منابع را زودتر از زمانی که فشردهسازی انجام نمیشود، مشاهده کنند.
کوچکسازی: پیشپردازش و بهینهسازیهای خاص زمینه
اولین تکنیکی که در اینجا مورد بحث قرار میگیرد، کوچکسازی (minification) است. اگرچه کوچکسازی صرفاً یک الگوریتم فشردهسازی نیست، اما روشی برای حذف کاراکترهای غیرضروری و تکراری مورد استفاده در کد منبع است تا منابع را برای انسان قابل خواندنتر کند. با این حال، این خوانایی برای حفظ عملکرد آن کد منبع در وبسایتهای تولیدی ضروری نیست و میتواند بارگذاری منابع در وب را به تأخیر بیندازد.
کوچکسازی نوعی بهینهسازی مختص محتوا است که میتواند حجم منابع ارائه شده را به میزان قابل توجهی کاهش دهد و این بهینهسازیها بهتر است به عنوان بخشی از فرآیند ساخت و استقرار شما اعمال شوند. به عنوان مثال، bundlerها نوعی نرمافزار رایج هستند که میتوانند به طور خودکار منابع را درست قبل از استقرار کد تولید جدید در یک وبسایت، کوچکسازی کنند.
بهترین راه برای فشردهسازی دادههای اضافی یا غیرضروری، حذف آنهاست. با این حال، شما نمیتوانید دادههای دلخواه را حذف کنید. با این حال، در برخی زمینهها که دانش محتوایی خاصی از قالب دادهها و ویژگیهای آنها داریم، میتوان اندازه بار مفید را بدون تأثیر بر معنا یا قابلیتهای واقعی آن، به میزان قابل توجهی کاهش داد.
<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، حذف این نوع افزونگی میتواند زیاد شود - اما ممکن است چیزی نباشد که بتوان آن را به طور گسترده اعمال کرد، زیرا انتخابگرها اغلب لزوماً در زمینههای مختلف، مانند درون کوئریهای رسانهای، تکرار میشوند. - فاصلهها و تبها از امکانات توسعهدهندگان در HTML، CSS و جاوا اسکریپت هستند. یک فشردهساز اضافی میتواند تمام تبها و فاصلهها را حذف کند. برخلاف سایر تکنیکهای حذف دادههای تکراری، این نوع بهینهسازی را میتوان به طور نسبتاً گستردهای اعمال کرد، البته تا زمانی که چنین فاصلهها یا تبهایی برای نمایش صفحه ضروری نباشند - برای مثال، شما میخواهید فاصلههای بین رشتههای متن در یک سند 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>
پس از اعمال مراحل قبلی، صفحه از ۵۱۶ به ۲۰۴ کاراکتر میرسد که تقریباً ۶۰٪ صرفهجویی را نشان میدهد. درست است که خیلی خوانا نیست، اما برای قابل استفاده بودن نیازی به خوانا بودن آن نیست. شیوههای توسعه مدرن همچنین به شما این امکان را میدهند که نسخههای خوشفرم و خوانا از کد منبع خود را از کد بهینهشدهای که به محیط تولید ارسال میکنید، جدا نگه دارید. همراه با نقشههای منبع - که نمایشی خوانا از کد تولید تبدیلشده شما ارائه میدهد، به شما امکان میدهد تا اشکالات را در محیط تولید راحتتر عیبیابی کنید - میتوانید هم یک تجربه توسعهدهنده خوب داشته باشید و هم عملکرد را به خاطر تجربه کاربر بهینه کنید.
مثال قبلی نکتهی مهمی را نشان میدهد: یک فشردهساز عمومی - مثلاً فشردهسازی متن دلخواه - میتواند کار فشردهسازی صفحه در مثال قبلی را به خوبی انجام دهد، اما هرگز نمیداند که باید نظرات را حذف کند، قوانین CSS را از بین ببرد یا دهها بهینهسازی خاص محتوا را انجام دهد. به همین دلیل است که پیشپردازش، کوچکسازی و سایر بهینهسازیهای آگاه از متن مهم هستند.
به طور مشابه، تکنیکهای شرح داده شده در بالا میتوانند فراتر از داراییهای مبتنی بر متن گسترش یابند. تصاویر، ویدیو و سایر انواع محتوا، همگی حاوی اَشکال خاص خود از فراداده و بارهای داده مختلف هستند. به عنوان مثال، هر زمان که با دوربین عکس میگیرید، فایل آن معمولاً اطلاعات اضافی زیادی را در خود جای میدهد: تنظیمات دوربین، مکان و غیره. بسته به کاربرد شما، این دادهها ممکن است حیاتی باشند (مثلاً یک سایت اشتراکگذاری عکس) یا ممکن است کاملاً بیفایده باشند. باید در نظر بگیرید که آیا ارزش حذف کردن را دارند یا خیر. در عمل، این فرادادهها میتوانند برای هر تصویر تا دهها کیلوبایت حجم ایجاد کنند.
خلاصه اینکه، به عنوان اولین قدم در بهینهسازی کارایی داراییهای خود، فهرستی از انواع مختلف محتوا تهیه کنید و در نظر بگیرید که چه نوع بهینهسازیهای خاص محتوایی را میتوانید برای کاهش اندازه آنها اعمال کنید. سپس - پس از اینکه فهمیدید آنها چه هستند - با افزودن آنها به مراحل ساخت و انتشار خود، این بهینهسازیها را خودکار کنید تا مطمئن شوید که بهینهسازیها به طور مداوم برای هر انتشار جدید به مرحله تولید اعمال میشوند.
فشردهسازی متن با الگوریتمهای فشردهسازی
گام بعدی برای کاهش اندازه دادههای متنی، اعمال یک الگوریتم فشردهسازی بر روی آنهاست. این الگوریتم یک گام فراتر میرود و با جستجوی شدید الگوهای تکرارپذیر در دادههای متنی قبل از ارسال آنها به کاربر، و از حالت فشرده خارج کردن آنها پس از رسیدن به مرورگر کاربر، انجام میشود. نتیجه، کاهش بیشتر و قابل توجه این منابع و متعاقباً زمان دانلود سریعتر است.
- gzip و Brotli الگوریتمهای فشردهسازی رایجی هستند که روی فایلهای متنی مانند CSS، جاوا اسکریپت و HTML بهترین عملکرد را دارند.
- همه مرورگرهای مدرن از فشردهسازی gzip و Brotli پشتیبانی میکنند و پشتیبانی از هر دو را در هدر درخواست HTTP
Accept-Encodingاعلام میکنند. - سرور شما باید طوری پیکربندی شود که فشردهسازی را فعال کند. نرمافزار وب سرور اغلب ماژولهایی را فعال میکند که منابع مبتنی بر متن را فشرده کنند. این کار را بهطور پیشفرض انجام میدهد.
- هم gzip و هم Brotli را میتوان با تنظیم سطح فشردهسازی، برای بهبود نسبتهای فشردهسازی تنظیم کرد. برای gzip، تنظیمات فشردهسازی از ۱ تا ۹ متغیر است که ۹ بهترین حالت است. برای Brotli، این محدوده ۰ تا ۱۱ است که ۱۱ بهترین حالت است. با این حال، تنظیمات فشردهسازی بالاتر به زمان بیشتری نیاز دارند. برای منابعی که به صورت پویا فشرده میشوند - یعنی در زمان درخواست - تنظیمات در وسط این محدوده، بهترین تعادل بین نسبت فشردهسازی و سرعت را ارائه میدهند. با این حال، فشردهسازی استاتیک نیز امکانپذیر است، یعنی زمانی که پاسخ قبل از زمان فشرده میشود و بنابراین میتواند از تهاجمیترین تنظیمات فشردهسازی موجود برای هر الگوریتم فشردهسازی استفاده کند.
- شبکههای تحویل محتوا (CDN) معمولاً فشردهسازی خودکار منابع واجد شرایط را ارائه میدهند. CDNها همچنین میتوانند فشردهسازی پویا و ایستا را برای شما مدیریت کنند و یک جنبه کمتر از فشردهسازی را که باید نگران آن باشید، به شما ارائه دهند.
gzip و Brotli فشردهسازهای رایجی هستند که میتوانند روی هر جریانی از بایتها اعمال شوند. در باطن، آنها برخی از محتویات قبلاً بررسیشدهی یک فایل را به خاطر میسپارند و متعاقباً تلاش میکنند قطعات دادهی تکراری را به روشی کارآمد پیدا و جایگزین کنند.
در عمل، هم gzip و هم Brotli در محتوای مبتنی بر متن بهترین عملکرد را دارند و اغلب برای فایلهای بزرگتر به نرخ فشردهسازی تا ۷۰ تا ۹۰ درصد میرسند. با این حال، اجرای این الگوریتمها روی فایلهایی که از قبل با استفاده از الگوریتمهای جایگزین فشرده شدهاند - مانند اکثر فرمتهای تصویری که از تکنیکهای فشردهسازی بدون اتلاف یا با اتلاف استفاده میکنند - بهبود چندانی ایجاد نمیکند یا اصلاً بهبود ایجاد نمیکند.
همه مرورگرهای مدرن در هدر درخواست HTTP مربوط به Accept-Encoding پشتیبانی از gzip و Brotli را تبلیغ میکنند. با این حال، این مسئولیت ارائهدهنده خدمات میزبانی وب است که اطمینان حاصل کند که وب سرور به درستی پیکربندی شده است تا در صورت درخواست مشتری، منبع فشردهشده را ارائه دهد.
| فایل | الگوریتم | اندازه فشرده نشده | اندازه فشرده | نسبت تراکم |
|---|---|---|---|---|
| انگولار-۱.۸.۳.js | بروتلی | ۱,۳۴۶ کیلوبایت | ۲۵۶ کیلوبایت | ۸۱٪ |
| انگولار-۱.۸.۳.js | gzip | ۱,۳۴۶ کیلوبایت | ۳۲۹ کیلوبایت | ۷۶٪ |
| انگولار-۱.۸.۳.min.js | بروتلی | ۱۷۳ کیلوبایت | ۵۳ کیلوبایت | ۶۹٪ |
| انگولار-۱.۸.۳.min.js | gzip | ۱۷۳ کیلوبایت | ۶۰ کیلوبایت | ۶۵٪ |
| جیکوئری-۳.۷.۱.js | بروتلی | ۳۰۲ کیلوبایت | ۶۹ کیلوبایت | ۷۷٪ |
| جیکوئری-۳.۷.۱.js | gzip | ۳۰۲ کیلوبایت | ۸۳ کیلوبایت | ۷۳٪ |
| جیکوئری-۳.۷.۱.min.js | بروتلی | ۸۵ کیلوبایت | ۲۷ کیلوبایت | ۶۸٪ |
| جیکوئری-۳.۷.۱.min.js | gzip | ۸۵ کیلوبایت | ۳۰ کیلوبایت | ۶۵٪ |
| لوداش-۴.۱۷.۲۱.js | بروتلی | ۵۳۱ کیلوبایت | ۷۳ کیلوبایت | ۸۶٪ |
| لوداش-۴.۱۷.۲۱.js | gzip | ۵۳۱ کیلوبایت | ۹۴ کیلوبایت | ۸۲٪ |
| لوداش-۴.۱۷.۲۱.min.js | بروتلی | ۷۱ کیلوبایت | ۲۳ کیلوبایت | ۶۸٪ |
| لوداش-۴.۱۷.۲۱.min.js | gzip | ۷۱ کیلوبایت | ۲۵ کیلوبایت | ۶۵٪ |
جدول قبل میزان صرفهجویی که فشردهسازی Brotli و gzip میتوانند برای چند کتابخانه معروف جاوا اسکریپت فراهم کنند را نشان میدهد. این صرفهجویی بسته به فایل و الگوریتم از ۶۵٪ تا ۸۶٪ متغیر است. برای مرجع، حداکثر سطح فشردهسازی برای هر فایل برای Brotli و gzip اعمال شده است. در صورت امکان، Brotli را به gzip ترجیح دهید.
فعال کردن فشردهسازی یکی از سادهترین و مؤثرترین بهینهسازیها برای پیادهسازی است. اگر وبسایت شما از آن بهره نمیبرد، فرصت بزرگی را برای بهبود عملکرد کاربران خود از دست میدهید. خوشبختانه، بسیاری از سرورهای وب تنظیمات پیشفرضی را ارائه میدهند که این بهینهسازی مهم را فعال میکنند و به ویژه CDNها در پیادهسازی آن به گونهای که سرعت و نسبت فشردهسازی را متعادل میکند، بسیار مؤثر هستند.
یک راه سریع برای مشاهده فشردهسازی در عمل، باز کردن Chrome DevTools، باز کردن پنل Network ، بارگذاری صفحه مورد نظر خود و مشاهده پایینترین قسمت پنل network است.
مانند تصویر قبلی، باید جزئیات زیر را ببینید:
- تعداد درخواستها، که تعداد منابع بارگذاری شده برای صفحه است.
- اندازه انتقال همه درخواستها. این نشان دهنده اثربخشی فشردهسازی اعمال شده بر روی هر یک از منابع یک صفحه است.
- اندازه منبع همه درخواستها. این نشان میدهد که منابع صفحه پس از فشردهسازی چقدر بزرگ هستند.
تأثیرات بر Core Web Vitals
بهبود عملکرد را نمیتوان اندازهگیری کرد، مگر اینکه معیارهایی وجود داشته باشد که آن پیشرفتها را منعکس کنند. ابتکار Core Web Vitals برای ایجاد و افزایش آگاهی از معیارهایی وجود دارد که تجربه واقعی کاربر را منعکس میکنند. این برخلاف معیارهایی است - مانند زمان بارگذاری ساده صفحه - که به وضوح به کیفیت تجربه کاربر تبدیل نمیشوند.
وقتی بهینهسازیهای ذکر شده در این راهنما را روی منابع وبسایت خود اعمال میکنید، تأثیرات آن بر Core Web Vitals میتواند بسته به منابع بهینهسازی شده و معیار(های) مربوطه متفاوت باشد. با این حال، در اینجا مواردی وجود دارد که اعمال این بهینهسازیها میتواند Core Web Vitals وبسایت شما را بهبود بخشد:
- منابع HTML که کوچکسازی و فشردهسازی میشوند، میتوانند بارگذاری آن HTML، قابلیت کشف زیرمنابع آن و در نتیجه بارگذاری آنها را بهبود بخشند. این میتواند برای Largest Contentful Paint (LCP) یک صفحه مفید باشد. در حالی که میتوان از نکات مربوط به منابع مانند
rel="preload"برای تأثیرگذاری بر قابلیت کشف منابع استفاده کرد، استفاده بیش از حد از آنها میتواند باعث ایجاد مشکلاتی در مورد پهنای باند شود. با اطمینان از فشردهسازی پاسخ HTML برای یک درخواست ناوبری، منابع درون آنها میتوانند در اسرع وقت توسط اسکنر preload کشف شوند. - برخی از کاندیدهای LCP همچنین میتوانند با استفاده از فشردهسازی زودتر بارگذاری شوند. به عنوان مثال، تصاویر SVG که کاندید LCP هستند، میتوانند مدت زمان بارگذاری منابع خود را از طریق فشردهسازی مبتنی بر متن کاهش دهند. این با بهینهسازیهایی که برای سایر انواع تصاویر - که ذاتاً از طریق سایر روشهای فشردهسازی فشرده میشوند - انجام میدهید، متفاوت است، مانند نحوه استفاده تصاویر JPEG از فشردهسازی با اتلاف.
- علاوه بر این، گرههای متنی نیز میتوانند کاندیدهای LCP باشند. نحوهی استفاده از تکنیکهای شرح داده شده در این راهنما بستگی به این دارد که آیا از فونت وب برای متن در صفحات وب خود استفاده میکنید یا خیر. اگر از فونت وب استفاده میکنید، بهترین شیوههای بهینهسازی فونت وب اعمال میشود. با این حال، اگر از فونتهای وب استفاده نمیکنید - بلکه از فونتهای سیستمی استفاده میکنید که بدون تحمیل هیچ مدت زمان بارگذاری منبع نمایش داده میشوند - کوچکسازی و فشردهسازی CSS شما این مدت زمان را کاهش میدهد، به این معنی که رندر گرههای متنی بالقوه LCP میتواند زودتر اتفاق بیفتد.
نتیجهگیری
نحوه بهینهسازی رمزگذاری و انتقال دادههای متنی، یک مفهوم پایه برای عملکرد است - اما مفهومی است که تأثیر زیادی دارد. مطمئن شوید که تمام تلاش خود را میکنید تا منابع واجد شرایط برای کوچکسازی و فشردهسازی از این بهینهسازیها بهرهمند شوند.
مهمتر از آن، مطمئن شوید که این فرآیندها خودکار میشوند. برای کوچکسازی، از یک bundler برای اعمال کوچکسازی روی منابع واجد شرایط استفاده کنید. مطمئن شوید که پیکربندی وب سرور شما از فشردهسازی پشتیبانی میکند، اما مهمتر از آن، از مؤثرترین فشردهسازی موجود استفاده کنید. برای اینکه این کار تا حد امکان ساده شود، از CDNها برای خودکارسازی فشردهسازی برای خود استفاده کنید، زیرا آنها نه تنها میتوانند منابع را برای شما فشرده کنند، بلکه میتوانند این کار را خیلی سریع نیز انجام دهند.
با گنجاندن این مفاهیم عملکرد پایه در معماری وبسایت خود، میتوانید اطمینان حاصل کنید که تلاشهای بهینهسازی عملکرد شما در وضعیت خوبی قرار دارند و بهینهسازیهای بعدی میتوانند بر پایه محکمی از شیوههای خوب پایه بنا شوند.