LCP چیست و چگونه آن را بهینه کنیم؟

وقتی صفحه‌ای را روی گوشی باز می‌کنید و هنوز چیزی جز سفیدی نمی‌بینید، مغز شما در حال اندازه‌گیری همان چیزی است که گوگل سال‌ها بعد اسمش را گذاشت LCP (Largest Contentful Paint). شاخصی که به‌جای پرسیدن «چه زمانی صفحه بارگذاری شد؟»، می‌پرسد «چه زمانی کاربر حس کرد صفحه آمد؟». در پروژه‌های واقعی، LCP یکی از پرتکرارترین معیارهای قرمز در گزارش Search Console است و در تجربه‌ام، برخلاف تصور رایج، حل کردنش معمولاً ساده‌تر از INP و CLS است — به شرطی که مظنون درست را پیدا کنید. در این نوشته همان مسیر تشخیص و درمان را می‌گویم که در پروژه‌های واقعی اجرا می‌کنم.

LCP دقیقاً چه چیزی را می‌سنجد؟

LCP یکی از سه شاخص اصلی Core Web Vitals (شاخص‌های اصلی وب) گوگل است و زمان لازم برای رندر بزرگ‌ترین عنصر قابل‌مشاهده در ویوپورت (viewport) را اندازه می‌گیرد. این تعریف دقیق، دو نکته مهم را در خود دارد: اول، LCP به «بارگذاری کامل صفحه» کاری ندارد؛ فقط روی لحظه‌ای تمرکز دارد که کاربر حس می‌کند صفحه محتوای اصلی‌اش را نشان داده. دوم، LCP به بزرگ‌ترین عنصر دیداری وابسته است، نه به سنگین‌ترین فایل. جایگاه LCP در چارچوب کلی سه‌شاخصی در Core Web Vitals چیست به‌طور کامل آمده است؛ در این نوشته، فقط روی عمق همان یک شاخص تمرکز می‌کنم.

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

LCP معیار تحمل کاربر است، نه سرعت فنی؛ در فاصله کمتر از سه ثانیه، کاربر حس می‌کند صفحه «همین حالا» آمد؛ بعد از آن، حس می‌کند منتظر مانده.

کدام عناصر به‌عنوان LCP شمارش می‌شوند؟

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

• تصویر <img>: شایع‌ترین حالت؛ بنر اصلی صفحه، تصویر شاخص در بالای مطلب، یا تصویر یک محصول.
• تصویر بک‌گراند CSS: تصویر بزرگ که با background-image در یک عنصر پیاده‌سازی شده.
• عنصر بلوک متنی: در صفحات خبری، تیتر اصلی که چند خط بزرگ با فونت سنگین کشیده شده، می‌تواند به‌عنوان LCP شمرده شود.
• ویدئو (video poster): تصویر کاور یک ویدئوی جاسازی‌شده، اگر بزرگ‌ترین عنصر باشد.

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

آستانه‌های عددی و امتیازدهی

آستانه‌های رسمی گوگل برای LCP سه‌سطحی است: زیر ۲.۵ ثانیه خوب، بین ۲.۵ تا ۴ ثانیه نیازمند بهبود، و بالای ۴ ثانیه ضعیف. اما عددی که در Search Console و در گزارش CrUX دیده می‌شود، ۷۵امین صدک (75th percentile) بازدیدهای ۲۸ روز گذشته است، نه میانگین. یعنی اگر ۷۵ درصد بازدیدهای یک صفحه LCP زیر ۲.۵ ثانیه داشته باشند، آن صفحه در گروه سبز قرار می‌گیرد.

در تجربه من، انتقال از دسته «ضعیف» به «خوب» معمولاً یک بار با شناسایی و حذف یک گلوگاه بزرگ اتفاق می‌افتد. اما تثبیت در محدوده «خوب» مستلزم پایش مستمر است؛ چون افزودن یک اسلایدر جدید یا یک تصویر سنگین، می‌تواند همان عدد را در یک شب خراب کند. ابزارهای رصد ماهانه در بهترین ابزارهای تست سرعت سایت آمده است.

مظنون اول: سرور و TTFB

LCP نمی‌تواند از خودِ سرور سریع‌تر باشد. اگر TTFB (Time To First Byte) بالای ۸۰۰ میلی‌ثانیه باشد، حتی با بهینه‌ترین تصویر، LCP شما زیر ۲.۵ ثانیه نخواهد ماند. جداسازی گلوگاه سرور از تصویر و CSS را در تأثیر TTFB بر سرعت بارگذاری مفصل توضیح داده‌ام؛ اما چکیده تشخیص این است:

• اگر TTFBِ همه صفحات بالا است، مشکل سرور یا هاست است. مسیر پیشنهادی: کش سمت سرور (مثل LiteSpeed) یا ارتقای هاست. تحلیل عمیق‌تر در تأثیر هاست بر سرعت سایت.
• اگر TTFBِ بعضی صفحات بالا و بعضی پایین است، مشکل افزونه یا کوئری سنگین در همان صفحه‌هاست؛ روش عیب‌یابی در رفع مشکلات سرعت سایت.
• اگر TTFB خوب است ولی LCP بد، سرور را از فهرست مظنون‌ها بیرون بگذارید و سراغ چهار مظنون دیگر بروید.

یک نکته کاربردی: در سایت‌های وردپرسی، ترکیب کش صفحه و کش آبجکت (Redis) معمولاً TTFB را از چند صد میلی‌ثانیه به چند ده میلی‌ثانیه می‌رساند. اگر افزونه کش ندارید، از امروز فعال کنید؛ مقایسه در بهترین افزونه‌های کش وردپرس.

مظنون دوم: تصویر اصلی صفحه

در تجربه من، بیش از نیمی از پروژه‌هایی که LCP قرمز داشتند، مظنون اصلی تصویر بودند. چهار خطای رایج در تصویر LCP:

1. ابعاد بیش از حد: تصویر ۳۰۰۰ پیکسلی که در موبایل ۶۰۰ پیکسل نمایش داده می‌شود، فقط داده هدررفته است. راه‌حل: srcset و sizes درست، که در سئوی تصویر تفصیل داده شده.
2. فرمت قدیمی: JPEGِ فشرده‌نشده به‌جای WebP، حجم را چند برابر می‌کند. مقایسه فرمت‌ها در بهترین فرمت تصویر وب.
3. نبود fetchpriority: مرورگر پیش‌فرض نمی‌داند این تصویر مهم‌ترین عنصر صفحه است. با fetchpriority="high" روی همان تگ، اولویت دانلودش بالا می‌رود.
4. پرده‌گذاری‌های اضافه: برخی قالب‌ها یک لایه animation یا parallax روی تصویر اصلی می‌گذارند که رندر آن را عقب می‌اندازد.

<img
  src="hero-800.webp"
  srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
  sizes="(max-width: 600px) 100vw, 800px"
  width="800" height="600"
  fetchpriority="high"
  loading="eager"
  alt="بنر اصلی صفحه">

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

مظنون سوم: CSS بلاک‌کننده رندر

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

• CSS بحرانی (critical CSS): استایل بخش بالای صفحه (above-the-fold) را درون خود HTML قرار بدهید، بقیه را با defer بارگذاری کنید. ابزارهایی مثل critical یا افزونه‌های کش این کار را خودکار می‌کنند.
• کاهش CSS بلااستفاده: اگر قالب شما ۳۰۰ کیلوبایت CSS دارد ولی فقط ۲۰ درصدش در صفحه اصلی استفاده می‌شود، همان ۸۰ درصد بلااستفاده، رندر را معطل می‌کند. این را با افزونه‌های بهینه‌ساز حل کنید، ولی به‌تدریج و یک‌متغیر، چون بهینه‌سازی تهاجمی، چیدمان را می‌شکند.

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

مظنون چهارم: فونت‌های وب

فونت‌های وب (web fonts) در دو جهت می‌توانند LCP را بد کنند: اول با بلوکه کردن رندر (font blocking) در حالت FOIT (Flash of Invisible Text)، دوم با تکان دادن چیدمان وقتی فونت نهایی جایگزین فونت پشتیبان می‌شود. دو راه‌حل عملی:

1. استفاده از font-display: swap روی همه فونت‌ها؛ کاربر با فونت پشتیبان متن را می‌بیند و وقتی فونت اصلی لود شد، جایگزین می‌شود.
2. لود فونت‌ها از دامنه خودتان و با فرمت WOFF2؛ لود از دامنه خارجی، تأخیر DNS و TLS را اضافه می‌کند.

@font-face {
  font-family: "Vazirmatn";
  src: url("/fonts/vazirmatn-regular.woff2") format("woff2");
  font-weight: 400;
  font-display: swap;
}

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

فونت، تصمیمِ ابتدای مسیر رندر است؛ اگر فونت اشتباه انتخاب شده، هیچ بهینه‌سازی بعدی آن را جبران نمی‌کند.

تله LCP: lazy-load روی عنصر اصلی

این تله در تجربه من پرتکرارترین دلیل «بهبودی که اثر نداشت» است. lazy-load یعنی تصویر تا نزدیک نشدن به ویوپورت دانلود نشود. اگر این ویژگی به‌طور خودکار روی عنصر LCP هم اعمال شود، مرورگر منتظر می‌ماند تا کاربر اسکرول کند و بعد دانلود را شروع می‌کند — که عملاً تأخیر اضافه می‌سازد، نه بهبود.

تشخیص این وضعیت با DevTools (Developer Tools) کمتر از یک دقیقه است: در سربرگ Network، فیلتر Img را فعال کنید و صفحه را ریلود کنید؛ اگر تصویر اصلی صفحه در انتهای فهرست و با تأخیر ظاهر می‌شود، lazy-load روی آن اعمال شده. درمان:

<!-- عنصر LCP: هرگز lazy نکنید -->
<img src="hero.webp" loading="eager" fetchpriority="high">

<!-- بقیه تصاویر صفحه -->
<img src="gallery-1.webp" loading="lazy">

در وردپرس، lazy-load بومی از نسخه ۵.۵ فعال است؛ برای مستثنا کردن تصویر شاخص در برخی قالب‌ها از فیلتر wp_img_tag_add_loading_attr استفاده می‌کنم. نکات مرتبط با تصویر در موبایل در بهینه‌سازی تصاویر موبایل آمده است.

عیب‌یابی عملی: از DevTools تا PageSpeed

نظم کاری من در تشخیص LCP سه‌مرحله‌ای است:

1. تشخیص عنصر LCP: در Chrome DevTools، پنل Performance را ضبط کنید و در نتایج، فیلتر LCP را بزنید. DevTools دقیقاً همان عنصر را به شما نشان می‌دهد. اگر از این مرحله بگذرید، بقیه عیب‌یابی حدس می‌شود.
2. خواندن گزارش PSI: PageSpeed Insights در تب Diagnostics، بخشی به‌نام «Largest Contentful Paint element» دارد. همان، نقطه شروع تحلیل است.
3. بررسی CrUX در Search Console: اگر داده میدانی داشتید، وضعیت واقعی کاربران اندروید Chrome را ببینید، نه عدد آزمایشگاهی. تفاوت این دو در همان مقاله CWV توضیح داده شده.

ترتیب شک در پروژه‌های واقعی: اول TTFB (اگر بد است، هیچ چیز دیگری نمی‌تواند جبران کند)، بعد تصویر یا عنصر LCP، بعد CSS بلاک‌کننده، و در آخر فونت. اگر بعد از این چهار مرحله هم عدد قرمز ماند، گلوگاه معماری در قالب یا افزونه‌هاست؛ تحلیل کامل در تأثیر افزونه‌ها بر سرعت سایت آمده است.

تأیید بهبود: قبل و بعد با عدد

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

یک قاعده شخصی که در تجربه به آن رسیده‌ام: هر بهبود LCP را در استجینگ تست کنید، نه روی سایت زنده. بهینه‌سازی CSS یا lazy-load ممکن است چیدمان را در گوشه‌ای از سایت بشکند که شما نمی‌بینید. پروتکل تغییر امن در تغییر قالب بدون آسیب آمده است و منطق آن برای هر تغییر بهینه‌سازی هم درست است. بعد از انتشار، در هفته اول Search Console و گزارش CrUX را پایش کنید؛ گاهی عدد میدانی یک تا دو هفته دیر به‌روز می‌شود.

جدول مرجع

پرسش‌های کوتاه

آیا LCP در دسکتاپ هم مهم است؟ بله، اما گوگل در گزارش داوری، داده موبایل را مبنا می‌گیرد. تمرکز اولیه روی موبایل بگذارید.

آیا اگر TTFB خوب است ولی LCP بد، همیشه مشکل تصویر است؟ در اکثر موارد بله، اما سه مظنون دیگر (CSS، فونت و lazy-load اشتباه) هم می‌توانند مقصر باشند. با DevTools، عنصر LCP را قطعی کنید و بعد بر اساس همان، به‌سراغ مظنون متناظر بروید.

آیا افزونۀ کش، LCP را بهتر می‌کند؟ افزونۀ کش اساساً TTFB را بهتر می‌کند و به‌طور غیرمستقیم روی LCP اثر دارد. اگر مظنون شما تصویر یا فونت است، افزونۀ کش مشکل را حل نمی‌کند.

چرا بعد از بهینه‌سازی، عدد Search Console هنوز قرمز است؟ گزارش CrUX، ۷۵امین صدک ۲۸ روز گذشته است. تغییرات معمولاً با دو تا چهار هفته تأخیر در این گزارش دیده می‌شود. تفاوت داده میدانی و آزمایشگاهی در Core Web Vitals چیست توضیح داده شده است.

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

در بطن مهندسی LCP

برای توسعه‌دهندگان حرفه‌ای، LCP را می‌توان به‌عنوان مجموع چهار مؤلفه تحلیل کرد: زمان رسیدن اولین بایت (TTFB)، زمان بلاک‌شدن توسط استایل‌شیت‌ها (Render-Blocking CSS)، زمان اجرای JS بلاک‌کننده، و زمان لود منابع حیاتی (Resource Load Time). هر مؤلفه، مستقل از بقیه، سهمی از عدد نهایی را می‌سازد. DevTools دقیقاً همین تفکیک را در تب Performance زیر همان آبشار LCP ارائه می‌دهد؛ با یک بار خواندن دقیق این آبشار در پروژه‌های پرترافیک، به‌سرعت می‌فهمید گلوگاه واقعی در کدام لایه است. دو تصمیم معماری که در پروژه‌های سازمانی اثر مستقیم داشته‌اند: استفاده از CDN (Content Delivery Network) برای تصاویر و فایل‌های استاتیک — همان منطقی که در نقش CDN در سرعت سایت آمده — و کاهش HTML بحرانی با انتقال استایل‌های بلااستفاده به فایل‌های مجزا. هر دو، تصمیم‌های بنیادینی هستند که به‌ندرت با یک تنظیم جانبی حل می‌شوند. علاوه بر این، در معماری‌های HTTP/2 و HTTP/3، الگوی push کردن منابع حیاتی (Server Push در حال کاهش و Early Hints در حال رشد) می‌تواند TTFB مؤثر را برای منابع LCP پایین بیاورد؛ اما هزینه پیکربندی و نگهداری آن، فقط برای سایت‌های پرترافیک توجیه دارد. در پروژه‌های کوچک، تمرکز روی چهار مظنون ابتدایی، بازده به‌مراتب بهتری می‌سازد.

خلاصه مسیر بهبود LCP

بهبود LCP، از جنس تشخیص است، نه از جنس تنظیم. تجربه من می‌گوید اگر امروز فقط یک کار بکنید، عنصر LCP را در DevTools قطعی کنید؛ همان یک قدم، جست‌وجو برای سایر گزینه‌ها را از حالت حدس خارج می‌کند. اگر TTFB خوب است و عنصر LCP تصویر است، سه تغییر (WebP، srcset، fetchpriority) در بیشتر پروژه‌ها کافی است. اگر بعد از این تغییرات عدد قرمز ماند، به‌سراغ CSS و فونت بروید. اگر عدد سبز شد، همان پایش ماهانه را داشته باشید تا با اضافه‌شدن یک اسلایدر یا کمپین جدید، به‌جای چند ماه بعد، همان هفته بفهمید. اگر تجربه‌ای از بهینه‌سازی LCP دارید که با یک تغییر کوچک جهش محسوسی ساخت، در دیدگاه‌ها بنویسید؛ همان مثال‌ها، برای نفر بعدی از هر راهنمای عمومی کاربردی‌تر است. 🎯