فرض کنید PageSpeed Insights را باز کرده اید و مقابل Largest Contentful Paint عدد 4.3 ثانیه دیده می شود. اولین توصیه ای که معمولا به ذهن می رسد این است: «تصویرها را فشرده کنیم.»
تصویر Hero را از JPEG به WebP تبدیل می کنید، حجم آن را از 350 کیلوبایت به 120 کیلوبایت می رسانید و دوباره تست می گیرید. LCP حالا 4.1 ثانیه است.
بهبود اتفاق افتاده، اما بسیار کمتر از چیزی که انتظار داشتید.
مشکل کجاست؟
ممکن است تصویر اصلی صفحه اصلا دیر دانلود نشود؛ مرورگر شاید دو ثانیه دیر متوجه وجود آن شود. ممکن است تصویر خیلی زود دانلود شده باشد اما JavaScript اجازه Render شدن آن را ندهد. ممکن است پاسخ HTML از سرور دیر برسد و بخش بزرگی از زمان LCP قبل از آنکه مرورگر حتی تصویر را ببیند از دست رفته باشد.
این مثال یکی از مهم ترین اصول بهینه سازی LCP را نشان می دهد:
LCP ضعیف یک مشکل واحد نیست. برای بهبود آن ابتدا باید بفهمید زمان دقیقا در کدام مرحله از مسیر بارگذاری از دست می رود.
LCP یا Largest Contentful Paint یکی از سه معیار اصلی Core Web Vitals است و مدت زمانی را اندازه گیری می کند که طول می کشد بزرگ ترین عنصر محتوایی قابل مشاهده در Viewport کاربر Render شود. برای تجربه خوب، هدف این است که LCP در صدک 75 بازدیدهای واقعی، به تفکیک موبایل و دسکتاپ، حداکثر 2.5 ثانیه باشد.
در این مقاله فقط نمی خواهیم بدانیم LCP چیست. هدف این است که بتوانیم LCP ضعیف را تحلیل کنیم، LCP Element را پیدا کنیم، زمان آن را به بخش های قابل تشخیص بشکنیم و براساس علت واقعی، راه حل مناسبی انتخاب کنیم.
LCP چیست؟
LCP مخفف Largest Contentful Paint است.
این معیار زمان Render شدن بزرگ ترین عنصر محتوایی قابل مشاهده در Viewport را نسبت به شروع بارگذاری صفحه اندازه گیری می کند.
هدف LCP پاسخ دادن به یک سوال ساده اما مهم است:
کاربر چه زمانی می تواند بخش اصلی و معنادار صفحه را ببیند؟
در بسیاری از صفحات، عناصر کوچک مثل لوگو، آیکون، منو یا Skeleton خیلی زود نمایش داده می شوند. اما نمایش چند عنصر کوچک لزوما به این معنی نیست که کاربر احساس می کند صفحه بارگذاری شده است.
مثلا در صفحه محصول ممکن است هدر در کمتر از یک ثانیه ظاهر شود، اما تصویر اصلی محصول سه ثانیه بعد نمایش داده شود. در یک Landing Page ممکن است Navigation آماده باشد، اما Hero Image و تیتر اصلی با تاخیر ظاهر شوند.
LCP تلاش می کند آن لحظه ای را اندازه گیری کند که بخش بزرگ و معنادار محتوا در اختیار کاربر قرار گرفته است. Chrome برای این کار بزرگ ترین عنصر محتوایی Render شده در Viewport را دنبال می کند.
LCP یکی از سه Core Web Vital فعلی در کنار INP و CLS است. LCP Loading Performance را می سنجد، INP Responsiveness را بررسی می کند و CLS روی Visual Stability تمرکز دارد. اگر هنوز با رابطه این سه معیار آشنا نیستید، بهتر است LCP را در چارچوب کلی Core Web Vitals ببینید، نه به عنوان یک عدد مستقل.
LCP خوب چند ثانیه است؟
محدوده های استاندارد LCP به شکل زیر هستند:
| وضعیت | مقدار LCP |
|---|---|
| خوب | 2.5 ثانیه یا کمتر |
| نیازمند بهبود | بیشتر از 2.5 تا 4 ثانیه |
| ضعیف | بیشتر از 4 ثانیه |
این ارزیابی برای تجربه واقعی کاربران بر اساس صدک 75 انجام می شود. یعنی برای قرار گرفتن در محدوده Good، هدف این نیست که فقط یک اجرای آزمایشگاهی زیر 2.5 ثانیه باشد؛ بخش بزرگی از کاربران واقعی باید چنین تجربه ای داشته باشند. موبایل و دسکتاپ نیز باید جداگانه بررسی شوند.
به عنوان مثال اگر صد کاربر واقعی صفحه را باز کرده باشند و LCP صدک 75 برابر 2.3 ثانیه باشد، وضعیت LCP در محدوده خوب قرار می گیرد. اگر همین مقدار 3.2 ثانیه باشد، صفحه در محدوده Needs Improvement قرار خواهد گرفت.
این موضوع اهمیت زیادی دارد، چون یک تست روی لپ تاپ قدرتمند و اینترنت سریع نمی تواند نماینده تمام کاربران باشد.
LCP دقیقا چه چیزی را اندازه گیری می کند؟
یکی از اشتباهات رایج این است که LCP را با «زمان کامل شدن لود صفحه» برابر بدانیم.
LCP نمی پرسد تمام تصاویر، اسکریپت ها، Analytics، Widgetها و فایل های صفحه چه زمانی به طور کامل دانلود شدند.
سوال آن محدودتر و کاربرمحورتر است:
بزرگ ترین عنصر محتوایی قابل مشاهده چه زمانی Render شد؟
به همین دلیل ممکن است LCP یک صفحه 2 ثانیه باشد، در حالی که دانلود بعضی Resourceهای پایین صفحه تا ثانیه 6 ادامه داشته باشد.
این اتفاق لزوما مشکل نیست.
اگر کاربر محتوای اصلی را سریع ببیند، نیازی نیست تمام Resourceهای غیرضروری در همان چند لحظه ابتدایی دانلود شوند.
در واقع یکی از اصول Performance خوب همین است: منابعی که برای تجربه اولیه اهمیت ندارند نباید برای پهنای باند و پردازش با Resourceهای حیاتی رقابت کنند.
چه عناصری می توانند LCP Element باشند؟
LCP Element همیشه یک تصویر نیست.
براساس تعریف فعلی Largest Contentful Paint، انواع مشخصی از عناصر می توانند به عنوان LCP Candidate در نظر گرفته شوند؛ از جمله تصاویر <img>، تصاویر داخل SVG، ویدیوها با Poster یا Frame قابل استفاده، بعضی CSS Background Imageها و عناصر Block که متن در آن ها نمایش داده می شود.
در عمل، نمونه های متداول چنین هستند:
| نوع صفحه | LCP Element محتمل |
|---|---|
| صفحه محصول | تصویر اصلی محصول |
| صفحه دسته بندی | بنر یا Hero Image |
| مقاله وبلاگ | تیتر اصلی، متن ابتدایی یا تصویر شاخص |
| Landing Page | Hero Image یا Hero Heading |
| صفحه خدمات | تصویر معرفی سرویس یا بلوک متن Hero |
| صفحه خبری | تصویر اصلی خبر یا تیتر بزرگ |
یک نکته مهم این است که LCP Element می تواند در طول Load تغییر کند.
مثلا مرورگر ابتدا تیتر <h1> را Render می کند و آن را بزرگ ترین عنصر می داند. کمی بعد Hero Image نمایش داده می شود و چون مساحت بیشتری دارد، تصویر تبدیل به LCP Candidate جدید می شود. web.dev نیز توضیح می دهد که مرورگر با Render شدن عناصر بزرگ تر می تواند Entry جدیدی برای Largest Contentful Paint ثبت کند.
پس نباید براساس ظاهر صفحه حدس بزنید LCP Element چیست. آن را اندازه گیری کنید.
چگونه LCP Element صفحه را پیدا کنیم؟
قبل از هر Optimization باید بدانیم دقیقا چه عنصری را بهینه می کنیم.
برای شروع، PageSpeed Insights و Chrome DevTools هر دو مفید هستند.
در Lighthouse و ابزارهای Performance می توانید LCP و عنصر مرتبط با آن را مشاهده کنید. Chrome DevTools نیز در Performance Panel اطلاعات مربوط به Core Web Vitals و LCP را نشان می دهد و در Insights امکان بررسی Breakdown و علت های احتمالی تاخیر را فراهم کرده است.
یک Workflow منطقی این است:
| مرحله | کاری که انجام می دهید |
|---|---|
| 1 | URL را در PageSpeed Insights بررسی کنید |
| 2 | ابتدا Field Data مربوط به LCP را ببینید |
| 3 | Mobile و Desktop را جداگانه بررسی کنید |
| 4 | Lab Data و Lighthouse را باز کنید |
| 5 | LCP Element را شناسایی کنید |
| 6 | LCP Breakdown یا Network Waterfall را بررسی کنید |
| 7 | مشخص کنید بیشترین زمان در کدام بخش مصرف می شود |
| 8 | فقط همان Bottleneck را هدف قرار دهید |
همین مرحله آخر تفاوت بهینه سازی حرفه ای و تغییرات تصادفی است.
اگر مشکل TTFB است، فشرده کردن تصویر Hero اولویت اول نیست.
اگر Resource Load Delay دو ثانیه است، خرید سرور قوی تر ممکن است مشکل اصلی را حل نکند.
اگر Resource دانلود شده ولی Render Delay بسیار زیاد است، باید CSS، JavaScript یا Rendering را بررسی کنید.
چرا LCP سایت ضعیف می شود؟
LCP ضعیف معمولا نتیجه یک زنجیره از تاخیرها است، نه یک عامل منفرد.
فرض کنید LCP صفحه برابر 4 ثانیه است.
این چهار ثانیه ممکن است چنین ساخته شده باشد:
| بخش | زمان |
|---|---|
| دریافت اولین بایت HTML | 900ms |
| تاخیر قبل از شروع دانلود تصویر | 1,400ms |
| دانلود تصویر | 500ms |
| تاخیر تا Render تصویر | 1,200ms |
| LCP نهایی | 4,000ms |
در این مثال حجم تصویر فقط 500 میلی ثانیه از کل زمان را تشکیل می دهد.
اگر حجم تصویر را نصف کنیم و مدت دانلود به 250 میلی ثانیه برسد، LCP هنوز حدود 3.75 ثانیه خواهد بود.
یعنی تصویر را واقعا بهینه کرده ایم، اما مشکل اصلی صفحه را حل نکرده ایم.
داده های منتشر شده توسط web.dev نیز همین سوءبرداشت را به چالش می کشند. در تحلیل داده های واقعی، مدت دانلود تصویر در بسیاری از صفحات حتی کوتاه ترین بخش LCP بوده و زمان قابل توجهی در TTFB و Load Delay مصرف شده است.
به همین دلیل بهترین مدل تحلیل، تقسیم LCP به چهار Subpart است.
چهار بخش اصلی LCP را بشناسید
زمان نهایی LCP را می توان به چهار بخش تقسیم کرد:
| بخش | معنی |
|---|---|
| TTFB | از شروع Navigation تا دریافت اولین بایت HTML |
| Resource Load Delay | از TTFB تا شروع دانلود Resource مربوط به LCP |
| Resource Load Duration | مدت دانلود خود Resource |
| Element Render Delay | از پایان دانلود Resource تا Render شدن LCP Element |
اگر LCP Element برای Render شدن Resource جداگانه ای نیاز نداشته باشد، مثلا یک بلوک متن با فونت سیستمی باشد، بخش های مربوط به Resource می توانند صفر باشند. این مدل چهار بخشی در راهنمای web.dev و ابزارهای فعلی Chrome برای تشخیص علت LCP استفاده می شود.
TTFB؛ صفحه از همان ابتدا چقدر دیر شروع می شود؟
TTFB مخفف Time to First Byte است.
این زمان از لحظه شروع درخواست صفحه تا زمانی محاسبه می شود که مرورگر اولین بایت پاسخ HTML را دریافت کند.
اگر TTFB زیاد باشد، تمام مراحل بعدی نیز دیرتر شروع می شوند.
مرورگر قبل از دریافت HTML نمی تواند ساختار صفحه را Parse کند، بسیاری از Resourceها را کشف کند یا تصمیم بگیرد چه چیزی باید Render شود.
علت TTFB بالا می تواند در لایه های مختلف باشد: پردازش سنگین Backend، دیتابیس کند، Cache نامناسب، Redirect قبل از Document اصلی، فاصله زیاد جغرافیایی سرور، زیرساخت ضعیف یا مشکلات شبکه.
فرض کنید هدف LCP شما 2.5 ثانیه است و HTML بعد از 1.6 ثانیه به مرورگر می رسد. قبل از اینکه مرورگر تصویر Hero را پیدا کند، بخش بزرگی از بودجه زمانی خود را مصرف کرده اید.
اما کاهش TTFB به تنهایی نیز تضمین نمی کند LCP خوب شود. ممکن است HTML خیلی سریع برسد ولی تصویر LCP دو ثانیه بعد کشف شود.
پس TTFB اولین حلقه زنجیره است، نه تمام زنجیره.
Resource Load Delay؛ مرورگر چه زمانی Resource اصلی را پیدا می کند؟
این بخش یکی از مهم ترین و در عین حال کمتر دیده شده ترین عوامل LCP است.
Resource Load Delay فاصله بین دریافت HTML و زمانی است که مرورگر دانلود Resource مربوط به LCP را شروع می کند.
ایده آل این است که این فاصله تا حد امکان کم باشد.
اگر تصویر Hero مستقیما در HTML وجود داشته باشد، Preload Scanner مرورگر می تواند خیلی زود آن را پیدا کند:
<img
src="/images/hero.webp"
width="1200"
height="700"
alt="..."
>اما تصور کنید تصویر فقط بعد از اجرای JavaScript ساخته شود:
<div id="hero"></div>
<script>
// بعد از اجرای JavaScript تصویر به DOM اضافه می شود
</script>مرورگر ابتدا HTML را می گیرد، JavaScript را دانلود و اجرا می کند و تازه بعد از آن متوجه می شود تصویری وجود دارد که باید دانلود شود.
همین تاخیر ممکن است صدها میلی ثانیه یا حتی چند ثانیه به LCP اضافه کند.
web.dev سه نمونه مهم برای Discovery دیرهنگام Resource را مشخص می کند: تصویرهایی که با JavaScript به صفحه اضافه می شوند، پیاده سازی های Lazy Load که src یا srcset را پشت data-src مخفی می کنند و تصاویر LCP که فقط در CSS Background تعریف شده اند.
این یعنی گاهی بهترین Optimization برای تصویر LCP کم کردن حجم آن نیست؛ زودتر قابل کشف کردن آن است.
Resource Load Duration؛ خود فایل چقدر دیر دانلود می شود؟
بعد از اینکه Browser Resource را پیدا کرد، مرحله دانلود شروع می شود.
Resource Load Duration مدت زمانی است که دریافت خود Resource طول می کشد.
اگر LCP یک تصویر باشد، این بخش می تواند تحت تاثیر حجم فایل، ابعاد تصویر، فرمت، سرعت شبکه، CDN و Cache قرار بگیرد.
اینجاست که سئو تصاویر و Image Optimization اهمیت مستقیم پیدا می کنند.
اما Optimization حرفه ای تصویر به معنی «کمترین حجم ممکن» نیست.
اگر تصویر را آن قدر Compress کنید که کیفیت Hero Image یک فروشگاه لوکس از بین برود، شاید چند کیلوبایت ذخیره کرده باشید اما تجربه بصری را خراب کرده اید.
هدف، پیدا کردن تعادل مناسب بین کیفیت، ابعاد و حجم است.
یک تصویر 2400 پیکسلی نباید بدون دلیل برای نمایش در Container 600 پیکسلی به موبایل فرستاده شود. Responsive Images با srcset و sizes می توانند به مرورگر اجازه دهند Resource متناسب با Viewport را انتخاب کند.
فرمت های مدرن مانند WebP و AVIF نیز در بسیاری از سناریوها امکان کاهش حجم را فراهم می کنند، اما انتخاب فرمت باید با توجه به محتوای تصویر و نتیجه واقعی Compression انجام شود. Chrome Performance Insights نیز بهینه سازی Delivery تصاویر، Format و Sizing را از جمله فرصت های قابل تشخیص معرفی می کند.
Element Render Delay؛ فایل آمده، چرا هنوز چیزی دیده نمی شود؟
گاهی Resource خیلی سریع دانلود می شود، اما LCP همچنان دیر اتفاق می افتد.
این همان جایی است که Element Render Delay اهمیت پیدا می کند.
Render Delay فاصله بین پایان دانلود Resource و Render کامل LCP Element است.
ممکن است تصویر Hero در 1.4 ثانیه کاملا دانلود شده باشد، اما تا 3 ثانیه روی صفحه دیده نشود.
چرا؟
ممکن است Stylesheet هنوز Rendering را Block کند.
ممکن است یک Script همگام در <head> اجرا شود.
ممکن است LCP Element منتظر اجرای JavaScript باشد تا وارد DOM شود.
ممکن است A/B Testing ابتدا بخش Hero را مخفی نگه دارد.
ممکن است Main Thread با Long Taskهای JavaScript اشغال باشد و فرصت Paint پیدا نکند.
راهنمای web.dev دقیقا این موارد را از دلایل متداول Element Render Delay معرفی می کند.
پس اگر تصویر کامل دانلود شده ولی دیر نمایش داده می شود، فشرده کردن دوباره تصویر تقریبا به مسئله اصلی ربطی ندارد.
باید مسیر Render بررسی شود.
چگونه LCP را مرحله به مرحله بهبود دهیم؟
بهترین روش این نیست که ده تکنیک Performance را هم زمان اجرا کنیم.
یک روش حرفه ای چنین است:
اندازه گیری → تشخیص Subpart ضعیف → اصلاح علت → اندازه گیری مجدد
اگر از این فرایند پیروی کنید، هر تغییر یک هدف روشن خواهد داشت.
1. ابتدا TTFB را بررسی کنید
اگر TTFB سهم بزرگی از زمان LCP دارد، قبل از دستکاری Hero Image باید مشکل اولیه Document را بررسی کنید.
در این شرایط مواردی مانند Cache صفحه، سرعت Backend، Queryهای دیتابیس، CDN، Edge Caching و Redirectها ارزش بررسی دارند.
برای سایت های Dynamic، Full Page Cache یا Edge Cache می تواند در بعضی معماری ها زمان تولید HTML را به شکل محسوسی کاهش دهد.
اما هیچ نسخه عمومی وجود ندارد.
مثلا سایتی که محتوای کاملا شخصی سازی شده دارد نمی تواند همان Cache Strategy یک وبلاگ Static را استفاده کند.
هدف این است که بفهمید چرا Document اصلی دیر پاسخ می دهد.
در PageSpeed Insights، TTFB در داده واقعی نیز گزارش می شود، اما باید به یاد داشت که TTFB یک Core Web Vital مستقل نیست. PSI آن را به عنوان یک Metric تشخیصی ارائه می کند.
2. LCP Resource را از HTML قابل کشف کنید
اگر LCP تصویر است، یکی از بهترین حالت ها این است که URL تصویر در Markup اولیه وجود داشته باشد.
مثال:
<img
src="/hero.webp"
width="1280"
height="720"
alt="تصویر اصلی صفحه"
>در این حالت Preload Scanner مرورگر می تواند حتی هنگام Parse شدن Document Resource را پیدا کند.
اما اگر URL تصویر داخل JavaScript یا Stylesheet خارجی پنهان شده باشد، Discovery ممکن است عقب بیفتد.
قاعده کلی ساده است:
Resource حیاتی برای LCP را پشت زنجیره ای از Dependencyها پنهان نکنید، مگر اینکه معماری صفحه واقعا چنین چیزی را ضروری کند.
web.dev توصیه می کند LCP Resource تا حد امکان از HTML Source قابل کشف باشد.
3. تصویر LCP را Lazy Load نکنید
Lazy Loading تکنیک بسیار مفیدی است، اما استفاده اشتباه از آن می تواند LCP را بدتر کند.
هدف Lazy Loading این است که دانلود تصاویر خارج از Viewport را تا زمانی که کاربر به آن ها نزدیک نشده عقب بیندازد.
این رفتار برای تصویر پایین یک مقاله منطقی است.
اما Hero Image که در اولین Viewport قرار دارد دقیقا برعکس است: می خواهیم هرچه زودتر دانلود شود.
برای همین web.dev توصیه می کند تصاویر قابل مشاهده در Viewport اولیه، مخصوصا LCP Image، به شکل Eager بارگذاری شوند و loading="lazy" روی آن ها قرار نگیرد.
نمونه مناسب:
<img
src="/hero.webp"
width="1200"
height="700"
loading="eager"
alt="..."
>در واقع اگر loading را ننویسید، رفتار Default تصویر Eager است. استفاده صریح از loading="eager" بیشتر زمانی مفید است که CMS یا Library شما به شکل خودکار Lazy Loading اضافه می کند.
نکته مهم دیگر این است که:
loading="lazy"
fetchpriority="high"یک تناقض مفهومی ایجاد می کند.
Fetch Priority نمی تواند Lazy Loading را خنثی کند. تصویر همچنان تا زمان مناسب برای Lazy Load منتظر می ماند و بعد با Priority بالا Fetch می شود. web.dev نیز به این رفتار اشاره می کند.
4. در صورت نیاز از fetchpriority=”high” استفاده کنید
Browser خودش برای Resourceها Priority تعیین می کند، اما همیشه از همان ابتدا نمی داند کدام تصویر مهم ترین تصویر صفحه است.
برای یک تصویر LCP مهم می توان از Fetch Priority استفاده کرد:
<img
src="/hero.webp"
width="1200"
height="700"
fetchpriority="high"
alt="..."
>این Attribute به Browser می گوید این Resource اهمیت بالاتری دارد.
web.dev استفاده از fetchpriority="high" را برای تصاویر مهمی مانند LCP Image یکی از کاربردهای اصلی Fetch Priority معرفی می کند.
اما نکته حرفه ای این است که High Priority یک Resource محدود و ارزشمند است.
اگر روی پنج تصویر، سه Font، دو Script و چهار Preload اعلام کنید که همه چیز «High» است، عملا مفهوم Priority را ضعیف کرده اید.
Priority زمانی معنا دارد که Resourceهای واقعا حیاتی از Resourceهای کم اهمیت تر متمایز شوند.
5. چه زمانی از preload استفاده کنیم؟
Preload و Fetch Priority یک چیز نیستند.
preload به Browser کمک می کند Resource را زودتر کشف کند.
fetchpriority به Browser Hint می دهد Resource کشف شده را با چه اولویتی Fetch کند.
برای مثال اگر Hero Image به عنوان CSS Background تعریف شده باشد، Browser برای پیدا کردن آن باید ابتدا CSS را دانلود و Parse کند.
در چنین شرایطی Preload می تواند Discovery را جلو بیندازد:
<link
rel="preload"
as="image"
href="/hero.webp"
fetchpriority="high"
>web.dev برای LCP Resourceهایی که از HTML مستقیم قابل کشف نیستند، مانند CSS Background، استفاده مناسب از Preload همراه با Fetch Priority را پیشنهاد می کند.
اما Preload را نباید به تمام تصاویر صفحه اضافه کرد.
هر Preload به Browser می گوید:
«این Resource آن قدر مهم است که همین حالا برای آن پهنای باند اختصاص بده.»
اگر ده ها Resource را Preload کنید، Browser مجبور می شود منابع زیادی را هم زمان با Resource اصلی Fetch کند. نتیجه ممکن است دقیقا خلاف چیزی باشد که می خواستید.
Preload یک ابزار جراحی است، نه یک تنظیم عمومی.
6. تصویر LCP را با ابعاد درست ارسال کنید
یکی از ساده ترین اتلاف های Bandwidth زمانی اتفاق می افتد که تصویر بسیار بزرگ تر از اندازه نمایش داده شده ارسال شود.
مثلا Container موبایل 390 پیکسل عرض دارد ولی Browser مجبور است تصویر 2000 پیکسلی دانلود کند.
Responsive Images می توانند این مشکل را حل کنند:
<img
src="/hero-1280.webp"
srcset="
/hero-640.webp 640w,
/hero-960.webp 960w,
/hero-1280.webp 1280w
"
sizes="100vw"
width="1280"
height="720"
fetchpriority="high"
alt="..."
>با این ساختار Browser می تواند براساس Viewport و Device Pixel Ratio گزینه مناسب تری انتخاب کند.
این Optimization مخصوصا در موبایل اهمیت زیادی دارد؛ چون کاربر ممکن است هم صفحه کوچک تر و هم شبکه کندتری داشته باشد.
7. عرض و ارتفاع تصویر را مشخص کنید
قرار دادن width و height فقط مربوط به LCP نیست و به جلوگیری از Layout Shift نیز کمک می کند.
نمونه:
<img
src="/hero.webp"
width="1200"
height="700"
alt="..."
>Browser قبل از دانلود تصویر نسبت ابعاد را می داند و می تواند فضای مناسبی برای آن رزرو کند.
اگر ابعاد مشخص نباشند، صفحه ممکن است پس از دریافت تصویر جابه جا شود و علاوه بر Loading Performance، CLS نیز تحت تاثیر قرار بگیرد.
در نتیجه Optimization تصویر را بهتر است جدا از تجربه کلی صفحه نبینیم.
8. Render-blocking Resourceها را بررسی کنید
گاهی Network Waterfall نشان می دهد Hero Image زود دانلود شده ولی Paint آن دیر رخ داده است.
در این حالت CSS و JavaScript را بررسی کنید.
Stylesheetهای حیاتی برای Render ضروری هستند، اما فایل CSS بزرگی که شامل Style تمام صفحات سایت است می تواند Rendering صفحه فعلی را عقب بیندازد.
Scriptهای Sync در Head نیز می توانند Parser یا Main Thread را درگیر کنند.
Chrome Performance Insights در نسخه های فعلی خود Insight مستقلی برای Render-blocking Requestها دارد و این Resourceها را به عنوان یکی از عوامل بالقوه تاخیر LCP نمایش می دهد.
هدف این نیست که تمام CSS و JavaScript را حذف کنیم.
هدف این است که Resource حیاتی را از Resource غیرضروری برای First Render جدا کنیم.
9. Client-side Rendering را با دقت بررسی کنید
Frameworkهای JavaScript امکانات زیادی ایجاد کرده اند، اما معماری Rendering می تواند تاثیر بزرگی بر LCP داشته باشد.
اگر HTML اولیه تقریبا خالی باشد و Browser برای ساخت Hero Section مجبور باشد Bundle JavaScript را دانلود، Parse و Execute کند، LCP Resource ممکن است بسیار دیر کشف شود.
این زنجیره ممکن است چنین باشد:
HTML → JavaScript Bundle → Execute → API Request → Component Render → Image Discovery → Image Download → Paint
حالا آن را با حالت زیر مقایسه کنید:
HTML → Image Discovery → Download → Paint
هر مرحله اضافی لزوما بد نیست، اما هزینه دارد.
در پروژه هایی که SEO و Loading Performance اهمیت بالایی دارند، Server-side Rendering، Static Rendering یا Streaming می توانند بسته به Framework و معماری پروژه راهکارهای مناسبی باشند.
اما تصمیم معماری را نباید فقط براساس LCP گرفت. Maintainability، Personalization، Data Freshness و Complexity نیز اهمیت دارند.
10. Main Thread را قبل از Render آزاد نگه دارید
ممکن است Network مشکلی نداشته باشد اما Main Thread گرفتار Long Task باشد.
Browser برای Parse HTML، Style Calculation، Layout، JavaScript و Paint از منابع پردازشی استفاده می کند.
اگر یک Script سنگین درست در لحظه ای اجرا شود که LCP Element باید Paint شود، Render می تواند عقب بیفتد.
در چنین شرایطی باید بررسی شود آیا JavaScript اولیه واقعا برای نمایش اولین Viewport ضروری است یا خیر.
Third-party Scriptها نیز گاهی بخش بزرگی از هزینه CPU را ایجاد می کنند.
Analytics، A/B Testing، Chat Widget، Advertising، Heatmap و Tagهای متعدد هرکدام به تنهایی شاید کوچک باشند، اما در کنار هم می توانند Main Thread را شلوغ کنند.
Chrome Performance Insights امکان مشاهده Third-partyها، Network Dependency Tree و Render-blocking Requestها را فراهم می کند و برای پیدا کردن چنین Bottleneckهایی مفید است.
اگر LCP Element متن باشد چه؟
تمام راهکارهای LCP به تصویر مربوط نیستند.
فرض کنید بزرگ ترین عنصر صفحه تیتر اصلی باشد.
در چنین حالتی ممکن است Font Loading روی زمان Render تاثیر بگذارد.
اگر متن تا زمان دانلود Web Font مخفی بماند، Browser شاید نتواند LCP Element را به موقع نمایش دهد.
در این سناریو مواردی مانند Font Loading Strategy، Preload محدود Font حیاتی، استفاده از font-display مناسب، Subset کردن Font و کاهش تعداد Weightها ارزش بررسی دارند.
اما باز هم قانون اصلی برقرار است:
اول اندازه گیری، بعد تغییر.
اگر Font فقط 50 میلی ثانیه از Render Delay را تشکیل می دهد، صرف روزها برای تغییر Font Architecture احتمالا بهترین اولویت نیست.
LCP تصویر CSS Background است؛ چه کنیم؟
CSS Background Image می تواند LCP Element باشد.
چالش اصلی این است که Browser معمولا URL آن را بعد از دریافت و Parse شدن CSS کشف می کند.
فرض کنید:
.hero {
background-image: url("/hero.webp");
}برای کشف این تصویر، Browser ابتدا باید HTML را دریافت کند، Stylesheet را پیدا کند، CSS را دانلود کند و Declaration را Parse کند.
اگر Hero Image نقش LCP دارد، می توان براساس شرایط آن را Preload کرد:
<link
rel="preload"
as="image"
href="/hero.webp"
fetchpriority="high"
>یا اگر طراحی اجازه می دهد، از <img> یا <picture> استفاده کرد تا Browser Resource را مستقیما از HTML کشف کند.
هیچ کدام از این گزینه ها به شکل مطلق برای تمام سایت ها بهتر نیستند. تصمیم باید براساس Design، Semantics و Waterfall واقعی صفحه گرفته شود.
آیا Preload همیشه LCP را بهتر می کند؟
خیر.
Preload می تواند بسیار موثر باشد، اما اگر Resource از قبل زود کشف می شود، ممکن است مزیت بزرگی ایجاد نکند.
بدتر از آن، Preload اشتباه می تواند Network Contention ایجاد کند.
فرض کنید Hero Image از HTML اولیه در همان لحظات اول کشف می شود و Priority مناسبی دارد. اضافه کردن Preload ممکن است فقط Markup را پیچیده تر کند بدون اینکه سود معناداری داشته باشد.
یا ممکن است تصویری را Preload کنید که در نسخه موبایل اصلا نمایش داده نمی شود.
در این صورت پهنای باند کاربر برای Resource غیرضروری مصرف شده است.
پس قبل از Preload این سوال را بپرسید:
آیا مشکل من واقعا Discovery دیرهنگام Resource است؟
اگر پاسخ منفی است، ابزار دیگری لازم دارید.
چرا Lazy Loading می تواند LCP را خراب کند؟
Lazy Loading ذاتا برای به تاخیر انداختن Fetch طراحی شده است.
این رفتار برای Resource خارج از Viewport عالی است.
اما LCP معمولا در Viewport اولیه قرار دارد.
اگر روی تصویر Hero بنویسید:
<img
src="/hero.webp"
loading="lazy"
alt="..."
>Browser ممکن است Fetch را نسبت به حالت Eager دیرتر آغاز کند.
web.dev تاکید می کند Hero Image و تصاویر محتمل برای LCP نباید Lazy Load شوند و بهتر است Lazy Loading روی تصاویر خارج از Viewport متمرکز شود.
این نکته مخصوصا برای CMSها اهمیت دارد.
بعضی افزونه ها به صورت خودکار loading="lazy" را به تمام تصاویر اضافه می کنند. اگر استثنایی برای تصویر اصلی صفحه نداشته باشند، Optimization عمومی آن ها می تواند LCP را بدتر کند.
آیا کم کردن حجم تصویر همیشه بهترین راه بهبود LCP است؟
خیر.
این شاید مهم ترین سوءبرداشت درباره LCP باشد.
کم کردن حجم تصویر زمانی بیشترین تاثیر را دارد که Resource Load Duration بخش بزرگی از زمان باشد.
اما اگر Resource Load Delay یا Render Delay بیشتر باشد، Image Compression بازده محدودی خواهد داشت.
web.dev با بررسی داده های واقعی نیز نشان داده است که در بسیاری از صفحات، مدت دانلود تصویر کوتاه تر از بخش هایی مانند TTFB و Load Delay بوده است.
یک متخصص Performance نباید از روی نوع Element راه حل را حدس بزند.
تصویر LCP است؟
این فقط می گوید «چه چیزی دیر نمایش داده شده»، نه اینکه «چرا دیر نمایش داده شده».
Field LCP و Lab LCP چه تفاوتی دارند؟
LCP را می توان در محیط واقعی کاربران و محیط آزمایشگاهی اندازه گیری کرد.
Field LCP براساس تجربه کاربران واقعی است.
Lab LCP براساس اجرای کنترل شده و شبیه سازی شده ابزارهایی مانند Lighthouse محاسبه می شود.
PageSpeed Insights هر دو نوع داده را ارائه می کند. Field Data آن از Chrome User Experience Report یا CrUX تامین می شود و تجربه کاربران واقعی در یک دوره 28 روزه را منعکس می کند. Lab Data توسط Lighthouse و در شرایط شبیه سازی شده تولید می شود.
این دو عدد ممکن است متفاوت باشند.
فرض کنید Lighthouse روی یک اجرای مشخص LCP برابر 1.9 ثانیه نشان می دهد، اما Field Data مقدار 3.1 ثانیه دارد.
این تناقض نیست.
ممکن است کاربران واقعی:
دستگاه ضعیف تری داشته باشند، شبکه کندتری استفاده کنند، از موقعیت جغرافیایی دیگری وارد شوند، Cookie یا State متفاوت داشته باشند یا با Variation متفاوتی از صفحه روبرو شوند.
Lab Data برای Debug بسیار مناسب است.
Field Data برای فهم تجربه واقعی کاربران مناسب تر است.
بهترین Workflow این است که Field Data بگوید آیا مشکل واقعی داریم؟ و Lab Data کمک کند بفهمیم چرا مشکل داریم؟
چرا LCP در PageSpeed Insights با Search Console متفاوت است؟
این یکی از سوالات متداول تیم های سئو است.
Search Console و PageSpeed Insights هر دو می توانند از داده CrUX استفاده کنند، اما سطح Aggregation و نحوه نمایش اطلاعات یکسان نیست.
Search Console URLهای مشابه را در گروه ها نمایش می دهد.
PageSpeed Insights تلاش می کند داده URL خاص را نشان دهد و اگر داده کافی برای آن URL وجود نداشته باشد، ممکن است داده Origin را نمایش دهد. PSI همچنین Field Data تاریخی را در کنار اجرای Lab همان لحظه قرار می دهد.
بنابراین مقایسه مستقیم یک Lab Run امروز با گزارش تاریخی Search Console درست نیست.
اگر امروز LCP را اصلاح کرده باشید، Lighthouse ممکن است بلافاصله نتیجه بهتر نشان دهد.
اما Field Data باید با تجربه های جدید کاربران به مرور تغییر کند.
پس «اصلاح امروز» لزوما مساوی «سبز شدن Search Console امروز» نیست.
LCP موبایل ضعیف است اما دسکتاپ خوب؛ چرا؟
این وضعیت بسیار رایج است.
کاربران موبایل معمولا محدودیت های متفاوتی دارند: CPU ضعیف تر، شبکه کندتر، Viewport متفاوت و Assetهای متفاوت.
گاهی سایت در Desktop یک Hero Image بهینه ارسال می کند اما Mobile همان فایل بزرگ را دانلود می کند.
گاهی Menu، Slider یا Framework در Mobile رفتار متفاوتی دارد.
گاهی طراحی Responsive باعث می شود یک عنصر کاملا متفاوت به LCP تبدیل شود.
به همین دلیل LCP Element را در Mobile و Desktop جدا بررسی کنید.
فرض نکنید چون Hero Image دسکتاپ LCP است، در موبایل نیز همان Element خواهد بود.
LCP و SEO چه ارتباطی دارند؟
LCP یکی از معیارهای Core Web Vitals است و Google اعلام می کند Core Web Vitals در سیستم های Ranking آن استفاده می شوند.
اما این جمله نباید به این تعبیر تبدیل شود که:
LCP را از 2.8 به 2.3 برسانید و رتبه شما حتما بالا می رود.
Google به صراحت می گوید داشتن Core Web Vitals خوب تضمینی برای قرار گرفتن در بالای نتایج نیست و گرفتن Score کامل صرفا برای SEO لزوما بهترین استفاده از زمان نیست. سیستم های Ranking عوامل مختلفی را در نظر می گیرند و مرتبط بودن و مفید بودن محتوا همچنان بسیار مهم است.
پس LCP را باید از دو زاویه جدی گرفت:
اول، تجربه واقعی کاربر.
دوم، بخشی از کیفیت فنی و Page Experience که می تواند در موفقیت Search نقش داشته باشد.
اگر می خواهید تصویر کامل تری از عوامل Search داشته باشید، مقاله رتبه بندی گوگل موضوع Ranking را مستقل از یک Metric خاص توضیح می دهد.
یک مثال عملی؛ چرا LCP یک صفحه محصول 4.6 ثانیه است؟
یک سناریوی فرضی را بررسی کنیم.
صفحه محصول یک فروشگاه اینترنتی در Mobile چنین LCPی دارد:
4.6 ثانیه
LCP Element تصویر اصلی محصول است.
Breakdown:
| بخش | زمان |
|---|---|
| TTFB | 700ms |
| Resource Load Delay | 1,800ms |
| Resource Load Duration | 600ms |
| Element Render Delay | 1,500ms |
| LCP | 4,600ms |
در نگاه اول ممکن است تیم سئو بگوید:
«تصویر اصلی 600 میلی ثانیه طول کشیده. آن را فشرده کنیم.»
تصویر از 180KB به 90KB کاهش پیدا می کند و Load Duration از 600 به 400 میلی ثانیه می رسد.
LCP جدید تقریبا 4.4 ثانیه است.
هنوز Poor.
چرا؟
چون مشکل اصلی 600 میلی ثانیه دانلود تصویر نبود.
1.8 ثانیه Load Delay و 1.5 ثانیه Render Delay داشتیم.
بررسی عمیق تر نشان می دهد تصویر محصول توسط Slider JavaScript ساخته می شود. Markup اولیه URL تصویر را در src ندارد. علاوه بر آن، افزونه Optimization سایت به تصویر اول Slider نیز loading="lazy" اضافه کرده است.
بعد از Load تصویر هم یک Script سنگین برای Product Variation اجرا می شود و Main Thread را درگیر می کند.
راه حل واقعی می تواند شامل این تغییرات باشد:
URL تصویر اصلی در HTML اولیه قرار گیرد.
Lazy Loading تصویر LCP حذف شود.
در صورت اثبات نیاز، fetchpriority="high" روی تصویر اصلی قرار گیرد.
اجرای JavaScript غیرضروری از Critical Rendering Path خارج شود.
حالا Load Delay و Render Delay هدف اصلی Optimization هستند.
این مثال تفاوت بزرگی را نشان می دهد:
Performance Optimization یعنی کاهش بزرگ ترین اتلاف زمان، نه اجرای محبوب ترین توصیه.
مثال دوم؛ LCP متن است نه تصویر
فرض کنید یک سایت خدماتی Hero Image ندارد.
بالای صفحه یک Heading بزرگ و چند خط توضیح قرار گرفته است.
Lighthouse نشان می دهد LCP Element همان بلوک Heading است.
TTFB خوب است.
Resource جداگانه ای برای LCP وجود ندارد.
اما Render Delay بالاست.
بررسی نشان می دهد متن با Font اختصاصی نمایش داده می شود و CSS طوری تنظیم شده که تا زمان آماده شدن Font متن برای مدتی نمایش داده نمی شود.
در چنین صفحه ای تبدیل تصاویر به WebP هیچ تاثیری روی LCP ندارد.
مسیر درست، بررسی Font Loading و CSS Rendering است.
این مثال دلیل دیگری است که قبل از Optimization باید خود LCP Element را بشناسید.
مثال سوم؛ تصویر فقط 60KB است اما LCP هنوز ضعیف است
Hero Image فقط 60KB حجم دارد.
از CDN نیز Serve می شود.
در نگاه اول همه چیز عالی به نظر می رسد.
اما LCP برابر 3.8 ثانیه است.
Network Waterfall نشان می دهد درخواست تصویر در ثانیه 2.4 آغاز شده است.
چرا؟
تصویر CSS Background یک Component است و فایل CSS مربوط به Component بعد از یک JavaScript Chunk دانلود می شود.
یعنی Resource سبک است، اما بسیار دیر کشف می شود.
راه حل می تواند تغییر ساختار Discovery، Preload هدفمند یا بازنگری Markup باشد.
باز هم مشکل حجم تصویر نیست.
مشکل Resource Load Delay است.
اشتباهات رایج در بهبود LCP
| اشتباه | چرا مشکل دارد؟ |
|---|---|
| فقط فشرده کردن تصاویر | شاید Bottleneck اصلی Load Delay یا Render Delay باشد |
| Lazy Load کردن Hero Image | شروع دانلود LCP Resource را عقب می اندازد |
| Preload کردن همه تصاویر | Network Contention ایجاد می کند |
| High Priority دادن به همه چیز | Priority واقعی Resourceها را از بین می برد |
| تمرکز فقط روی Lighthouse | تجربه واقعی کاربران ممکن است متفاوت باشد |
| خرید سرور قوی بدون بررسی | مشکل ممکن است اصلا TTFB نباشد |
| حذف بی هدف JavaScript | ممکن است Complexity زیاد شود بدون تاثیر واقعی بر LCP |
| تغییر چند چیز هم زمان | مشخص نمی شود کدام تغییر واقعا اثر داشته است |
| هدف گرفتن Score 100 | ممکن است زمان زیادی برای سود ناچیز مصرف شود |
| یکی دانستن LCP با Load Time | این دو Metric مفهوم یکسانی ندارند |
چک لیست حرفه ای بهبود LCP
وقتی با یک URL دارای LCP ضعیف روبرو می شوید، بهتر است به جای مجموعه ای از ترفندهای پراکنده، یک ترتیب ثابت برای تحلیل داشته باشید:
- ابتدا Field LCP را بررسی کنید و مطمئن شوید مشکل فقط یک Lab Run نیست.
- Mobile و Desktop را جداگانه تحلیل کنید.
- LCP Element واقعی را پیدا کنید.
- LCP را به TTFB، Load Delay، Load Duration و Render Delay تقسیم کنید.
- بزرگ ترین Subpart غیرضروری را پیدا کنید.
- اگر TTFB بالاست، Server و Delivery HTML را بررسی کنید.
- اگر Load Delay بالاست، Discovery، Lazy Loading، CSS Background و JavaScript را بررسی کنید.
- اگر Load Duration بالاست، حجم، ابعاد، Format، CDN و Responsive Image را بررسی کنید.
- اگر Render Delay بالاست، CSS، JavaScript، Font، DOM و Main Thread را بررسی کنید.
- فقط اصلاح مرتبط با Bottleneck را اجرا کنید.
- دوباره با همان شرایط Lab Test بگیرید.
- بعد از Deploy، Field Data را در روزها و هفته های بعد دنبال کنید.
این فرایند بسیار مهم تر از حفظ کردن ده ها تکنیک Performance است.
تفاوت LCP و FCP چیست؟
FCP یا First Contentful Paint لحظه ای را اندازه گیری می کند که اولین محتوای قابل مشاهده صفحه Render می شود.
LCP زمان Render بزرگ ترین محتوای قابل مشاهده را اندازه گیری می کند.
به همین دلیل FCP می تواند بسیار خوب باشد اما LCP ضعیف بماند.
مثلا لوگو در 700 میلی ثانیه نمایش داده می شود.
FCP خوب است.
اما Hero Image در 4 ثانیه ظاهر می شود.
LCP ضعیف است.
از زاویه تجربه کاربر نیز این تفاوت منطقی است.
کاربر با دیدن یک Logo کوچک لزوما احساس نمی کند محتوای صفحه آماده شده است.
آیا CDN باعث بهبود LCP می شود؟
ممکن است، اما همیشه نه.
CDN می تواند فاصله شبکه ای تا کاربر را کاهش دهد و Delivery Resourceها را بهتر کند. برای تصاویر و Assetهای Static نیز Cache در Edge می تواند مفید باشد.
اما اگر مشکل اصلی این باشد که Hero Image دو ثانیه دیر کشف می شود، CDN فقط مدت دانلود بعد از Discovery را کاهش می دهد.
یا اگر Render Delay ناشی از JavaScript باشد، انتقال تصویر از CDN سریع تر مشکل Main Thread را حل نمی کند.
پس CDN یک ابزار است، نه درمان عمومی LCP.
قبل از استفاده از هر ابزار بپرسید:
این ابزار کدام Subpart را کاهش می دهد؟
اگر پاسخ مشخص نیست، هنوز تشخیص کامل نشده است.
آیا Cache می تواند LCP را بهتر کند؟
بله، در بعضی سناریوها.
Cache می تواند روی TTFB، Resource Load Duration یا هر دو تاثیر بگذارد.
Full Page Cache ممکن است Backend Processing را کاهش دهد.
Browser Cache می تواند Resource تکراری را در بازدیدهای بعدی سریع تر در اختیار کاربر قرار دهد.
CDN Cache می تواند Delivery را نزدیک تر کند.
اما بازدید اول کاربر نیز اهمیت دارد.
اگر Performance فقط برای Repeat Visit عالی باشد ولی کاربران جدید LCP ضعیفی ببینند، مشکل کاملا حل نشده است.
به همین دلیل Performance را در چند سناریوی واقعی بررسی کنید.
آیا حذف تمام JavaScript باعث LCP بهتر می شود؟
از نظر نظری، حذف JavaScript غیرضروری می تواند هزینه Network و Main Thread را کاهش دهد.
اما «تمام JavaScript را حذف کنیم» توصیه حرفه ای نیست.
بسیاری از سایت ها به JavaScript برای Functionality واقعی نیاز دارند.
هدف این است که مشخص کنیم:
کدام JavaScript برای First View حیاتی است؟
کدام Script می تواند بعدا اجرا شود؟
کدام Third-party واقعا ارزش هزینه Performance خود را دارد؟
کدام Bundle بیش از حد بزرگ است؟
کدام Task درست قبل از Render LCP Main Thread را مسدود می کند؟
Performance Engineering حذف تکنولوژی نیست؛ مدیریت هزینه تکنولوژی است.
آیا رسیدن به LCP زیر 2.5 ثانیه کافی است؟
از دید Threshold Core Web Vitals، 2.5 ثانیه مرز Good است.
اما Performance یک Switch صفر و یک نیست.
LCP برابر 2.4 ثانیه به این معنی نیست که دیگر هیچ Optimization ارزشمندی وجود ندارد، همان طور که 2.6 ثانیه به معنی فاجعه نیست.
Threshold برای ارزیابی و هدف گذاری مفید است.
اما تصمیم کسب و کار باید Cost و Benefit را هم در نظر بگیرد.
اگر رساندن LCP از 2.4 به 2.2 فقط چند ساعت زمان نیاز دارد و تجربه کاربران زیادی را بهتر می کند، ممکن است ارزشمند باشد.
اگر رساندن آن از 1.5 به 1.3 نیازمند بازنویسی چند هفته ای سیستم است و تفاوت قابل احساس محدودی دارد، احتمالا اولویت های مهم تری وجود دارند.
چگونه بفهمیم Optimization موفق بوده است؟
دو مرحله داریم.
مرحله اول Lab Validation است.
بعد از هر تغییر، تست کنترل شده بگیرید و ببینید Subpart هدف واقعا کاهش پیدا کرده است یا خیر.
مثلا اگر هدف شما کاهش Resource Load Delay بود، بررسی کنید درخواست LCP Image حالا زودتر در Waterfall شروع می شود یا نه.
فقط به Performance Score نگاه نکنید.
مرحله دوم Field Validation است.
بعد از Deploy، داده کاربران واقعی باید دنبال شود.
PageSpeed Insights داده CrUX را در یک بازه متحرک 28 روزه گزارش می کند، بنابراین انتظار نداشته باشید تغییر Field LCP بلافاصله مانند Lab Data دیده شود.
اگر RUM اختصاصی دارید، می توانید تاثیر تغییر را سریع تر و با Segmentهای دقیق تر بررسی کنید.
سوالات متداول درباره LCP
LCP چیست؟
LCP یا Largest Contentful Paint یکی از معیارهای Core Web Vitals است و مدت زمانی را اندازه گیری می کند که طول می کشد بزرگ ترین عنصر محتوایی قابل مشاهده در Viewport Render شود. هدف توصیه شده برای تجربه خوب، LCP برابر 2.5 ثانیه یا کمتر در صدک 75 است.
LCP خوب چند ثانیه است؟
LCP تا 2.5 ثانیه Good، بیشتر از 2.5 تا 4 ثانیه Needs Improvement و بیشتر از 4 ثانیه Poor محسوب می شود.
چگونه LCP را کاهش دهیم؟
ابتدا LCP را به چهار بخش TTFB، Resource Load Delay، Resource Load Duration و Element Render Delay تقسیم کنید. سپس بخشی را که بیشترین زمان غیرضروری را مصرف می کند هدف قرار دهید. راه حل بسته به Bottleneck می تواند بهبود Server، Discovery زودتر Resource، حذف Lazy Load از LCP Image، Image Optimization یا کاهش Render Delay باشد.
LCP Element چیست؟
LCP Element بزرگ ترین عنصر محتوایی است که در Viewport Render شده و برای محاسبه Largest Contentful Paint در نظر گرفته می شود. این عنصر می تواند تصویر، Video Poster، CSS Background Image واجد شرایط یا یک بلوک متن باشد.
آیا تصویر همیشه LCP Element است؟
خیر. در بسیاری از صفحات تصویر Hero یا Product Image به LCP تبدیل می شود، اما بلوک متن، عنوان بزرگ، Video Poster یا Background Image نیز می توانند LCP باشند.
آیا Lazy Loading باعث افزایش LCP می شود؟
اگر روی تصویر داخل Viewport و مخصوصا LCP Image استفاده شود، می تواند شروع دانلود را عقب بیندازد و LCP را بدتر کند. Lazy Loading معمولا برای تصاویر خارج از Viewport مناسب است.
آیا fetchpriority=”high” باعث بهبود LCP می شود؟
اگر LCP Resource زود کشف می شود اما Browser Priority کافی به آن نمی دهد، fetchpriority="high" می تواند مفید باشد. با این حال نباید تعداد زیادی Resource را High Priority کرد.
آیا Preload همیشه برای LCP مناسب است؟
خیر. Preload بیشتر زمانی ارزش دارد که Resource مهم دیر کشف شود، مثلا LCP Image داخل CSS Background باشد. Preload بی دلیل می تواند با Resourceهای حیاتی دیگر رقابت ایجاد کند.
تفاوت LCP و FCP چیست؟
FCP زمان نمایش اولین محتوای قابل مشاهده را اندازه گیری می کند، اما LCP روی بزرگ ترین محتوای قابل مشاهده تمرکز دارد. به همین دلیل FCP ممکن است خوب باشد و LCP همچنان ضعیف بماند.
چرا LCP در موبایل و دسکتاپ متفاوت است؟
تفاوت CPU، شبکه، Viewport، Assetهای Responsive و حتی LCP Element می تواند باعث اختلاف شود. Mobile و Desktop باید جداگانه تحلیل شوند.
چرا LCP در Lighthouse و Search Console متفاوت است؟
Lighthouse یک تست آزمایشگاهی در شرایط کنترل شده است، اما Search Console بر داده واقعی کاربران متکی است. تفاوت دستگاه، شبکه، موقعیت و بازه زمانی باعث می شود دو مقدار لزوما یکسان نباشند.
جمع بندی؛ برای بهبود LCP اول زمان گمشده را پیدا کنید
LCP در ظاهر یک عدد ساده است.
مثلا:
4.2 ثانیه
اما پشت این عدد یک زنجیره وجود دارد.
مرورگر باید Document را دریافت کند.
باید LCP Resource را پیدا کند.
باید آن Resource را دانلود کند.
و بعد باید امکان Render عنصر را داشته باشد.
هر کدام از این مراحل می تواند Bottleneck اصلی باشد.
به همین دلیل توصیه هایی مانند «عکس را WebP کن»، «CDN بخر»، «Cache نصب کن» یا «JavaScript را کم کن» بدون تشخیص دقیق، پاسخ کاملی به مشکل LCP نیستند.
روش حرفه ای این است که LCP را به چهار بخش تقسیم کنیم:
TTFB
Resource Load Delay
Resource Load Duration
Element Render Delay
بعد ببینیم بیشترین زمان غیرضروری کجا مصرف شده است.
اگر TTFB مشکل دارد، Delivery Document و Server را اصلاح کنیم.
اگر Resource دیر پیدا می شود، Discovery را بهتر کنیم.
اگر دانلود Resource کند است، حجم، ابعاد و Delivery آن را بهینه کنیم.
اگر Resource آماده است ولی عنصر دیر ظاهر می شود، Rendering Path، CSS، JavaScript و Main Thread را بررسی کنیم.
این طرز فکر یک مزیت مهم دارد: به جای انجام ده ها تغییر و امید داشتن به اینکه یکی از آن ها موثر باشد، هر Optimization براساس یک علت قابل اندازه گیری انجام می شود.
و در نهایت هدف LCP فقط سبز شدن PageSpeed Insights نیست.
هدف این است که کاربری که وارد صفحه می شود، مجبور نباشد چند ثانیه به فضای خالی، Skeleton یا Hero ناقص نگاه کند.
LCP خوب یعنی محتوای اصلی در زمانی نمایش داده شود که تجربه صفحه سریع، قابل اعتماد و طبیعی احساس شود.
وقتی Optimization را از تجربه کاربر شروع کنیم و با داده فنی ادامه دهیم، LCP دیگر یک عدد مبهم در گزارش Performance نیست؛ تبدیل به یک مسئله قابل تشخیص و قابل حل می شود.
اولین دیدگاه را بنویسید