91035059 - 021

نیاز به راهنمایی دارید؟

رسیدن به LCP زیرِ ۲ ثانیه در موبایل؛ نقشه‌راه عملی ۲۰۲۵

  • بدون نظر

آنـچه در این مقاله میـخوانیم

اگر فقط یک شاخص را برای «اولین برداشتِ بصری» کاربر در موبایل بهینه کنید، آن شاخص LCP است. در این راهنما یک مسیر قدم‌به‌قدم می‌دهیم تا LCP صفحه‌های شما در p75 موبایل به زیرِ ۲ ثانیه برسد و آن‌جا بماند—با چک‌لیست اجرایی، حدهای عملکرد (performance budgets) و نمونه‌کدهای کاربردی.

LCP دقیقاً چیست و «۲ ثانیه» یعنی چه؟

Largest Contentful Paint (LCP) زمان رندرِ بزرگ‌ترین محتوای قابل‌مشاهده در viewport است؛ معمولاً یک تصویر هیرو، بلاک متن بزرگ (مانند H1/hero text)، یا پوستر ویدئو. از نظر فنی، مرورگر یکی از این عناصر را وقتی واقعاً رندر و در صفحه دیده شد، به‌عنوان نامزد LCP گزارش می‌کند. تصاویر پس‌زمینهٔ CSS با url() نیز می‌توانند نامزد LCP باشند؛ نکته‌ای که بسیاری از تیم‌ها از آن غافل می‌شوند.

از نگاه جستجو و تجربهٔ واقعی کاربر، آستانه‌های Core Web Vitals بر پایهٔ پنجک هفتاد و پنجم (p75) تعریف شده‌اند: اگر ۷۵٪ بازدیدهای موبایل شما زیرِ حد «خوب» باشند، کل صفحه «خوب» محسوب می‌شود. آستانهٔ «خوب» برای LCP تاکنون ≤ ۲.۵ ثانیه است؛ اما برای رقابت‌پذیری در موبایل هدف عملی ما ≤ ۲.۰ ثانیه است.

چهار اصل کلیدی برای LCP زیر ۲ ثانیه

  1. TTFB کم: تحویل HTML اولیه باید برق‌آسا باشد (کش لبه، CDN، بهینه‌سازی سرور).
  2. در دسترس‌بودن سریع منبعِ LCP: خودِ تصویر/بلاک متن که LCP را می‌سازد باید زود درخواست و زود دانلود شود (preload، fetch priority، عدم lazy‑load روی هیرو).
  3. مسیر رندر کم‌اصطکاک: CSS حیاتی کم‌حجم و بدون انسداد، فونت بدون تأخیر بلاک‌کننده، JS به‌تعویق‌افتاده.
  4. اندازه و فرمت بهینهٔ LCP resource: تصویر مناسبِ سایزِ واقعی viewport، فرمت‌های مدرن (WebP/AVIF)، و تعریف ابعاد برای جلوگیری از CLS.

در ادامه، یک پلن اجرایی مرحله‌به‌مرحله می‌دهیم که بر همین اصول بنا شده است.

فاز صفر: اندازه‌گیری درست—میدانی و آزمایشگاهی

  • میدانی (Field): گزارش Core Web Vitals در Search Console و دیتاست CrUX برای دیدن p75 واقعی موبایل.
  • آزمایشگاهی (Lab): Lighthouse و WebPageTest برای تکرار سریع تغییرات. Lighthouse علاوه بر معرفی «عنصر LCP»، زنجیرهٔ زمانی آن را به چهار بخش می‌شکند (TTFB، بارگذاری منبع، decode/resize، render) تا بفهمید کجا گلوگاه دارید.

تذکر مهم: ابتدا عنصر LCP را شناسایی کنید (DevTools > Performance: روی نشان LCP کلیک کنید). ممکن است تصور کنید تصویر هیرو است، در حالی که در موبایل، بلاک متن بزرگ یا تصویر پس‌زمینهٔ CSS عامل اصلی باشد.

فاز ۱: پیِ محکم—TTFB و شبکه

۱) کش لبه و CDN

  • HTML را تا جای ممکن از نزدیک‌ترین نقطه به کاربر تحویل دهید (Full‑page caching + CDN).
  • برای صفحات شخصی‌سازی‌شده از Edge Side Includes یا partial caching استفاده کنید تا بخش‌های عمومی کش شوند.

۲) Early Hints (HTTP 103)

اگر سرور/CDN شما پشتیبانی کند، قبل از آماده‌شدن پاسخ نهایی، هدرهای preload/preconnect را با 103 Early Hints بفرستید تا مرورگر زودتر سراغ منابع حیاتی برود. این روش در کاهش تأخیر رندر LCP چشمگیر است.

۳) بهینه‌سازی پروتکل و فشرده‌سازی

  • HTTP/3 (QUIC) برای شبکه‌های موبایل پرنوسان پایدارتر است.
  • TLS 1.3 و Brotli را فعال کنید.
  • مطمئن شوید Keep‑Alive و 0‑RTT (اگر امن است) فعال‌اند.

حد پیشنهادی فاز ۱ (موبایل):

  • TTFB ≤ 800ms در p75.
  • DNS+TLS ≤ 300ms (در مخاطبان داخلی/منطقه‌ای معمولاً کمتر از این هم قابل دستیابی است).

فاز ۲: تنظیم دقیق منبع LCP

۴) تصویر/متن LCP را زودتر درخواست کنید

اگر LCP شما تصویر است:

همان بالای <head>:

<link

  rel="preload"

  as="image"

  href="/images/hero-mobile.avif"

  imagesrcset="/images/hero-mobile.avif 640w, /images/hero-tablet.avif 960w, /images/hero-desktop.avif 1280w"

  imagesizes="(max-width: 640px) 100vw, (max-width: 960px) 100vw, 1280px"

fetchpriority="high">

در خود عنصر:

    <img

  src="/images/hero-mobile.avif"

  srcset="/images/hero-mobile.avif 640w, /images/hero-tablet.avif 960w"

  sizes="100vw"

  width="640" height="400"

  loading="eager"

  decoding="async"

  fetchpriority="high"

alt="عنوان ارزش پیشنهادی محصول">

    چرا؟ preload زنجیرهٔ درخواست LCP را جلو می‌اندازد و Fetch Priority به مرورگر می‌گوید این منبع حیاتی است؛ ترکیب این دو معمولاً بهترین نتیجه را می‌دهد.

    هیچ‌وقت تصویر LCP را lazy‑load نکنید. Lazy‑load برای «پایین صفحه» عالی است، اما برای تصویر بالای صفحه (LCP) باعث تأخیر می‌شود.

    اگر LCP شما بلاک متن است:

    فونت‌ها را به‌موقع برسانید تا متن سریع رندر شود:

    <link rel="preload" as="font" type="font/woff2" href="/fonts/brand-regular.woff2" crossorigin>

<style> @font-face { font-family: 'Brand'; src: url('/fonts/brand-regular.woff2') format('woff2'); font-display: swap; }</style>

    استفاده از font-display: swap مانع از بلاک‌شدن متن و به‌تبع آن تأخیر در LCP می‌شود (در عین حال مراقب CLS ناشی از تغییر متریک فونت باشید).

    ۵) فرمت، ابعاد و رمزگذاریِ تصویر LCP

    • فرمت‌های مدرن: در موبایل، AVIF و WebP بیشترین کاهش سایز را می‌دهند؛ همراه با کیفیت بصری قابل‌قبول.
    • ابعاد دقیق: width/height یا aspect-ratio را تنظیم کنید تا هم از CLS جلوگیری شود، هم مرورگر بتواند فضا را پیش‌بینی و زودتر رندر کند.
    • Responsive Images: با srcset/sizes دقیقاً به viewport موبایل خدمت‌رسانی کنید تا oversize اتفاق نیفتد.
    • فشرده‌سازی هدفمند: برای هیرو در موبایل معمولاً 40–90KB (AVIF/WebP) یک بازهٔ مناسب است؛ اما کیفیت واقعی صفحه ملاک نهایی است.

    ۶) پس‌زمینهٔ CSS به‌عنوان LCP

    اگر هیروی شما با background-image ساخته شده، بدانید که ممکن است خودِ همان بک‌گراند LCP شود. در این حالت:

    • به‌جای background-image یک <img> جایگزین با object-fit: cover را در نظر بگیرید تا ابزارهای مدرن (preload/fetchPriority) را کامل به‌کار بگیرید؛ یا
    • از preload با as=”image” برای URL بک‌گراند استفاده کنید و حجم را دقیق کنترل کنید.

    فاز ۳: مسیر رندرِ کم‌اصطکاک (CSS/JS)

    ۷) CSS حیاتی کم‌حجم

    • Critical CSS بالای صفحه را استخراج و inline کنید (۱۴–۲۰KB هدف معقولی برای موبایل است).
    • استایل‌های غیرحیاتی را defer کنید:
    <link rel="preload" as="style" href="/css/above-the-fold.css">

<link rel="stylesheet" href="/css/above-the-fold.css">

<link rel="preload" as="style" href="/css/rest.css" onload="this.onload=null;this.rel='stylesheet'">

<noscript><link rel="stylesheet" href="/css/rest.css"></noscript>
    • از چندین فایل CSS غول‌آسا دوری کنید؛ تقسیم هوشمند و حذف CSS بلااستفاده، زمانِ در دسترس‌بودن LCP را جلو می‌اندازد.

    ۸) جاوااسکریپتِ تعاملی، اما پس از رندر

    • اسکریپت‌های غیرضروری را حذف یا به تعویق بیندازید (defer/async، یا تا تعامل کاربر).
    • هیدریشن‌های سنگین SPA را code‑split کنید؛ مسیر لندینگ را تا حد امکان SSR/SSG کنید تا HTML و LCP زود برسند.
    • اسکریپت‌های ثالث (analytics، تگ‌ها، ویجت‌ها) را بودجه‌بندی کنید؛ هرچه رقابت بیشتر، بودجهٔ JS کمتر.

    فاز ۴: ترتیب‌دادن شبکه—Hints هوشمند

    ۹) Preconnect و DNS Prefetch

    • برای دامنه‌های حیاتی (CDN تصاویر/فونت‌ها) از <link rel=”preconnect” href=”https://cdn.example.com” crossorigin> استفاده کنید تا هندشیک‌ها زودتر انجام شوند.

    ۱۰) Early Hints دوباره!

    • اگر کنترل سرور/ CDN را دارید، پیکربندی 103 Early Hints را در برنامهٔ تحویل HTML اعمال کنید تا مرورگر، قبل از آماده شدن پاسخ، preloadها را شروع کند.

    حدهای پیشنهادی (Mobile p75)

    این حدها «نقطهٔ شروع» هستند. بسته به بیزنس و دیزاین شما ممکن است تغییر کنند.

    • TTFB: ≤ 800ms
    • LCP Resource Request Start: ≤ 400ms بعد از شروع ناوبری (با preload/priority)
    • حجم تصویر LCP (موبایل): 40–90KB (AVIF/WebP)
    • Critical CSS: ≤ 14–20KB gzip
    • Blocking Time قبل از LCP: ≤ 300ms (JS حداقلی پیش از LCP)
    • LCP نهایی (p75 موبایل): ≤ 2000ms

    سازوکارهای CMS (وردپرس، شاپ/سایت‌های پویا)

    وردپرس:

    • کش تمام‌صفحهٔ واقعی در سطح سرور/پلاگین (LiteSpeed Cache، یا معادل‌های سازگار با سرور).
    • برای هیرو، Lazy Load را روی تصویر نخست خاموش کنید و fetchpriority=”high” بگذارید؛ اگر قالب به‌صورت پیش‌فرض lazy می‌کند، استثنا تعریف کنید.
    • Critical CSS خودکار (ابری یا بیلد) + حذف CSS بلااستفاده.
    • فونت‌ها را محلی و با preload + font-display: swap عرضه کنید.
    • اگر LCP شما بک‌گراند CSS است، امکان مهاجرت به <img> را ارزیابی کنید یا دست‌کم preload را برای همان URL پیکربندی کنید.

    فروشگاهی/پویا:

    • صفحهٔ لیست/جزییات محصول اغلب هیروهای بزرگ دارند؛ حدهای سخت‌گیرانه برای تصاویر موبایل تعیین کنید.
    • اجزای شخصی‌سازی را جدا از بخش هیرو رندر کنید تا LCP گرفتار منطق پویا نشود.
    • برای قیمت/موجودی از lazy hydration استفاده کنید تا بعد از LCP بارگیری شوند.

    چک‌لیست اجرایی LCP زیر ۲ ثانیه

    اندازه‌گیری

    • p75 موبایلِ فعلی در Search Console و CrUX را ثبت کنید.
    • در Lighthouse/WebPageTest: عنصر LCP و تفکیک زمانی آن را ببینید.

    سرور/شبکه

    • CDN و کش لبه فعال—TTFB ≤ 800ms.
    • Early Hints 103 برای preloadهای حیاتی (در صورت پشتیبانی).

    منبع LCP

    • اگر تصویر است: preload + fetchpriority=high + loading=eager + ابعاد مشخص.
    • اگر متن است: فونت WOFF2 محلی + preload + font-display: swap.
    • اگر بک‌گراند CSS است: مهاجرت به <img> یا preload URL بک‌گراند.

    رندر

    • Critical CSS inline ≤ 20KB؛ بقیه CSS با بارگیری غیرهمزمان.
    • JS غیرحیاتی defer/async؛ اسکریپت‌های ثالث را بودجه‌بندی کنید.
    • جلوگیری از CLS با تعیین ابعاد/نسبت‌ها.

    بازبینی

    • رگرسیون را با RUM یا Analytics سفارشی پایش کنید.
    • بودجه‌ها را در CI/CD enforce کنید (Lighthouse CI، WebPageTest API).

    مثالِ «قبل/بعد» برای تصویر LCP

    قبل (رایج و مشکل‌ساز):

    <img src="/images/hero.jpg" loading="lazy" alt="">

<link rel="stylesheet" href="/css/app.css">

<script src="/js/vendor.js"></script>

    بعد (بهینه برای LCP):

    <link rel="preload" as="image" href="/images/hero.avif" fetchpriority="high">

<link rel="preload" as="style" href="/css/critical.css">

<link rel="stylesheet" href="/css/critical.css">

<img src="/images/hero.avif"

     width="640" height="384"

     loading="eager" decoding="async" fetchpriority="high"

     alt="ارزش پیشنهادی محصول برای موبایل">

<script defer src="/js/app.js"></script>
    • loading=”lazy” برای تصویر LCP حذف شد.
    • preload و fetchpriority=”high” افزوده شد.
    • CSS حیاتی جدا و زودتر در دسترس قرار گرفت.

    پرسش‌های متداول کوتاه

    آیا همیشه تصویر LCP است؟

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

    چرا «۲ ثانیه» و نه ۲.۵ ثانیه؟

    ۲.۵ ثانیه «خوب» است، اما هدف‌گذاری ۲.۰ ثانیه در موبایل، حاشیهٔ امن ایجاد می‌کند و روی شبکه‌های واقعی (نوسان 4G/5G، CPUهای ضعیف‌تر) پایداری می‌دهد.

    آیا صرفاً با فشرده‌سازی تصویر به زیر ۲ ثانیه می‌رسیم؟

    معمولاً نه. زمان درخواست منبع LCP و انسدادهای رندر (CSS/فونت/JS) نقش کلیدی دارند؛ باید همهٔ زنجیره را با هم بهینه کنید.

    جمع‌بندی

    برای رسیدن به LCP زیرِ ۲ ثانیه در موبایل باید زنجیرهٔ کامل را باهم ببینید: TTFB پایین، درخواست زودهنگام منبع LCP (preload + fetchpriority)، CSS/فونت بدون انسداد، و تصویر/متن بهینه. این یک پروژهٔ تک‌مرحله‌ای نیست؛ یک سیستم است که باید در چرخهٔ توسعه شما نهادینه شود. وقتی این بلوغ به‌دست بیاید، نه‌تنها امتیازهای شما سبز می‌شوند، بلکه درآمد و نرخ تبدیل هم به‌طور پایدار رشد می‌کند.

    اگر می‌خواهید این مسیر را سریع، کم‌ریسک و نتیجه‌محور پیش ببرید، تیم ما این کار را روزانه انجام می‌دهد: از عیب‌یابی LCP و پیاده‌سازی preload/fetchpriority/critical CSS تا تنظیم سرور و Early Hints—همه با گزارش‌های قبل/بعد و تضمین بهبود p75.

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

    منابع کوتاه برای مطالعهٔ بیشتر

    • تعریف و عناصرِ نامزد LCP (تصویر، متن، پوستر ویدئو، و حتی پس‌زمینهٔ CSS). (web.dev)
    • آستانه‌ها و p75 در Core Web Vitals و ارتباط با جستجو. (web.dev)
    • Fetch Priority و اولویت‌دهی به تصویر LCP + نمونهٔ بهبود. (web.dev)
    • Early Hints (103) برای preload/preconnect پیش از پاسخ نهایی. (MDN Web Docs)
    • فونت‌ها و اثرشان بر LCP/CLS و بهترین شیوه‌ها. (web.dev)

    آموزش فشرده پشتیبانی سایت

    فقط با ۲۰ ساعت آموزش یاد بگیر سایت وردپرسیت رو اصولی نگهداری کنی !!!
    اطلاعات بیشتر

    فهرست این مقاله شامل:

    آموزش فشرده پشتیبانی سایت

    فقط با ۲۰ ساعت آموزش یاد بگیر سایت وردپرسیت رو اصولی نگهداری کنی !!!
    اطلاعات بیشتر

    جدیدترین اخبـار را در شبکه هــای اجتــماعی ما دنبال کنید

    ورود به صفحه اینستاگرام پشتیبان وردپرس

    دیدگاهتان را بنویسید

    نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

    چک لیست نگهداری سایت
    تجربه ۹ سال پشتیبانی در یک PDF
    به این فایل نیاز دارم