من هیچ محتوای مفیدی نمی توانم ببینم! چرا بارگیری اینقدر طولانی است؟ بیایید با بهینه سازی بزرگترین عنصر محتوا (LCP) این تجربه کاربری ناخوشایند را از بین ببریم.

یکی از عواملی که باعث ایجاد تجربه نامناسب در کاربر می‌شود مدت زمانی است که کاربر باید منتظر بماند تا محتوای ارائه شده روی صفحه را ببیند. First Contentful Paint (FCP) مدت زمان لازم برای ارائه محتوای اولیه DOM را اندازه‌گیری می‌کند، اما مدت زمان طولانی‌تری را که برای بزرگترین (معمولاً با معنی‌ترین) محتوای صفحه صرف می‌شود را محاسبه نمی‌کند.

LCP یک از معیارهای اصلی Core Web Vital است و زمانی را محاسبه می‌کند که بزرگترین عنصر محتوای در viewport قابل مشاهده است.این معیار می‌تواند برای تعیین زمان پایان ارائه محتوای اصلی صفحه بر روی صفحه استفاده شود.

معمول‌ترین دلایل LCP ضعیف عبارتند از:

• زمان طولانی پاسخ‌دهی سرور.
• رندر–بلاکینگ جاوا اسکریپت و CSS.
• زمان طولانی بارگیری منابع.
• رندرینگ در سمت کاربر.

زمان طولانی پاسخ‌دهی سرور

هرچه زمانی که مرورگر برای دریافت محتوا از سرور معطل بماند طولانی‌تر شود، رندر هر چیزی روی صفحه بیشتر طول می‌کشد. زمان پاسخ سریع‌تر سرور مستقیماً هر معیار بارگیری صفحه، از جمله LCP را بهبود می‌بخشد.

قبل از هر چیز دیگری، نحوه و مکانی که سرور محتوای شما را هندل می‌کند بهبود ببخشید. برای اندازه‌گیری زمان پاسخ سرور از Time to First Byte (TTFB) استفاده کنید. شما می‌توانید TTFB خود را به روش‌های مختلفی بهبود بخشید:

• سرور خود را بهینه کنید.
• کاربران را به CDN نزدیک هدایت کنید.
• کش محتوا.
• ابتدا صفحات HTML را به صورت کش سرو کنید.
• ارتباطات شخص ثالث را زودهنگام برقرار کنید.

بهینه‌سازی سرور

آیا از کوئری‌های سنگینی استفاده می‌کنید که زمان قابل توجهی برای تکمیل در سرور شما وقت صرف می‌کنند؟ یا عملیات پیچیده دیگری نیز در سمت سرور اتفاق می افتد که روند بازگشت مطالب صفحه را به تأخیر می‌اندازد؟ تجزیه و تحلیل و بهبود کارایی کد سمت سرور شما به طور مستقیم باعث می‌شود زمان دریافت داده برای مرورگر بهینه شود.

به جای سرویس دهی فوری یک صفحه ثابت به درخواست مرورگر، بسیاری از فریم‌ورک‌های وب که سمت سرور رندر می‌شوند، نیاز به ایجاد صفحه وب پویا دارند. به عبارت دیگر، فریم‌ورک‌ها به جای ارسال فقط یک فایل HTML کامل که در لحظه درخواست مرورگر از قبل آماده است، زمانی را برای ساخت صفحه با توجه به درخواست و کد صرف کنند. این ممکن است به دلیل جستجو در پایگاه داده باشد یا حتی به این دلیل که HTML باید توسط یک فریم‌ورک UI تولید شوند (مانند React). بسیاری از فریم‌ورک‌های وب که بر روی سرور اجرا می‌شوند دارای راهنمایی عملکردی هستند که می‌توانید برای سرعت بخشیدن به این روند از آنها استفاده کنید.

هدایت کاربران به نزدیک‌ترین CDN

شبکه تحویل محتوا (CDN) شبکه ای از سرورها است که در مکان های مختلف توزیع شده اند. اگر محتوای صفحه وب شما در یک سرور میزبانی شود، وب سایت شما برای کاربرانی که از نظر جغرافیایی دورتر هستند، کندتر بارگیری می شود زیرا درخواست مرورگر آن‌ها به معنای واقعی کلمه باید به سراسر جهان سفر کند. استفاده از CDN را در نظر داشته باشید تا اطمینان حاصل کنید که کاربران شما هرگز منتظر درخواست شبکه به سرورهای دور نخواهند ماند.

کش محتوا

اگر HTML شما ثابت و استاتیک است و نیازی به تغییر در هر درخواست نیست، caching می تواند از ایجاد مجدد غیرضروری آن جلوگیری کند. با ذخیره یک نسخه از HTML تولیدشده در دیسک، ذخیره سمت سرور می تواند TTFB را کاهش داده و استفاده از منابع را به حداقل برساند.

بسته به ابزار شما، روش‌های مختلفی برای اعمال کش محتوا سرور وجود دارد:

• پروکسی‌های معکوس (Varnish، nginx) را برای ارائه محتوای ذخیره‌شده پیکربندی کنید.
• کش محتوا ارائه دهنده ابر (Firebase ، AWS ، Azure) خود را پیکربندی و مدیریت کنید.
• از CDN که سرورهای لبه را فراهم می‌کنند استفاده کنید تا محتوای شما در نزدیکی کاربران ذخیره شود.

سرو صفحات HTML به صورت کش در ابتدا

هنگام نصب، یک سرویس‌دهنده در پس‌زمینه مرورگر اجرا می‌شود و می‌تواند درخواست‌های سرور را رهگیری کند. این سطح از کنترل کش، امکان ذخیره برخی یا تمام محتوای صفحات HTML را فراهم می‌کند و فقط در صورت تغییر محتوا، کش را به روز می‌کند.

ارتباطات زودهنگام با شخص ثالث

درخواست‌های سرور به مبدا شخص ثالث نیز می‌تواند بر LCP تأثیر بگذارد، مخصوصاً اگر برای نمایش محتوای مهم در صفحه مورد نیاز باشد. با استفاده از rel = “preconnect” به مرورگر اطلاع دهید که صفحه شما قصد دارد در اسرع وقت اتصال برقرار کند.

برای حل سریع‌تر جستجوی DNS می توانید از dns-prefetch نیز استفاده کنید.

گرچه هر دو متفاوت عمل می کنند، استفاده از dns-prefetch را به عنوان گزینه فال‌بک برای مرورگرهایی که از اتصال مجدد پشتیبانی نمی‌کنند، در نظر بگیرید.

رندر بلاکینگ جاوااسکریپت و CSS

قبل از اینکه یک مرورگر بتواند هر محتوایی را ارائه دهد، باید مارک HTML را در یک درخت DOM تجزیه کند. تجزیه کننده HTML اگر با صفحه‌های خارجی (<link rel = “stylesheet”>) یا برچسب‌های هم‌گام جاوااسکریپت (<script src = “main.js”>) روبرو شود، صبر می‌کند. اسکریپت‌ها و شیوه‌نامه‌ها هر دو منابع مسدود کننده هستند که FCP و در نتیجه LCP را به تأخیر می‌اندازند. برای سرعت بخشیدن به بارگذاری محتوای اصلی صفحه وب خود‌، JavaScript و CSS غیر مهم را به تعویق بیندازید.

کاهش زمان مسدودسازی CSS

با رعایت موارد زیر اطمینان حاصل کنید که حداقل مقدار CSS لازم، رندر را در سایت شما مسدود می‌کند:

• CSS را کم کنید.

• CSS غیر مهم را به تعویق بیندازید.

• درون خطی CSS مهم.

کاهش CSS

برای خوانایی آسان‌تر، فایل‌های CSS می‌توانند شامل نویسه‌هایی مانند فاصله یا کامنت باشند. این کاراکترها برای مرورگر غیرضروری هستند و کوچک کردن این پرونده‌ها باعث می‌شود که حذف شوند. در نهایت‌، کاهش میزان مسدود کردن CSS همیشه باعث بهینه سازی بزرگترین عنصر محتوا (LCP) می‌شود.

تعویق CSS غیرمهم

برای یافتن CSS استفاده نشده در صفحه وب خود از تب Coverage در Chrome DevTools استفاده کنید.

برای بهینه سازی:

• در صورت استفاده در صفحه جداگانه سایت خود ، CSS بدون استفاده را به طور کامل حذف کنید یا آن را به صفحه سبک دیگری منتقل کنید.

• برای هر CSS که برای ارائه اولیه نیازی به آن نیست، از loadCSS برای بارگیری همزمان پرونده‌ها استفاده کنید، که از rel = “preload” و onload استفاده می‌شود.

درون‌خطی CSS

با قرار دادن CSS مهم در سربرگ فایل HTML آن را درون‌خطی کنید:

درون‌خطی استایل‌های مهم، نیاز به درخواست رفت و برگشت برای CSS مهم را از بین می‌برد. همچنین به تعویق انداختن بقیه، زمان مسدودسازی CSS را به حداقل می‌رساند.

کاهش زمان مسدودسازی جاوا اسکریپت

حداقل جاوااسکریپت لازم را بارگیری و به کاربران ارائه دهید. کاهش میزان مسدودسازی JavaScript منجر به رندر سریع‌تر و در نتیجه LCP بهتر می‌شود. با بهینه‌سازی اسکریپت‌ها به چند روش مختلف می‌توانید این کار را انجام دهید:

• پرونده های جاوا اسکریپت را کوچک و فشرده کنید.

• جاوا اسکریپت استفاده‌نشده را به تعویق بیندازید.

پلی‌فیلزهای استفاده‌نشده را به حداقل برسانید.

زمان طولانی بارگیری منابع 

اگرچه افزایش زمان انسداد CSS یا JavaScript مستقیماً منجر به عملکرد بدتر می‌شود، اما زمان بارگیری برای بسیاری از انواع دیگر منابع نیز می‌تواند بر LCP تأثیر بگذارد.  

انواع عناصر موثر بر LCP عبارتند از:  

• <img>. 
• <image> داخل عنصر <svg>.  
• <video>. 
• عنصری با تصویر پس زمینه که از طریق تابع url () بارگیری می‌شود (در مقابل گرادیان CSS).  
• عناصر سطح بلوک حاوی گره‌های متنی یا سایر عناصر متن سطح درون‌خطی. 

مدت زمان لازم برای بارگیری این عناصر ، تأثیر مستقیمی بر LCP خواهد داشت. چند روش برای اطمینان از بارگیری سریع این پرونده‌ها وجود دارد:  

• بهینه‌سازی و فشرده‌سازی تصاویر. 
• منابع مهم را از قبل بارگیری کنید. 
• فشرده‌سازی فایل‌های متنی. 
• ارائه دارایی‌های مختلف بر اساس اتصال به شبکه (سرویس انطباقی). 
• دارایی‌ها را با استفاده از یک سرویس ورکر ذخیره کنید.

بهینه‌سازی و فشرده‌سازی تصاویر 

برای بسیاری از سایت‌ها، تصاویر پس از اتمام بارگیری صفحه، بزرگترین محتوای قابل مشاهده هستند. اسلایدرها و بنرهای بزرگ نمونه‌های متداول این موضوع هستند. 

بهبود مدت زمان بارگیری و ارائه این نوع تصاویر مستقیماً سرعت LCP را افزایش می‌دهد. برای انجام این کار:  

• در وهله اول استفاده نکردن از تصویر را در نظر بگیرید. اگر مربوط به محتوا نیست، آن را حذف کنید. 
• فشرده سازی تصاویر (به عنوان مثال با Imagemin). 
• تبدیل تصاویر به قالب‌های جدیدتر (JPEG 2000 ،JPEG XR یا WebP). 
• از تصاویر رسپانسیو استفاده کنید. 
• استفاده از CDN تصویر را در نظر بگیرید. 

منابع مهم را از قبل بارگیری کنید  

در بعضی مواقع، منابع مهمی که در یک فایل خاص CSS یا JavaScript اعلام یا استفاده می‌شوند ممکن است دیرتر از آنچه شما می خواهید بارگیری شوند، مانند فونت در بسیاری از پرونده‌های CSS یک برنامه.  

اگر می‌دانید یک منبع خاص باید اولویت‌بندی شود، از <link rel = “preload”> استفاده کنید تا آن را زودتر بارگیری کنید. بسیاری از منابع می‌توانند از قبل بارگیری شوند، اما ابتدا باید روی بارگیری دارایی های مهم مانند فونت‌ها، تصاویر یا فیلم‌های حجیم و CSS یا JavaScript تمرکز کنید.

فایل‌های تکست را فشرده‌سازی کنید 

الگوریتم‌های فشرده‌سازی، مانند Gzip و Brotli، می‌توانند اندازه فایل‌های متنی (HTML،CSS، JavaScript) را به میزان قابل‌توجهی کاهش دهند زیرا آن‌ها بین سرور و مرورگر منتقل می‌شوند. Gzip به طور موثر در همه مرورگرها پشتیبانی می‌شود و Brotli ، که حتی نتایج فشرده‌سازی بهتری را نیز فراهم می‌کند، تقریباً در همه مرورگرهای جدیدتر قابل استفاده است. با فشرده‌سازی منابع، زمان تحویل و زمان بارگذاری آن‌ها کاهش می‌یابد و در نتیجه LCP بهبود می‌یابد.  

1. ابتدا بررسی کنید که آیا سرور شما از قبل فایل‌ها را به طور خودکار فشرده می‌کند یا خیر. بیشتر سیستم عامل‌های هاست، CDN ها و سرورهای معکوس پروکسی یا دارایی‌ها را به صورت پیش‌فرض فشرده‌سازی می‌کنند یا به شما امکان می‌دهند به راحتی آنها را پیکربندی کنید.  
2. اگر می‌خواهید سرور خود را برای فشرده‌سازی فایل‌ها اصلاح کنید، استفاده از Brotli به جای gzip را در نظر بگیرید زیرا می‌تواند نسبت‌های فشرده‌سازی بهتری را فراهم کند.  
3. هنگامی که یک الگوریتم فشرده‌سازی برای استفاده انتخاب کردید، دارایی‌ها را در زمان ساخت فشرده‌ کنید نه در هنگام ارسال. با این کار سربار سرور به حداقل می‌رسد و از تأخیر در هنگام درخواست به ویژه هنگام استفاده از نسبت‌های فشرده‌سازی بالا جلوگیری می‌کند. 

سرو کردن متناسب داده 

هنگام بارگیری منابعی که محتوای اصلی یک صفحه را تشکیل می‌دهند، بسته به شرایط و ضوابط کاربر، می‌توان دارایی‌های مختلف را ارسال کرد. این کار را می‌توان با استفاده از APIهای اطلاعات شبکه، حافظه دستگاه و HardwareConcurrency انجام داد. به عنوان مثال، می‌توانید برای سرعت اتصال کمتر از 4G، به جای فیلم، یک تصویر نمایش دهید: 

لیستی از ویژگی‌های مفیدی که می‌توانید استفاده کنید:

• navigator.connection.effectiveType

• navigator.connection.saveData

• navigator.hardwareConcurrency

• navigator.deviceMemory

کش کردن دارایی‌ها با سرویس‌ورکر

از سرویس‌ورکر می‌توان برای بسیاری از کارهای مفید استفاده کرد، از جمله ارائه پاسخ‌های HTML کوچکتر که قبلاً در این مقاله ذکر شد. آنها همچنین می‌توانند برای ذخیره هر منبع استاتیک که می‌تواند به جای استفاده از شبکه در درخواست‌های تکراری، به مرورگر ارائه شود، مورد استفاده قرار بگیرند

precaching منابع حیاتی با استفاده از سرویس‌ورکر می‌تواند زمان بارگیری آن‌ها را به میزان قابل‌توجهی کاهش دهد، خصوصاً برای کاربرانی که صفحه وب را با اتصال ضعیف‌تری بارگیری می‌کنند (یا حتی به صورت آفلاین به آن دسترسی دارند). کتابخانه‌هایی مانند Workbox می‌توانند روند به روزرسانی دارایی‌های منسوخ شده را آسان‌تر از نوشتن یک سرویس‌ورکر سفارشی کنند تا خودتان این کار را انجام دهید.

رندر سمت کاربر

بسیاری از سایت‌ها برای ارائه مستقیم صفحات در مرورگر از منطق رندر سمت کاربر استفاده می‌کنند. فریم‌ورک‌ها و کتابخانه‌هایی، مانند React ،Angular و Vue، ساخت اپلیکیشن‌های تک صفحه‌ای را که جنبه‌های مختلف یک صفحه وب را کاملاً در بخش کاربر و نه در سرور مدیریت می‌کنند، آسان‌تر کرده اند.

اگر سایتی می‌سازید که بیشتر در بخش کاربر رندر می‌شود، باید مراقب باشید که اگر از یک بسته بزرگ جاوا اسکریپت استفاده کند، می‌تواند بر LCP تأثیر بگذارد. اگر بهینه‌سازی‌هایی برای جلوگیری از آن انجام نشده باشد، تا زمانی که بارگیری و اجرای همه جاوا اسکریپت مهم به پایان نرسد، کاربران نمی‌توانند محتوایی را در صفحه ببینند یا با آن تعامل داشته باشند.

هنگام ساخت یک سایت رندر در سمت کاربر، بهینه‌سازی‌های زیر را در نظر بگیرید:

• جاوا اسکریپت مهم را به حداقل برسانید.

• از رندر در سمت سرور استفاده کنید.

• از پیش رندر استفاده کنید.

استفاده از رندر سمت سرور

به حداقل رساندن مقدار جاوا اسکریپت همیشه باید اولین موضوعی باشد که در سایت‌هایی که در سمت کاربر رندر می شوند تمرکز کرد. با این حال، شما همچنین باید ترکیبی از رندر سمت سرور برای بهبود هرچه بیشتر LCP را در نظر داشته باشید.

این مفهوم با استفاده از سرور برای رندر اپلیکیشن به HTML کار می‌کند، جایی که مشتری سپس تمام JavaScript و داده‌های مورد نیاز را روی همان محتوا “hydrates” می‌کند. این کار می‌تواند با اطمینان از اینکه محتوای اصلی صفحه ابتدا در سرور ارائه می شود نه فقط در کلاینت، LCP را بهبود بخشد، اما چند اشکال وجود دارد:

• حفظ اپلیکیشن رندر شده توسط JavaScript در سرور و کاربر می‌تواند پیچیدگی را افزایش دهد.

• اجرای جاوا اسکریپت برای رندر یک فایل HTML در سرور همیشه باعث افزایش زمان پاسخ سرور (TTFB) در مقایسه با رندر فقط صفحات ثابت از سرور می‌شود.

• یک صفحه رندر شده از سرور ممکن است به نظر برسد که می‌توان با آن تعامل کرد، اما تا زمانی که تمام JavaScript سمت کاربر را اجرا نکند، نمی‌تواند به هیچ ورودی کاربر پاسخ دهد. به طور خلاصه، می‌تواند Time to Interactive (TTI) را بدتر کند.

استفاده از پیش رندر

پیش رندر یک تکنیک جداگانه است که پیچیدگی کمتری نسبت به رندر سمت سرور دارد و همچنین روشی را برای بهبود LCP در برنامه شما ارائه می‌دهد.

پیش رندر، همچنان بر TTI تأثیر منفی می‌گذارد اما بر زمان پاسخگویی سرور تحت تأثیر رندر سمت سرور که هر صفحه را فقط پس از درخواست به صورت پویا ارائه می دهد، تأثیر نمی گذارد.

منبع:

https://web.dev/optimize-lcp/