بهینه سازی بزرگترین رنگ محتوایی

یک راهنمای گام به گام در مورد چگونگی تجزیه LCP و شناسایی حوزه‌های کلیدی برای بهبود.

Philip Walton

Barry Pollard

منتشر شده: ۳۰ آوریل ۲۰۲۰، آخرین به‌روزرسانی: ۳۱ مارس ۲۰۲۵

بزرگترین رنگ محتوا (LCP) یکی از سه معیار Core Web Vitals است و نشان می‌دهد که محتوای اصلی یک صفحه وب با چه سرعتی بارگذاری می‌شود. به طور خاص، LCP زمان را از زمانی که کاربر بارگذاری صفحه را شروع می‌کند تا زمانی که بزرگترین تصویر یا بلوک متن در نمای دید رندر می‌شود، اندازه‌گیری می‌کند.

برای ارائه یک تجربه کاربری خوب، سایت‌ها باید تلاش کنند تا حداقل در ۷۵٪ از بازدیدهای صفحه، LCP برابر با ۲.۵ ثانیه یا کمتر داشته باشند.

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

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

درک معیار LCP شما

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

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

داده‌های LCP مبتنی بر کاربران واقعی را می‌توان از ابزارهای نظارت بر کاربر واقعی (RUM) که در یک سایت نصب شده‌اند یا با استفاده از گزارش تجربه کاربری کروم (CrUX) که داده‌های ناشناس را از کاربران واقعی کروم برای میلیون‌ها وب‌سایت جمع‌آوری می‌کند، به دست آورد.

استفاده از داده‌های Chrome DevTools CrUX LCP

پنل عملکرد Chrome DevTools، تجربه LCP محلی شما را در کنار CrUX LCP صفحه یا مبدا در نمای معیارهای زنده و در Insights یک ردیابی عملکرد شامل جزئیات زمان‌بندی‌های زیربخش LCP (که به زودی توضیح خواهیم داد) نشان می‌دهد.

با لایه‌بندی داده‌های میدانی در پنل Performance، می‌توانید ارزیابی کنید که آیا یک صفحه دارای مشکلات LCP کاربر واقعی است یا خیر و تنظیمات محیط محلی خود را برای بازتولید و اشکال‌زدایی بهتر آن مشکلات تطبیق دهید.

استفاده از داده‌های PageSpeed ​​Insights CrUX LCP

PageSpeed ​​Insights دسترسی به داده‌های CrUX را در بخش بالایی با عنوان « کشف آنچه کاربران واقعی شما تجربه می‌کنند» فراهم می‌کند. داده‌های آزمایشگاهی دقیق‌تر در بخش پایینی با عنوان « تشخیص مشکلات عملکرد» موجود است. اگر داده‌های CrUX برای وب‌سایت شما در دسترس است، همیشه ابتدا روی داده‌های واقعی کاربر تمرکز کنید.

PageSpeed ​​Insights حداکثر چهار داده CrUX مختلف را نشان می‌دهد:

• داده تلفن همراه برای این آدرس اینترنتی
• داده‌های دسکتاپ برای این آدرس اینترنتی
• داده موبایل برای کل Origin
• داده‌های دسکتاپ برای کل Origin

می‌توانید این موارد را در کنترل‌های بالا و سمت راست بالای این بخش تغییر دهید. اگر یک URL داده‌های کافی برای نمایش در سطح URL نداشته باشد، اما داده‌هایی برای مبدا داشته باشد، PageSpeed ​​Insights همیشه داده‌های مبدا را نشان می‌دهد.

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

نگاه کردن به چهار دسته مختلف داده‌های CrUX می‌تواند به شما کمک کند تا بفهمید که آیا یک مشکل LCP مختص این صفحه است یا یک مشکل عمومی‌تر در کل سایت. به طور مشابه، می‌تواند نشان دهد که کدام نوع دستگاه‌ها دارای مشکلات LCP هستند.

استفاده از معیارهای تکمیلی PageSpeed ​​Insights CrUX

کسانی که به دنبال بهینه‌سازی LCP هستند، باید از زمان‌بندی‌های First Contentful Paint (FCP) و Time to First Byte (TTFB) نیز استفاده کنند، که معیارهای تشخیصی خوبی هستند و می‌توانند بینش‌های ارزشمندی در مورد LCP ارائه دهند.

TTFB زمانی است که بازدیدکننده شروع به پیمایش به یک صفحه می‌کند (برای مثال، کلیک روی یک لینک)، تا زمانی که اولین بایت‌های سند HTML دریافت می‌شوند. TTFB بالا می‌تواند دستیابی به LCP 2.5 ثانیه‌ای را چالش برانگیز یا حتی غیرممکن کند.

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

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

اختلاف زیاد بین TTFB و FCP می‌تواند نشان دهد که مرورگر نیاز به دانلود فایل‌های مسدودکننده رندر زیادی دارد. همچنین می‌تواند نشانه‌ای باشد که برای رندر کردن هرگونه محتوای معنادار، باید کار زیادی انجام دهد - نشانه کلاسیک سایتی که به شدت به رندر سمت کلاینت متکی است.

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

استفاده از داده‌های PageSpeed ​​Insights Lighthouse

بخش Lighthouse از PageSpeed ​​Insights راهنمایی‌هایی برای بهبود LCP ارائه می‌دهد، اما ابتدا باید بررسی کنید که آیا LCP ارائه شده به طور کلی با داده‌های واقعی کاربر ارائه شده توسط CrUX مطابقت دارد یا خیر. اگر Lighthouse و CrUX با هم اختلاف نظر داشته باشند، احتمالاً CrUX تصویر دقیق‌تری از تجربه کاربری شما ارائه می‌دهد. قبل از اقدام، مطمئن شوید که داده‌های CrUX شما برای صفحه شما است، نه منبع کامل آن.

اگر هم Lighthouse و هم CrUX مقادیر LCP را نشان دهند که نیاز به بهبود دارند، بخش Lighthouse می‌تواند راهنمایی‌های ارزشمندی در مورد راه‌های بهبود LCP ارائه دهد. از فیلتر LCP برای نمایش فقط ممیزی‌های مربوط به LCP به شرح زیر استفاده کنید:

علاوه بر فرصت‌های بهبود، اطلاعات تشخیصی نیز وجود دارد که ممکن است اطلاعات بیشتری برای کمک به تشخیص مشکل ارائه دهد. عنصر تشخیصی Largest Contentful Paint ، تفکیک مفیدی از زمان‌بندی‌های مختلفی که LCP را تشکیل داده‌اند، نشان می‌دهد:

انواع منابع LCP و زیربخش‌های آن نیز در CrUX موجود است.

در ادامه به بررسی این زیربخش‌ها خواهیم پرداخت.

شکست LCP

بهینه‌سازی برای LCP می‌تواند کار پیچیده‌تری باشد وقتی PageSpeed ​​Insights پاسخی در مورد چگونگی بهبود این معیار به شما نمی‌دهد. با وظایف پیچیده، معمولاً بهتر است آنها را به وظایف کوچک‌تر و قابل مدیریت‌تر تقسیم کنید و هر کدام را جداگانه بررسی کنید.

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

بیشتر بارگذاری‌های صفحه معمولاً شامل تعدادی درخواست شبکه هستند، اما برای شناسایی فرصت‌هایی برای بهبود LCP، باید با بررسی فقط دو مورد شروع کنید:

1. سند HTML اولیه
2. منبع LCP (در صورت وجود)

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

برای شناسایی منبع LCP، می‌توانید از ابزارهای توسعه‌دهنده (مانند PageSpeed ​​Insights که قبلاً در مورد آن بحث شد، Chrome DevTools یا WebPageTest ) برای تعیین عنصر LCP استفاده کنید. از آنجا می‌توانید URL (باز هم، در صورت لزوم) بارگذاری شده توسط عنصر را در یک آبشار شبکه‌ای از تمام منابع بارگذاری شده توسط صفحه مطابقت دهید.

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

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

زمان رسیدن به اولین بایت (TTFB)

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

تأخیر در بارگذاری منابع

زمان بین TTFB و زمانی که مرورگر شروع به بارگذاری منبع LCP می‌کند. اگر عنصر LCP برای رندر شدن نیازی به بارگذاری منبع نداشته باشد (برای مثال، اگر عنصر یک گره متنی رندر شده با فونت سیستم باشد)، این زمان 0 است.

مدت زمان بارگذاری منابع

مدت زمانی که طول می‌کشد تا خود منبع LCP بارگذاری شود. اگر عنصر LCP برای رندر شدن به بارگذاری منبع نیاز نداشته باشد، این زمان ۰ است.

تأخیر رندر عنصر

زمان بین اتمام بارگذاری منبع LCP و رندر شدن کامل عنصر LCP.

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

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

برای مثال، در آبشار شبکه‌ای قبلی، اگر اندازه فایل تصویر ما را با فشرده‌سازی بیشتر یا تغییر به فرمت بهینه‌تر (مانند AVIF یا WebP) کاهش می‌دادید، این کار مدت زمان بارگذاری منابع را کاهش می‌داد، اما در واقع LCP را بهبود نمی‌بخشید زیرا زمان فقط به زیربخش تأخیر رندر عنصر تغییر می‌کرد:

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

این مثال به روشن شدن این نکته کمک می‌کند که برای دستیابی به بهترین نتایج LCP، باید تمام این زیربخش‌ها را بهینه کنید.

زمان‌های بهینه زیربخش‌ها

برای بهینه‌سازی هر زیربخش از LCP، درک این نکته مهم است که تفکیک ایده‌آل این زیربخش‌ها در یک صفحه بهینه‌شده چگونه است.

از چهار زیربخش، دو بخش کلمه "تأخیر" را در نام خود دارند. این سرنخی است که شما می‌خواهید این زمان‌ها را تا حد امکان به صفر نزدیک کنید. دو بخش دیگر شامل درخواست‌های شبکه هستند که ذاتاً زمان‌بر هستند.

توجه داشته باشید که این تفکیک‌های زمانی، دستورالعمل هستند، نه قوانین سختگیرانه. اگر زمان‌های LCP در صفحات شما به طور مداوم در محدوده ۲.۵ ثانیه باشند، مهم نیست که نسبت‌های نسبی چقدر باشند. اما اگر زمان غیرضروری زیادی را در هر یک از بخش‌های «تأخیر» صرف می‌کنید، رسیدن به هدف ۲.۵ ثانیه‌ای به طور مداوم بسیار دشوار خواهد بود.

یک راه خوب برای درک تفکیک زمان LCP این است:

• بخش عمده‌ی زمان LCP باید صرف بارگذاری سند HTML و منبع LCP شود.
• هر زمانی قبل از LCP که یکی از این دو منبع بارگذاری نشود ، فرصتی برای بهبود است.

نحوه بهینه سازی هر بخش

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

چهار بخش بعدی، توصیه‌ها و بهترین شیوه‌ها را برای چگونگی بهینه‌سازی هر بخش ارائه می‌دهد. این توصیه‌ها به ترتیب ارائه شده‌اند و از بهینه‌سازی‌هایی شروع می‌شوند که احتمالاً بیشترین تأثیر را خواهند داشت.

۱. تأخیر در بارگذاری منابع را از بین ببرید

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

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

به طور کلی، دو عامل وجود دارد که بر سرعت بارگذاری یک منبع LCP تأثیر می‌گذارد:

• وقتی منبع کشف شد.
• چه اولویتی به منبع داده شده است.

بهینه‌سازی هنگام کشف منبع

برای اطمینان از اینکه منبع LCP شما در اسرع وقت شروع به بارگیری می‌کند، بسیار مهم است که منبع در پاسخ اولیه سند HTML توسط اسکنر پیش‌بارگذاری مرورگر قابل کشف باشد. به عنوان مثال، در موارد زیر، مرورگر می‌تواند با اسکن پاسخ سند HTML، منبع LCP را کشف کند:

• عنصر LCP یک عنصر <img> است و ویژگی‌های src یا srcset آن در کد HTML اولیه وجود دارند.
• عنصر LCP به یک تصویر پس‌زمینه CSS نیاز دارد، اما آن تصویر با استفاده از <link rel="preload"> در نشانه‌گذاری HTML (یا با استفاده از یک سرصفحه Link ) از قبل بارگذاری می‌شود.
• The LCP element is a text node that requires a web font to render, and the font is loaded using <link rel="preload"> in the HTML markup (or using a Link header).

در اینجا چند مثال آورده شده است که در آنها منبع LCP را نمی‌توان از اسکن پاسخ سند HTML کشف کرد:

• عنصر LCP یک <img> است که به صورت پویا با استفاده از جاوا اسکریپت به صفحه اضافه می‌شود.
• عنصر LCP به صورت تنبلانه‌ای با یک کتابخانه جاوا اسکریپت بارگذاری شده است که ویژگی‌های src یا srcset آن را پنهان می‌کند (اغلب به صورت data-src یا data-srcset ).
• عنصر LCP به یک تصویر پس زمینه CSS نیاز دارد.

در هر یک از این موارد، مرورگر قبل از اینکه بتواند منبع LCP را پیدا کند و شروع به بارگذاری آن کند، باید اسکریپت را اجرا کند یا stylesheet را اعمال کند - که معمولاً شامل انتظار برای پایان درخواست‌های شبکه است. این هرگز بهینه نیست.

برای حذف تأخیر غیرضروری در بارگذاری منابع، منبع LCP شما باید از منبع HTML قابل کشف باشد. در مواردی که منبع فقط از یک فایل CSS یا جاوا اسکریپت خارجی ارجاع داده می‌شود، منبع LCP باید با اولویت واکشی بالا از قبل بارگذاری شود، برای مثال:

<!-- Load the stylesheet that will reference the LCP image. -->
<link rel="stylesheet" href="/path/to/styles.css">

<!-- Preload the LCP image with a high fetchpriority so it starts loading with the stylesheet. -->
<link rel="preload" fetchpriority="high" as="image" href="/path/to/hero-image.webp" type="image/webp">

اولویتی که به منبع داده می‌شود را بهینه کنید

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

برای مثال، اگر loading="lazy" روی عنصر <img> خود تنظیم کنید، می‌توانید با استفاده از HTML، نمایش تصویر LCP خود را به تأخیر بیندازید. استفاده از lazy loading به این معنی است که منبع تا زمانی که layout تأیید نکند که تصویر در viewport قرار دارد، بارگذاری نمی‌شود و بنابراین ممکن است دیرتر از حالت عادی شروع به بارگذاری کند.

حتی بدون بارگذاری تنبل، تصاویر در ابتدا توسط مرورگرها با بالاترین اولویت بارگذاری نمی‌شوند، زیرا منابعی نیستند که رندر را مسدود کنند. می‌توانید با استفاده از ویژگی fetchpriority برای منابعی که می‌توانند از اولویت بالاتری بهره‌مند شوند، به مرورگر اطلاع دهید که کدام منابع از همه مهم‌تر هستند:

<img fetchpriority="high" src="/path/to/hero-image.webp">

It's a good idea to set fetchpriority="high" on an <img> element if you think it's likely to be your page's LCP element. However, setting a high priority on more than one or two images makes priority setting unhelpful in reducing LCP.

همچنین می‌توانید اولویت تصاویری را که ممکن است در اوایل پاسخ سند باشند اما به دلیل سبک‌بندی قابل مشاهده نیستند، مانند تصاویر موجود در اسلایدهای چرخشی که در هنگام شروع نمایش داده نمی‌شوند، کاهش دهید:

<img fetchpriority="low" src="/path/to/carousel-slide-3.webp">

اولویت‌زدایی از منابع خاص می‌تواند پهنای باند بیشتری را در اختیار منابعی قرار دهد که به آن نیاز بیشتری دارند - اما مراقب باشید. همیشه اولویت منابع را در DevTools بررسی کنید و تغییرات را با ابزارهای آزمایشگاهی و میدانی آزمایش کنید.

بعد از اینکه اولویت منابع LCP و زمان کشف آنها را بهینه کردید، نمودار آبشاری شبکه شما باید به این شکل باشد (که منبع LCP همزمان با اولین منبع شروع می‌شود):

۲. تأخیر رندر عنصر را حذف کنید

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

دلیل اصلی اینکه عنصر LCP نمی‌تواند بلافاصله پس از اتمام بارگذاری منبع خود رندر شود، این است که رندر به دلایل دیگری مسدود شده باشد:

• رندر کردن کل صفحه به دلیل وجود استایل‌شیت‌ها یا اسکریپت‌های همزمان در <head> که هنوز در حال بارگذاری هستند، مسدود شده است.
• بارگذاری منبع LCP به پایان رسیده است، اما عنصر LCP هنوز به DOM اضافه نشده است (منتظر بارگذاری برخی از کدهای جاوا اسکریپت است).
• این عنصر توسط کد دیگری پنهان شده است، مانند یک کتابخانه تست A/B که هنوز در حال تعیین آزمایشی است که کاربر باید در آن باشد.
• رشته اصلی به دلیل وظایف طولانی مسدود شده است و کار رندرینگ باید تا زمان اتمام آن وظایف طولانی منتظر بماند.

بخش‌های بعدی نحوه‌ی رسیدگی به رایج‌ترین علل تأخیر غیرضروری رندر عنصر را توضیح می‌دهند.

کاهش یا درون‌خطی کردن شیوه‌نامه‌های مسدودکننده‌ی رندر

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

برای رفع این مشکل، گزینه‌های شما عبارتند از:

• برای جلوگیری از درخواست شبکه اضافی، شیوه‌نامه را در HTML به صورت درون‌خطی قرار دهید؛ یا،
• اندازه برگه سبک را کاهش دهید.

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

در بیشتر موارد، بهترین راه برای اطمینان از اینکه شیوه‌نامه مانع از رندر عنصر LCP نمی‌شود، کاهش اندازه آن است تا از منبع LCP کوچکتر شود. این کار باید تضمین کند که برای اکثر بازدیدها، گلوگاه ایجاد نمی‌کند.

برخی از توصیه‌ها برای کاهش اندازه برگه سبک عبارتند از:

• حذف CSSهای بلااستفاده : از Chrome DevTools برای یافتن قوانین CSS که استفاده نمی‌شوند و می‌توانند حذف شوند (یا به تعویق بیفتند) استفاده کنید.
• CSS غیر ضروری را به تعویق بیندازید : فایل استایل خود را به سبک‌هایی که برای بارگذاری اولیه صفحه مورد نیاز هستند و سپس سبک‌هایی که می‌توانند به صورت تنبل بارگذاری شوند، تقسیم کنید.
• فشرده‌سازی و کوچک‌سازی CSS : برای استایل‌هایی که حیاتی هستند، مطمئن شوید که حجم انتقال آنها را تا حد امکان کاهش می‌دهید.

جاوا اسکریپت مسدود کننده رندر را به تعویق بیندازید یا درون خطی کنید

تقریباً هیچ‌وقت لازم نیست اسکریپت‌های همگام (اسکریپت‌هایی بدون ویژگی‌های async یا defer ) را به <head> صفحات خود اضافه کنید، و انجام این کار تقریباً همیشه تأثیر منفی بر عملکرد خواهد داشت.

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

<head>
  <script src="/path/to/main.js"></script>
</head>

<head>
  <script>
    // Inline script contents directly in the HTML.
    // IMPORTANT: only do this for very small scripts.
  </script>
</head>

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

رندر سمت سرور (SSR) فرآیندی است که منطق برنامه سمت کلاینت شما را روی سرور اجرا می‌کند و به درخواست‌های سند HTML با نشانه‌گذاری کامل HTML پاسخ می‌دهد.

از منظر بهینه‌سازی LCP، دو مزیت اصلی SSR وجود دارد:

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

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

گزینه‌ای مشابه SSR، تولید سایت استاتیک (SSG) یا پیش‌رندرینگ نام دارد. این فرآیند تولید صفحات HTML شما در یک مرحله ساخت است، نه بر اساس تقاضا. اگر پیش‌رندرینگ با معماری شما امکان‌پذیر باشد، عموماً انتخاب بهتری برای عملکرد است.

کارهای طولانی را تقسیم کنید

حتی اگر توصیه‌های قبلی را دنبال کرده باشید، و کد جاوا اسکریپت شما نه render-blocking باشد و نه مسئول رندر کردن عناصر شما باشد، باز هم می‌تواند LCP را به تأخیر بیندازد.

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

امروزه همه مرورگرها تصاویر را در نخ اصلی رندر می‌کنند، به این معنی که هر چیزی که نخ اصلی را مسدود کند، می‌تواند منجر به تأخیر غیرضروری در رندر عنصر نیز شود.

۳. کاهش مدت زمان بارگذاری منابع

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

• اندازه منبع را کاهش دهید.
• مسافتی را که منبع باید طی کند، کاهش دهید.
• کاهش رقابت برای پهنای باند شبکه.
• زمان شبکه را به طور کامل حذف کنید.

کاهش حجم منابع

منبع LCP یک صفحه (اگر صفحه‌ای داشته باشد) یا یک تصویر خواهد بود یا یک فونت وب. راهنماهای زیر به تفصیل در مورد نحوه کاهش اندازه هر دو توضیح می‌دهند:

• اندازه تصویر بهینه را ارائه دهید
• از فرمت‌های تصویر مدرن استفاده کنید
• فشرده‌سازی تصاویر
• کاهش اندازه فونت وب

کاهش مسافتی که منبع باید طی کند

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

CDN های تصویر به طور خاص بسیار مفید هستند زیرا نه تنها مسافتی را که منبع باید طی کند کاهش می‌دهند، بلکه به طور کلی اندازه منبع را نیز کاهش می‌دهند - و به طور خودکار تمام توصیه‌های کاهش اندازه از قبل را برای شما اجرا می‌کنند.

کاهش رقابت برای پهنای باند شبکه

حتی اگر اندازه منبع و مسافت طی شده توسط آن را کاهش داده باشید، اگر همزمان منابع زیادی را بارگذاری کنید، بارگذاری یک منبع می‌تواند مدت زمان زیادی طول بکشد. این مشکل به عنوان تداخل شبکه شناخته می‌شود.

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

زمان شبکه را به طور کامل حذف کنید

بهترین راه برای کاهش مدت زمان بارگذاری منابع، حذف کامل شبکه از فرآیند است. اگر منابع خود را با یک سیاست کنترل حافظه پنهان کارآمد ارائه دهید، بازدیدکنندگانی که بار دوم آن منابع را درخواست می‌کنند، از حافظه پنهان به آنها سرویس داده می‌شود - و مدت زمان بارگذاری منابع اساساً به صفر می‌رسد!

اگر منبع LCP شما یک فونت وب است، علاوه بر کاهش اندازه فونت وب ، باید در نظر بگیرید که آیا نیاز به مسدود کردن رندرینگ در هنگام بارگذاری منبع فونت وب دارید یا خیر. اگر مقدار font-display را روی هر چیزی غیر از auto یا block تنظیم کنید، متن همیشه در طول بارگذاری قابل مشاهده خواهد بود و LCP در صورت درخواست شبکه اضافی مسدود نمی‌شود.

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

۴. کاهش زمان اولین بایت

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

یکی از دلایل رایج کندی TTFB برای یک سایت سریع، بازدیدکنندگانی هستند که از طریق چندین ریدایرکت، مانند تبلیغات یا لینک‌های کوتاه شده، وارد می‌شوند. همیشه تعداد ریدایرکت‌هایی را که یک بازدیدکننده باید منتظر بماند، به حداقل برسانید.

یکی دیگر از دلایل رایج، زمانی است که محتوای ذخیره شده در حافظه پنهان (cache) نمی‌تواند از سرور لبه CDN استفاده شود و همه درخواست‌ها باید به سرور مبدا هدایت شوند. این اتفاق می‌تواند در صورتی رخ دهد که بازدیدکنندگان از پارامترهای URL منحصر به فرد برای تجزیه و تحلیل استفاده کنند - حتی اگر منجر به صفحات مختلف نشوند.

برای راهنمایی‌های خاص در مورد بهینه‌سازی TTFB، به راهنمای optimize TTFB مراجعه کنید.

نظارت بر خرابی LCP در جاوا اسکریپت

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

• بزرگترین API رنگ‌آمیزی محتوا
• API زمان‌بندی ناوبری
• API زمان‌بندی منابع

بسیاری از محصولات RUM از قبل با استفاده از این APIها، زیربخش‌ها را محاسبه می‌کنند. کتابخانه web-vitals نیز این زمان‌بندی‌های زیربخش LCP را در ساختار attribution گنجانده است و می‌توان برای نحوه محاسبه این موارد در جاوا اسکریپت به کد آن مراجعه کرد.

Chrome DevTools و Lighthouse نیز این زیربخش‌ها را همانطور که در تصاویر قبلی نشان داده شده است، اندازه‌گیری می‌کنند و شما را از محاسبه دستی آنها در جاوا اسکریپت هنگام استفاده از این ابزارها بی‌نیاز می‌کنند.

خلاصه

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

در سطح بالا، بهینه‌سازی LCP را می‌توان در چهار مرحله خلاصه کرد:

1. مطمئن شوید که منبع LCP در اسرع وقت شروع به بارگیری می‌کند.
2. مطمئن شوید که عنصر LCP به محض اتمام بارگذاری منبعش، می‌تواند رندر شود.
3. زمان بارگذاری منبع LCP را تا جایی که می‌توانید بدون کاهش کیفیت، کاهش دهید.
4. سند HTML اولیه را در اسرع وقت تحویل دهید.

اگر بتوانید این مراحل را در صفحات خود دنبال کنید، باید مطمئن باشید که یک تجربه بارگذاری بهینه را به کاربران خود ارائه می‌دهید و باید این را در نمرات LCP واقعی خود ببینید.