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

بهبود LCP سایت معمولاً از یکی از سه جا شروع می شه: سرور دیر جواب می ده، تصویر اصلی صفحه سنگینه یا مرورگر دیر پیداش می کنه، یا فایل هایی جلوی نمایش صفحه رو گرفتن. LCP یعنی لحظه ای که بزرگ ترین عنصر بالای صفحه، معمولاً عکس بنر یا یه تیتر درشت، روی صفحه ظاهر می شه. اینجا علت ها رو به ترتیب احتمال مرور می کنیم و برای هر کدوم می گیم چطور تشخیصش بدی و چی کار کنی.
نشانه ها: صفحه سنگین به نظر می رسه، ولی دقیقاً کجاش؟
صفحه رو باز می کنی. منو و متن ها میان، ولی جای عکس اصلی خالیه. یا تیتر هست و بنر چند لحظه بعد می پره وسط صفحه. مشتری ای که عکس محصول رو دیر می بینه فکر می کنه سایت هنوز بالا نیومده، حتی اگه بقیه صفحه آماده باشه.
LCP شبیه رسیدن غذای اصلی تو رستورانه. مشتری کاری نداره نوشیدنی و پیش غذا کی رسید. تا غذای اصلی نیاد، حس می کنه سفارشش نرسیده. مسیرش هم معلومه: سفارش می ره آشپزخونه (سرور)، غذا آماده می شه، بعد میاد روی میز و تو بشقاب چیده می شه (مرورگر). تأخیر می تونه از هر کدوم از این مرحله ها بیاد.
برای دیدن وضعیت، سه ابزار کافیه:
- PageSpeed Insights: داده آزمایشی (lab) رو نشون می ده، و اگه ترافیک کافی داشته باشی، داده کاربران واقعی (field) رو هم.
- گزارش Core Web Vitals در Search Console: صفحه های مشکل دار رو گروه بندی می کنه.
- تب Performance در DevTools: برای ردیابی دقیق همون صفحه ای که مشکل داره.
طبق راهنمای فعلی گوگل، LCP تا حدود ۲٫۵ ثانیه «خوب» حساب می شه. عدد دقیق و روش اندازه گیری رو با مستندات web.dev چک کن، چون ممکنه به روز بشه.
یه نکته که زیاد جا می ندازن: تست روی لپ تاپ خودت با اینترنت خوب، با گوشی متوسط روی دیتای موبایل خیلی فرق داره. اگه عدد آزمایشی خوبه ولی Search Console قرمزه، به Search Console اعتماد کن.
قبل از بهبود LCP سایت، عنصر LCP رو پیدا کن
تو PageSpeed Insights بخش Diagnostics رو باز کن و دنبال «Largest Contentful Paint element» بگرد. بیشتر وقت ها یه تصویره، ولی گاهی یه بلوک متنه. راه حل این دو فرق داره: اگه عنصر متنه، کوچیک کردن عکس ها هیچ کمکی نمی کنه.
بعدش زمان LCP رو به چهار تکه تقسیم کن:
| بخش | یعنی چی | مقصر رایج |
|---|---|---|
| زمان پاسخ سرور (TTFB) | تا رسیدن اولین بایت HTML | هاست شلوغ، نبود کش |
| تأخیر شروع دانلود | مرورگر دیر می فهمه باید عکس رو بگیره | lazy load اشتباه، تصویر پس زمینه، اسلایدر |
| مدت دانلود | حجم فایل و سرعت شبکه | عکس سنگین، فرمت قدیمی |
| تأخیر نمایش | فایل رسیده ولی هنوز رسم نشده | CSS و JS مسدودکننده، فونت |
اول سراغ تکه ای برو که بیشترین وقت رو می گیره. بقیه مقاله رو هم می تونی با همین ترتیب بخونی، چون از سرور شروع می کنیم و به نمایش صفحه می رسیم.

علت اول: سرور دیر جواب می ده
تا سرور اولین بایت HTML رو نفرسته، هیچ بهینه سازی سمت مرورگر شروع نمی شه. عکس رو هرقدر کوچیک کنی، اگه خود صفحه دیر برسه، LCP خوب نمی شه.
اندازه بگیر، حدس نزن
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://example.ir/
چند بار اجرا کن. یه بار هم تو ساعت پرمخاطب. راهنمای گوگل TTFB حدود ۸۰۰ میلی ثانیه یا کمتر رو مناسب می دونه. اگه چند برابر این بود، قبل از دست زدن به عکس ها سراغ سرور برو.
مقصرهای معمول
- نبود کش صفحه: هر بازدید PHP رو اجرا می کنه و ده ها کوئری به دیتابیس می ره. با کش، HTML آماده تحویل داده می شه.
- افزونه و قالب سنگین: افزونه ها رو یکی یکی غیرفعال کن و بعد از هر بار، TTFB رو دوباره بگیر. اغلب همون دو سه تا افزونه بیشترین زمان رو می خورن.
- نسخه قدیمی PHP: نسخه ای رو انتخاب کن که قالب و افزونه هات پشتیبانی می کنن و هنوز آپدیت امنیتی می گیره.
- منابع محدود یا هاست شلوغ: اگه کش و افزونه ها مشکلی نداشتن و TTFB باز بالاست، احتمالاً منابع سرور کمه.
یه مثال آشنا: فروشگاهی که شب یلدا یا جشنواره فروش چند برابر ترافیک می گیره. صفحه محصول تو روز عادی سریع بود، ولی اون شب دیر باز می شه. مشکل از عکس نیست. بدون کش، هر بازدیدکننده یه اجرای کامل PHP و دیتابیس می گیره و صف تشکیل می شه.
دیسک سریع هم تنها راه نجات نیست. توضیحش رو تو هاست NVMe؛ چرا دیسک سریع برای سایت کافی نیست؟ نوشتیم. اگه بعد از کش و پاکسازی افزونه ها هم TTFB بالا موند، احتمالاً بهینه سازی کد دیگه کمک زیادی نمی کنه و باید پلن یا سرور رو عوض کنی.
علت دوم: تصویر اصلی سنگینه یا دیر پیدا می شه
اگه TTFB خوب بود، معمولاً مقصر همین بخشه. دو مشکل جدا داریم و باید جدا بررسیشون کنی.
مشکل حجم
عکس ۳۰۰۰ پیکسلی که تو یه کادر ۴۰۰ پیکسلی نشون داده می شه، فقط پهنای باند مصرف می کنه. سه کار انجام بده:
- ابعاد رو با بزرگ ترین اندازه واقعی نمایش تنظیم کن.
- فرمت WebP یا AVIF بده. بیشتر مرورگرهای امروزی پشتیبانی می کنن، ولی اگه بخشی از کاربرهات مرورگر خیلی قدیمی دارن، نسخه JPEG هم کنارش بذار.
- برای موبایل نسخه کوچیک تر بده.
مشکل دیر پیدا شدن
مرورگر وقتی عکس رو زود می گیره که تو HTML ببینتش. اگه عکس به عنوان background-image تو CSS باشه، یا یه اسلایدر جاوااسکریپتی بعد از اجرای خودش بسازدش، مرورگر خیلی دیرتر می فهمه. اشتباه رایج تر اینه که افزونه کش یا بهینه ساز، loading="lazy" رو روی همه عکس ها گذاشته، حتی عکس اصلی بالای صفحه. نتیجه اش اینه که مرورگر دانلودش رو عقب می ندازه.
پیشنهاد ما برای عکس اصلی:
<img src="/img/hero-1200.webp"
srcset="/img/hero-600.webp 600w, /img/hero-1200.webp 1200w"
sizes="100vw"
width="1200" height="600"
fetchpriority="high"
alt="توضیح تصویر">
هر بخش یه کار می کنه. fetchpriority="high" به مرورگر می گه این عکس مهمه. srcset و sizes اندازه مناسب هر دستگاه رو انتخاب می کنن. width و height هم جلوی پرش صفحه رو می گیرن. فقط عکس های پایین تر از اولین صفحه رو lazy کن.
اگه مجبوری عکس رو از CSS یا جاوااسکریپت بگیری، پیش بارگذاری کن:
<link rel="preload" as="image" href="/img/hero-1200.webp"
imagesrcset="/img/hero-600.webp 600w, /img/hero-1200.webp 1200w"
imagesizes="100vw" fetchpriority="high">
حواست باشه فقط برای یک عکس، یعنی همون عکس LCP، پیش بارگذاری بذاری. اگه چند فایل رو با اولویت بالا بکشی، با هم رقابت می کنن و نتیجه برعکس می شه.

علت سوم: چیزهایی که جلوی رسم صفحه رو می گیرن
عکس رسیده، ولی مرورگر هنوز چیزی نشون نمی ده؟ معمولاً یکی از این هاست.
CSS و JS مسدودکننده. مرورگر تا CSS داخل <head> رو نگیره، صفحه رو نمی کشه. یه فایل ۵۰۰ کیلوبایتی که نصفش برای صفحه های دیگه ست، همین جا گیر می ندازه. CSS مهم بالای صفحه رو داخل خود صفحه بذار و بقیه رو دیرتر بار کن. اسکریپت های غیرضروری رو هم با defer بارگذاری کن.
فونت. اگه فونت از سرویس خارجی می آد، با توجه به شرایط اتصال به خارج از ایران، گاهی کند یا ناپایداره. فونت رو روی هاست خودت بذار و font-display رو تنظیم کن تا متن تا رسیدن فونت قابل خوندن بمونه:
@font-face {
font-family: "SiteFont";
src: url("/fonts/sitefont.woff2") format("woff2");
font-display: swap;
}
اگه عنصر LCP صفحه ات یه تیتر متنیه، این تنظیم می تونه بیشترین اثر رو داشته باشه.
اسکریپت های شخص ثالث. آنالیتیکس، پیکسل تبلیغاتی، ویجت چت، نماد اعتماد، اسکریپت پرداخت. هر کدوم به تنهایی کوچیکه، ولی با هم می تونن صفحه رو کند کنن. یه راه رایج اینه که اسکریپتی مثل Google Analytics رو بعد از بارگذاری کامل صفحه و تو زمان بیکاری مرورگر بار کنی، تا روی سرعت و Core Web Vitals اثری نذاره. الگوی کلیش این شکلیه:
window.addEventListener('load', function () {
var run = function () { /* ساخت تگ script و اضافه کردن به صفحه */ };
if ('requestIdleCallback' in window) requestIdleCallback(run);
else setTimeout(run, 2000);
});
اسکریپت پرداخت یا درگاه رو فقط تو صفحه ای بذار که لازمش داری. لازم نیست تو صفحه اصلی لود بشه.
یه مورد دیگه هم هست: صفحه هایی که محتوای اصلی رو کامل با جاوااسکریپت می سازن، مثل بعضی قالب های پیج ساز یا اپ های تک صفحه ای. اینجا تأخیر نمایش بالا می ره. اگه می شه، اولین بخش صفحه رو سمت سرور رندر کن.
کش مرورگر و شبکه: وقتی بقیه چیزها درسته
بازدیدکننده ای که برمی گرده، نباید عکس و فونت و CSS رو دوباره دانلود کنه. هدر کش رو تنظیم کن:
location ~* \.(webp|avif|jpg|png|woff2|css|js)$ {
expires 30d;
add_header Cache-Control "public";
}
این تنظیم فقط وقتی امنه که اسم فایل با هر تغییر عوض بشه (مثلاً style.a1b2.css). وگرنه کاربر نسخه قدیمی رو می بینه.
درباره CDN رو راست بگم: کمک می کنه، ولی جای یه سرور سالم رو نمی گیره. اگه بیشتر بازدیدکننده هات داخل ایران هستن، سروری که مسیر کوتاه تری تا کاربر داره معمولاً انتخاب منطقی تره، و بعضی CDN های خارجی تو مسیر ایران همیشه نتیجه خوبی نمی دن. جزئیاتش رو تو CDN برای سایت؛ آیا جای هاست قوی را می گیرد؟ گفتیم. قبل و بعد از هر تغییر، با کاربر واقعی ایرانی هم تست کن.
که دوباره برنگرده: عادت های کوچیک
بهینه سازی رو یه بار انجام می دی، ولی خراب شدنش هر هفته ممکنه. چند عادت ساده کمک می کنه:
- بعد از هر تغییر بزرگ (قالب جدید، افزونه جدید، بنر جدید) PageSpeed رو یه بار اجرا کن.
- به نویسنده ها و مدیر محتوا بگو عکس رو با ابعاد مشخص و فشرده آپلود کنن. رایج ترین دلیل برگشت مشکل، یه عکس چندمگابایتی تو بنر جدیده.
- داده field تو Search Console با تأخیر به روز می شه، حدود چهار هفته. برای قضاوت صبر کن و فقط به عدد آزمایشی تکیه نکن.
- یه چک لیست ثابت داشته باش: TTFB، عکس اصلی، اسکریپت های اضافه. هر بار همین سه تا رو بررسی کن.
اگه وقت نداری یا می خوای یه نفر عددها رو از صفر بخونه، بهینه سازی سرعت کاریه که ما تو Wbweb انجام می دیم. ولی بیشتر موارد بالا رو با یه بعدازظهر آزمایش و اندازه گیری، خودت هم می تونی پیش ببری.
سوالات متداول
LCP خوب چه عددیه؟
طبق راهنمای فعلی گوگل، حدود ۲٫۵ ثانیه یا کمتر برای بیشتر بازدیدها «خوب» حساب می شه. این آستانه ممکنه عوض بشه، پس هر چند وقت یه بار تو مستندات web.dev ببینش. مهم تر از عدد دقیق اینه که صفحه های اصلی کسب و کارت، مثل صفحه اول و صفحه محصول، زیر همین حد باشن.
چرا تو PageSpeed عدد خوبه ولی Search Console قرمز نشون می ده؟
بخش آزمایشی PageSpeed یه اجرای شبیه سازی شده ست، ولی Search Console از کاربران واقعی داده می گیره. اینترنت ضعیف موبایل، ساعت های اوج ترافیک و دستگاه های قدیمی تو تست آزمایشی خوب دیده نمی شن. اینجا به داده کاربران واقعی بیشتر اعتماد کن.
lazy load رو برای همه عکس ها فعال کنم؟
نه. عکسی که تو اولین صفحه دیده می شه، به خصوص عکس LCP، نباید lazy باشه. lazy load فقط برای عکس های پایین تر از صفحه خوبه. اگه افزونه ای همه رو lazy کرده، عکس اصلی رو از لیستش خارج کن.
بعد از رفع مشکل چقدر طول می کشه تا گزارش درست بشه؟
عدد PageSpeed بلافاصله عوض می شه، ولی داده کاربران واقعی تو Search Console با تأخیر به روز می شه، حدود چهار هفته. تا اون موقع با تست های آزمایشی و گزارش خودت جلو برو.
از کجا شروع کنی؟
اول عنصر LCP رو پیدا کن و ببین کدوم تکه از چهار تکه بیشترین وقت رو می گیره. اگه TTFB بالاست، کش و افزونه ها و منابع سرور رو درست کن. اگه مشکل از تصویره، ابعاد و فرمت رو اصلاح کن، loading="lazy" رو از عکس اصلی بردار و fetchpriority="high" بده. بعدش CSS، فونت و اسکریپت های جانبی رو سبک کن. هر تغییر رو جدا انجام بده و اندازه بگیر، تا بفهمی کدومش جواب داده.


