علاوه‌بر حذف بارگیری منابع غیرضروری، بهترین کاری که می‌توانید برای بهبود سرعت بارگیری صفحه انجام دهید این است که با بهینه‌سازی و فشرده‌سازی منابع باقی‌مانده، حجم کلی بارگیری را به حداقل برسانید.
مبانی فشرده‌سازی داده‌ها
وقتی وب‌سایتتان را طوری تنظیم کردید که از بارگیری منابع استفاده‌نشده جلوگیری کند، مرحله بعدی فشرده‌سازی منابع واجدشرایط باقی‌مانده‌ای است که مرورگر باید بارگیری کند. بسته به نوع منبع (نوشتار، تصویر، قلم، و غیره)، تکنیک‌های مختلفی برای انتخاب وجود دارد: ابزارهای عمومی که می‌توانند در سرور وب فعال شوند، بهینه‌سازی‌های پیش‌پردازش برای انواع محتوای خاص، و بهینه‌سازی‌های مختص منبع که به ورودی ازسوی توسعه‌دهنده نیاز دارند.
ارائه بهترین عملکرد مستلزم ترکیبی از همه تکنیک‌های زیر است:
- فشرده‌سازی فرایند کدبندی اطلاعات بااستفاده از بیت‌های کمتر است.
- حذف داده‌های غیرضروری همیشه بهترین نتایج را به‌همراه دارد.
- تکنیک‌ها و الگوریتم‌های فشرده‌سازی مختلفی وجود دارد.
- برای دستیابی به بهترین فشرده‌سازی، به تکنیک‌های مختلفی نیاز خواهید داشت.
فرایند کاهش اندازه داده‌ها فشرده‌سازی داده‌ها است. افراد زیادی الگوریتم‌ها، تکنیک‌ها، و بهینه‌سازی‌هایی را برای بهبود نسبت‌های فشرده‌سازی، سرعت فشرده‌سازی، و حافظه موردنیاز برای الگوریتم‌های فشرده‌سازی مختلف ارائه کرده‌اند.
بحث کامل درباره فشرده‌سازی داده‌ها بسیار فراتر از محدوده این راهنما است. بااین‌حال، مهم است که در سطح بالا درک کنید که فشرده‌سازی چگونه کار می‌کند و تکنیک‌هایی که می‌توانید برای کاهش اندازه دارایی‌های مختلفی که صفحات شما نیاز دارند استفاده کنید.
برای نشان دادن اصول اصلی این تکنیک‌ها، فرایند بهینه‌سازی یک قالب پیام متنی ساده را درنظر بگیرید که فقط برای این مثال ابداع شده است:
# 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
- پیام‌ها ممکن است حاوی حاشیه‌نویسی‌های دلخواه باشند—گاهی به آن‌ها نظرات گفته می‌شود—که با پیشوند «#» مشخص می‌شوند. حاشیه‌نویسی‌ها بر معنی پیام یا رفتارهای آن تأثیری ندارند.
- پیام‌ها ممکن است حاوی سرصفحه باشند که جفت‌های کلید-مقدار هستند (در مثال بالا با
":"از هم جدا شده‌اند) و در ابتدای پیام ظاهر می‌شوند. - پیام‌ها حاوی محموله نوشتاری هستند.
برای کاهش اندازه پیام قبلی که از ۲۰۰ نویسه شروع می‌شود، چه کاری می‌توان انجام داد؟
- نظر جالب است، اما بر معنی پیام تأثیری ندارد. هنگام ارسال پیام، آن را حذف کنید.
- روش‌های خوبی برای کدبندی سرایندها به‌شیوه‌ای کارآمد وجود دارد. برای مثال، اگر می‌دانید که همه پیام‌ها «قالب» و «تاریخ» دارند، می‌توانید آن‌ها را به شناسه‌های عدد صحیح کوتاه تبدیل کنید و فقط آن‌ها را ارسال کنید. اما ممکن است این‌طور نباشد، بنابراین بهتر است فعلاً آن را رها کنید.
- بار داده فقط نوشتار است. اگرچه نمی‌دانیم محتوای آن واقعاً چیست (ظاهراً از
"secret-cipher"استفاده می‌کند)، اما فقط با نگاه کردن به نوشتار مشخص می‌شود که حشو زیادی در آن وجود دارد. شاید به‌جای ارسال حروف تکراری، بتوانید تعداد حروف تکراری را بشمارید و آن‌ها را به‌طور کارآمدتری کدگذاری کنید. برای مثال،"AAA"به"3A"تبدیل می‌شود که نشان‌دهنده توالی سه حرف A است.
ترکیب این تکنیک‌ها نتیجه زیر را تولید می‌کند:
format: secret-cipher
date: 08/25/16
3A2Z4B3E3M 3E3T3A
طول پیام جدید ۵۶ نویسه است، یعنی پیام اصلی را ۷۲٪ فشرده کرده‌اید. کاهش قابل‌توجهی است!
این یک مثال ساده از چگونگی تأثیر الگوریتم‌های فشرده‌سازی در کاهش اندازه انتقال منابع متنی است. در عمل، الگوریتم‌های فشرده‌سازی بسیار پیچیده‌تر از آنچه در مثال قبلی نشان داده شد هستند و در وب، می‌توان از الگوریتم‌های فشرده‌سازی برای کاهش قابل‌توجه زمان بارگیری منابع استفاده کرد. با اعمال فشرده‌سازی بر دارایی‌های نوشتارمحور، صفحه وب می‌تواند زمان کمتری را صرف بار کردن منابع کند تا کاربران بتوانند تأثیرات آن منابع را زودتر از زمانی که فشرده‌سازی انجام نشده است ببینند.
کوچک‌سازی: پیش‌پردازش و بهینه‌سازی‌های مختص بافت
اولین تکنیکی که در اینجا مورد بحث قرار می‌گیرد، کوچک‌سازی است. درحالی‌که کوچک‌سازی دقیقاً یک الگوریتم فشرده‌سازی نیست، روشی برای حذف نویسه‌های غیرضروری و زائد استفاده‌شده در کد منبع است تا منابع برای انسان‌ها خواناتر شوند. اما این خوانایی برای حفظ عملکرد آن کد منبع در وب‌سایت‌های تولیدی ضروری نیست و می‌تواند بار کردن منابع را در وب به‌تأخیر بیندازد.
کوچک‌سازی نوعی بهینه‌سازی مختص محتوا است که می‌تواند به‌طور قابل‌توجهی اندازه منابع ارائه‌شده را کاهش دهد و بهینه‌سازی‌ها بهتر است به‌عنوان بخشی از فرایند ساخت و استقرار شما اعمال شوند. برای مثال، بسته‌سازها نوعی نرم‌افزار پرکاربرد هستند که می‌توانند منابع را درست قبل‌از استقرار کد تولید جدید در وب‌سایت به‌طور خودکار کوچک کنند.
بهترین راه برای فشرده‌سازی داده‌های زائد یا غیرضروری، حذف آن‌ها است. اما نمی‌توانید داده‌های دلخواه را حذف کنید. بااین‌حال، در برخی زمینه‌ها که ما دانش خاص محتوا درباره قالب داده و ویژگی‌های آن داریم، می‌توان اندازه بار مفید را به‌طور قابل‌توجهی کاهش داد بدون اینکه بر معنی یا قابلیت‌های واقعی آن تأثیر بگذارد.
<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 (<!-- ... -->)، و JavaScript (// ...) اندازه کل انتقال صفحه و منابع فرعی آن را کاهش می‌دهد. - یک فشرده‌ساز CSS «هوشمند» می‌تواند متوجه شود که ما از روشی ناکارآمد برای تعریف قوانین برای
.awesome-containerاستفاده می‌کنیم و دو اعلان را بدون تأثیر بر سبک‌های دیگر در یک اعلان جمع کند و بایت‌های بیشتری را ذخیره کند. Over a large set of CSS rules, removing this kind of redundancy can add up—but it may not be something that can be applied aggressively, as selectors are often necessarily duplicated in different contexts, such as within media queries. - فاصله‌ها و زبانه‌ها در 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، JavaScript، HTML.
- همه مرورگرهای نو از فشرده‌سازی gzip و Brotli پشتیبانی می‌کنند و پشتیبانی از هر دو را در سرایند درخواست HTTP
Accept-Encodingاعلام می‌کنند. - سرورتان باید برای فعال کردن فشرده‌سازی پیکربندی شده باشد. نرم‌افزار سرور وب اغلب به پیمانه‌ها امکان می‌دهد منابع مبتنی بر نوشتار را به‌طور پیش‌فرض فشرده کنند.
- هر دو gzip و Brotli را می‌توان با تنظیم سطح فشرده‌سازی برای بهبود نسبت‌های فشرده‌سازی تنظیم دقیق کرد. برای gzip، تنظیمات فشرده‌سازی از ۱ تا ۹ است که ۹ بهترین است. برای Brotli، این محدوده از ۰ تا ۱۱ است که ۱۱ بهترین است. بااین‌حال، تنظیمات فشرده‌سازی بالاتر به زمان بیشتری نیاز دارد. برای منابعی که به‌طور پویا فشرده شده‌اند—یعنی در زمان درخواست—تنظیمات در وسط محدوده معمولاً بهترین توازن را بین نسبت فشرده‌سازی و سرعت ارائه می‌دهند. بااین‌حال، فشرده‌سازی ایستا امکان‌پذیر است، یعنی زمانی که پاسخ ازقبل فشرده می‌شود و بنابراین می‌تواند از تهاجمی‌ترین تنظیمات فشرده‌سازی موجود برای هر الگوریتم فشرده‌سازی استفاده کند.
- شبکه‌های توزیع محتوا (CDNs) معمولاً فشرده‌سازی خودکار منابع واجدشرایط را ارائه می‌دهند. شبکه‌های توزیع محتوا همچنین می‌توانند فشرده‌سازی پویا و ایستا را برای شما مدیریت کنند، که باعث می‌شود یک جنبه کمتر از فشرده‌سازی برای نگرانی داشته باشید.
gzip و Brotli فشرده‌سازهای رایجی هستند که می‌توانند برای هر جریان بایتی اعمال شوند. در پشت صحنه، آن‌ها برخی‌از محتواهای قبلاً بررسی‌شده فایل را به‌خاطر می‌سپارند و سپس تلاش می‌کنند قطعات داده تکراری را به‌طور کارآمد پیدا و جایگزین کنند.
در عمل، gzip و Brotli هر دو بهترین عملکرد را روی محتوای نوشتاری دارند و اغلب به نرخ فشرده‌سازی تا ۷۰-۹۰٪ برای فایل‌های بزرگ‌تر می‌رسند. بااین‌حال، اجرای این الگوریتم‌ها روی دارایی‌هایی که قبلاً بااستفاده از الگوریتم‌های جایگزین فشرده شده‌اند (مانند اکثر قالب‌های تصویر که از تکنیک‌های فشرده‌سازی بدون اتلاف یا پراتلاف استفاده می‌کنند) بهبود چندانی ایجاد نمی‌کند.
همه مرورگرهای نو پشتیبانی از gzip و Brotli را در
Accept-Encoding سرایند درخواست HTTP تبلیغ می‌کنند. بااین‌حال، این مسئولیت ارائه‌دهنده خدمات میزبانی وب است که مطمئن شود سرور وب به‌درستی پیکربندی شده است تا وقتی مشتری درخواست می‌کند، منبع فشرده‌شده را ارائه دهد.
| فایل | الگوریتم | اندازه فشرده‌نشده | اندازه فشرده‌شده | نسبت فشرده‌سازی |
|---|---|---|---|---|
| angular-1.8.3.js | Brotli | ۱٬۳۴۶ کیبی‌بایت | ۲۵۶ کیبی‌بایت | ٪۸۱ |
| angular-1.8.3.js | gzip | ۱٬۳۴۶ کیبی‌بایت | ۳۲۹ کیبی‌بایت | ٪۷۶ |
| angular-1.8.3.min.js | Brotli | ۱۷۳ کیبی‌بایت | ۵۳ کیبی‌بایت | ٪۶۹ |
| angular-1.8.3.min.js | gzip | ۱۷۳ کیبی‌بایت | ۶۰ کیبی‌بایت | ٪۶۵ |
| jquery-3.7.1.js | Brotli | ۳۰۲ کیبی‌بایت | ۶۹ کیبی‌بایت | ٪۷۷ |
| jquery-3.7.1.js | gzip | ۳۰۲ کیبی‌بایت | ۸۳ کیبی‌بایت | ٪۷۳ |
| jquery-3.7.1.min.js | Brotli | ۸۵ کیبی‌بایت | ۲۷ کیبی‌بایت | ٪۶۸ |
| jquery-3.7.1.min.js | gzip | ۸۵ کیبی‌بایت | ۳۰ کیبی‌بایت | ٪۶۵ |
| lodash-4.17.21.js | Brotli | ۵۳۱ کیبی‌بایت | ۷۳ کیبی‌بایت | ٪۸۶ |
| lodash-4.17.21.js | gzip | ۵۳۱ کیبی‌بایت | ۹۴ کیبی‌بایت | ٪۸۲ |
| lodash-4.17.21.min.js | Brotli | ۷۱ کیبی‌بایت | ۲۳ کیبی‌بایت | ٪۶۸ |
| lodash-4.17.21.min.js | gzip | ۷۱ کیبی‌بایت | ۲۵ کیبی‌بایت | ٪۶۵ |
جدول بالا نشان می‌دهد که فشرده‌سازی Brotli و gzip چه مقدار صرفه‌جویی می‌تواند برای چند کتابخانه جاوا اسکریپت شناخته‌شده فراهم کند. بسته به فایل و الگوریتم، میزان صرفه‌جویی از ۶۵٪ تا ۸۶٪ متغیر است. برای مرجع، حداکثر سطح فشرده‌سازی برای هر فایل برای Brotli و gzip اعمال شد. هرجا امکان‌پذیر بود، Brotli را به gzip ترجیح دهید.
فعال کردن فشرده‌سازی یکی از ساده‌ترین و مؤثرترین بهینه‌سازی‌ها برای پیاده‌سازی است. اگر وب‌سایت شما از آن بهره نمی‌برد، فرصت بزرگی را برای بهبود عملکرد برای کاربران خود ازدست می‌دهید. خوشبختانه، بسیاری از سرورهای وب پیکربندی‌های پیش‌فرضی ارائه می‌دهند که این بهینه‌سازی مهم را فعال می‌کند، و به‌ویژه CDNها در پیاده‌سازی آن به‌گونه‌ای که سرعت و نسبت فشرده‌سازی را متعادل کند بسیار مؤثر هستند.
یک راه سریع برای دیدن فشرده‌سازی در عمل، باز کردن Chrome DevTools، باز کردن پانل شبکه، بارگیری صفحه‌ای به انتخاب شما و مشاهده پایین‌ترین قسمت پانل شبکه است.
مانند تصویر قبلی، باید تفکیکی از موارد زیر را ببینید:
- تعداد درخواست‌ها، که تعداد منابع بارشده برای صفحه است.
- اندازه انتقال همه درخواست‌ها. این نشان‌دهنده اثربخشی فشرده‌سازی اعمال‌شده بر هریک از منابع صفحه است.
- اندازه منبع همه درخواست‌ها. این نشان می‌دهد که منابع صفحه پس‌از خارج شدن از حالت فشرده چقدر بزرگ هستند.
تأثیرات بر معیارهای کلیدی اصلی وب
بهبود عملکرد را نمی‌توان اندازه‌گیری کرد مگراینکه سنجه‌هایی وجود داشته باشد که آن بهبودها را منعکس کند. ابتکار Core Web Vitals برای ایجاد و افزایش آگاهی از سنجه‌هایی که تجربه واقعی کاربر را منعکس می‌کنند وجود دارد. این برخلاف سنجه‌هایی است (مثلاً زمان بار کردن ساده صفحه) که به‌طور واضح به کیفیت تجربه کاربری ترجمه نمی‌شوند.
وقتی بهینه‌سازی‌های شرح‌داده‌شده در این راهنما را برای منابع موجود در وب‌سایتتان اعمال می‌کنید، تأثیرات آن بر «معیارهای کلیدی وب» می‌تواند براساس منابع بهینه‌شده و سنجه(های) مربوطه متفاوت باشد. بااین‌حال، در اینجا چند نمونه آورده شده است که در آن‌ها اعمال این بهینه‌سازی‌ها می‌تواند «شاخص‌های حیاتی وب» وب‌سایت شما را بهبود بخشد:
- منابع HTML که کوچک و فشرده شده‌اند می‌توانند بار کردن آن HTML و قابلیت شناسایی منابع فرعی آن را بهبود بخشند و درنتیجه بار کردن آن‌ها را بهبود بخشند. این کار می‌تواند برای بزرگ‌ترین نقاشی دارای محتوا (LCP) صفحه مفید باشد. درحالی‌که از راهنمایی‌های منبع مانند
rel="preload"می‌توان برای تأثیرگذاری بر قابلیت کشف منابع استفاده کرد، استفاده بیش‌ازحد از آن‌ها می‌تواند مشکلاتی درزمینه رقابت بر سر پهنای باند ایجاد کند. با اطمینان از اینکه پاسخ HTML برای درخواست پیمایش فشرده شده است، منابع درون آن‌ها می‌تواند در اسرع وقت توسط اسکنر پیش‌بارگیری کشف شود. - برخی‌از نامزدهای LCP را می‌توان بااستفاده از فشرده‌سازی زودتر بار کرد. برای مثال، تصاویر SVG که نامزد «بزرگ‌ترین نقاشی دارای محتوا» هستند می‌توانند مدت بار کردن منبع خود را ازطریق فشرده‌سازی مبتنی بر نوشتار کاهش دهند. این با بهینه‌سازی‌هایی که برای انواع دیگر تصویر انجام می‌دهید متفاوت است—که ذاتاً ازطریق روش‌های فشرده‌سازی دیگر فشرده می‌شوند—مانند نحوه استفاده تصاویر JPEG از فشرده‌سازی پراتلاف.
- علاوه‌براین، گره‌های نوشتاری نیز می‌توانند نامزد LCP باشند. نحوه استفاده از تکنیک‌های شرح‌داده‌شده در این راهنما به این بستگی دارد که آیا از قلم وب برای نوشتار در صفحه‌های وب خود استفاده می‌کنید یا نه. اگر از قلم وب استفاده می‌کنید، روال‌های مطلوب بهینه‌سازی قلم وب اعمال می‌شود. بااین‌حال، اگر از قلم‌های وب استفاده نمی‌کنید—بلکه از قلم‌های سیستم استفاده می‌کنید که بدون صرف زمان برای بار کردن منابع نمایش داده می‌شوند—کوچک‌سازی و فشرده‌سازی CSS این مدت‌زمان را کاهش می‌دهد، یعنی رندر کردن گره‌های نوشتاری LCP احتمالی می‌تواند زودتر انجام شود.
نتیجه‌گیری
نحوه بهینه‌سازی کدبندی و انتقال دارایی‌های مبتنی بر نوشتار یک مفهوم عملکردی پایه است، اما تأثیر بزرگی دارد. مطمئن شوید که هر کاری می‌توانید انجام می‌دهید تا مطمئن شوید منابع واجدشرایط برای کوچک‌سازی و فشرده‌سازی از این بهینه‌سازی‌ها بهره‌مند می‌شوند.
مهم‌تر اینکه مطمئن شوید این فرایندها خودکارسازی شده باشند. برای کوچک‌سازی، از یک بسته‌بند برای اعمال کوچک‌سازی به منابع واجدشرایط استفاده کنید. مطمئن شوید که پیکربندی سرور وب شما از فشرده‌سازی پشتیبانی می‌کند، اما علاوه‌بر آن، از مؤثرترین فشرده‌سازی موجود استفاده کنید. برای اینکه این کار تا حد امکان ساده شود، از CDNها برای خودکارسازی فشرده‌سازی استفاده کنید، زیرا آن‌ها نه‌تنها می‌توانند منابع را برای شما فشرده کنند، بلکه می‌توانند این کار را بسیار سریع انجام دهند.
با تثبیت این مفاهیم عملکرد پایه در معماری وب‌سایتتان، می‌توانید مطمئن شوید که تلاش‌هایتان برای بهینه‌سازی عملکرد در مسیر درستی قرار دارد و بهینه‌سازی‌های بعدی می‌توانند بر پایه محکمی از روال‌های مطلوب پایه استوار باشند.