Largest Contentful Paint (LCP): Diagnose TTFB, Load Delay & Render Delay

Largest Contentful Paint (LCP) measures how long it takes for the largest eligible content element in the initial viewport to render. It is one of the three Core Web Vitals alongside Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS).

On many article pages, the LCP element is a featured image or hero image. On other pages it may be a large heading or text block. This distinction matters because the correct optimization depends on what actually becomes the LCP element.

A slow LCP should therefore not automatically lead to image compression, CDN migration, cache-plugin installation, or a hosting upgrade. First identify the LCP element and determine where the delay occurs in its loading and rendering path.

This guide is intentionally LCP-specific. For INP responsiveness, CLS layout stability, or a combined Core Web Vitals workflow, use the dedicated guides rather than expanding this page into multiple metric intents.

Last verified: September 24, 2026. LCP definitions, browser behavior and tooling can evolve; major changes should be rechecked against current Chrome/web.dev documentation.

---

---

1. LCP Performance Thresholds

LCP	Classification	Meaning
≤ 2.5 seconds	Good	Primary visible content renders within the recommended range
> 2.5–4.0 seconds	Needs Improvement	Users may perceive delayed primary content
> 4.0 seconds	Poor	Primary content is substantially delayed

Evaluate LCP at the 75th percentile of page visits rather than treating one individual test result as the site's definitive performance.

---

2. Identify the Actual LCP Element

Before optimizing anything, determine which element is being reported as LCP.

Common candidates include:

• <img> elements such as featured or hero images.
• <image> elements inside SVG.
• Video poster images or the first rendered video frame.
• Elements with eligible CSS background-image: url(...) content.
• Large block-level text such as article headings or introductory copy.

Chrome also applies heuristics that can exclude content such as fully transparent elements, low-entropy placeholders and some full-viewport background-like elements from being treated as LCP candidates.

The LCP candidate can also change between mobile and desktop layouts.

A desktop hero image might be the largest visible element while a large heading becomes the LCP candidate on mobile.

---

3. Break LCP into Four Components

A practical LCP model is:

Navigation Start
      ↓
Time to First Byte
      ↓
Resource Load Delay
      ↓
Resource Load Duration
      ↓
Element Render Delay
      ↓
Largest Contentful Paint

These stages collectively explain where the LCP time is being spent.

web.dev's current LCP optimization guidance uses the following proportions as diagnostic guidelines rather than strict thresholds. The important objective is to keep avoidable resource-load delay and element-render delay close to zero while maintaining a good overall LCP.

These percentages are diagnostic guidelines, not hard thresholds. If LCP already meets the 2.5-second target, the exact ratio matters less than eliminating obvious avoidable delay.

---

4. Time to First Byte

Time to First Byte (TTFB) covers the period before the browser receives the first byte of the HTML response.

Potential contributors include:

• Redirects.
• DNS and connection setup.
• Network distance.
• Server processing.
• PHP execution.
• Database queries.
• Cache misses.
• External API dependencies.

A high TTFB delays every frontend step that follows because the browser cannot discover HTML-referenced LCP resources until the document begins arriving.

Continue with our TTFB and Server Response Time Guide.

---

5. Resource Load Delay

Resource load delay is the time between receiving the first part of the HTML response and starting the request for the LCP resource.

This can become unnecessarily large when the browser cannot discover the resource immediately.

Examples include:

• The hero image is injected by JavaScript.
• The image URL exists only inside an external stylesheet.
• A JavaScript lazy-loading library hides the real src.
• The application waits for client-side rendering before inserting the image.

This component is often overlooked because developers focus on how quickly the image downloads rather than when that download starts. web.dev recommends making the LCP resource discoverable as early as possible; a useful diagnostic is whether it begins loading alongside the earliest critical resources after TTFB rather than sitting idle while CSS or JavaScript first reveals it.

---

6. Make the LCP Resource Discoverable in Initial HTML

For an important featured image, prefer direct HTML discovery:

<img
  src="/images/hero.webp"
  width="1200"
  height="675"
  alt="Article hero image">

Avoid architectures where the browser must first download and execute JavaScript before learning that the primary image exists.

---

7. Do Not Lazy-Load the LCP Image

Lazy loading is useful for below-the-fold images, but the actual LCP image should not be lazy-loaded because that introduces unnecessary resource-load delay.

Avoid:

<img
  src="/images/hero.webp"
  loading="lazy"
  alt="Main hero image">

when that image is immediately visible and likely to become LCP.

---

8. Use fetchpriority for Important Images Carefully

A likely LCP image can receive a priority hint:

<img
  src="/images/hero.webp"
  width="1200"
  height="675"
  fetchpriority="high"
  alt="Main article image">

Use fetchpriority="high" when an image is genuinely likely to be the LCP element. Google currently cautions that assigning high priority to more than one or two images makes prioritization less useful.

If many resources are promoted simultaneously, the browser loses useful prioritization information and critical resources can compete with one another.

For the broader rules around fetchpriority, preload, preconnect and dns-prefetch, use the Resource Hints Optimization Guide. This LCP guide should only apply those techniques when the LCP subpart analysis shows a discovery or priority problem.

---

9. Preload When Discovery Would Otherwise Be Late

If the LCP resource cannot be discovered from the initial HTML—for example because it is referenced only through CSS—preloading can make that critical dependency discoverable earlier.

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

Use preload selectively. It is not a substitute for clean document architecture.

---

10. CSS Background Images Can Delay Discovery

A hero image defined only in an external stylesheet requires the browser to:

1. Receive HTML.
2. Discover the stylesheet.
3. Download the stylesheet.
4. Parse CSS.
5. Discover the background image.
6. Start the image request.

This dependency chain can increase resource load delay.

Where appropriate, use direct image markup or preload the critical background resource.

---

11. Resource Load Duration

Once the LCP image request starts, the browser must transfer the resource.

Resource load duration can be improved through:

• Appropriate image dimensions.
• Efficient compression.
• Modern formats when beneficial.
• Responsive images.
• Caching.
• Reducing network distance where appropriate.

Do not assume format conversion alone fixes LCP.

---

12. Resize Before Compressing

An oversized image wastes bandwidth regardless of format.

If the largest rendered width is approximately 900 pixels, delivering a 4000-pixel original is usually unnecessary.

Generate sensible responsive variants instead.

---

13. Use srcset for Responsive Delivery

Example:

<img
  src="hero-768.webp"
  srcset="
    hero-480.webp 480w,
    hero-768.webp 768w,
    hero-1200.webp 1200w"
  sizes="(max-width: 768px) 100vw, 900px"
  width="1200"
  height="675"
  fetchpriority="high"
  alt="Responsive hero image">

This lets different devices select an appropriate source rather than forcing every visitor to download the largest file.

---

14. WebP vs AVIF

WebP and AVIF can both provide efficient web-image delivery.

Do not assume AVIF always wins.

Compare:

• Actual bytes.
• Visual quality.
• Encoding workflow.
• Responsive variants.

Format selection should be based on the actual output, not a fixed percentage claim.

For responsive images, srcset, sizes, WebP/AVIF, intrinsic dimensions and image-specific lazy-loading behavior, use the Image Optimization Guide.

---

15. Network Contention Can Slow the LCP Resource

An optimized image can still download slowly when it competes with many simultaneous resources.

Examples include:

• Multiple high-priority images.
• Large fonts.
• JavaScript bundles.
• Third-party advertising.
• Analytics libraries.

Prioritize the genuinely critical resource rather than promoting everything.

---

16. Element Render Delay

Suppose the hero image finishes downloading at 1.5 seconds, but LCP occurs at 3.2 seconds.

The remaining delay may come from:

• Render-blocking stylesheets.
• Synchronous JavaScript.
• Client-side rendering.
• Long main-thread tasks.
• A/B testing code.
• The element being hidden initially.

Compressing the image further may not solve this problem.

If the trace shows large style, layout or paint work after the LCP resource is available, use the DOM Size & Rendering Performance Guide to investigate rendering scope rather than treating the problem as another image-download issue.

---

17. Do Not Hide the LCP Element Until JavaScript Runs

An architecture such as:

Image downloads
      ↓
JavaScript bundle executes
      ↓
Component mounts
      ↓
Image becomes visible

creates unnecessary render delay when the main content could have been present in the initial page output.

---

18. Reduce Render-Blocking CSS

Large stylesheets can delay rendering of the LCP element even after the resource itself is available.

Review:

• Unused theme CSS.
• Page-builder CSS.
• Plugin styles loaded globally.
• Font stylesheets.

Continue with the Render-Blocking Resources Guide when initial CSS/JavaScript dependencies are delaying rendering. If the issue is specifically unused CSS, stylesheet architecture or style recalculation, use the CSS Performance Optimization Guide.

---

19. Large JavaScript Tasks Can Delay LCP

Even when JavaScript is not responsible for creating the LCP element, large scripts can occupy the main thread and postpone rendering.

Audit:

• Page-builder runtime code.
• Third-party widgets.
• Analytics.
• Advertising.
• Client-side application hydration.

Reducing main-thread work can help both LCP and INP. For broader first-party script execution, use the JavaScript Performance Optimization Guide. If ads, analytics, chat, consent or embedded vendors are the source of network/main-thread contention, use the Third-Party Script Performance Guide.

---

20. Text Can Be the LCP Element

Not every LCP problem involves images.

A large article heading or hero paragraph may become the LCP candidate.

In that case, investigate:

• TTFB.
• Render-blocking CSS.
• Web fonts.
• Client-side rendering.
• Main-thread work.

Image compression will not help a text-based LCP.

---

21. Fonts Can Delay Text-Based LCP

If an important heading relies on a web font, font loading can affect when the final text is rendered.

Audit:

• Font origin.
• Number of weights.
• Font file size.
• Preload strategy.
• Fallback behavior.

Do not preload every font variation. For font discovery, preload, fallback and layout-stability decisions, use the Web Font Performance Optimization Guide.

---

22. WordPress Featured Images

On WordPress articles, the featured image is frequently an LCP candidate.

Check whether:

• The image is in initial HTML.
• It is accidentally lazy-loaded.
• It uses appropriate responsive sizes.
• Its dimensions are present.
• It is hidden until JavaScript initializes.

---

23. Page Cache Can Improve the TTFB Component

For eligible public WordPress pages, full-page caching can avoid repeating much of the PHP and database work needed to generate identical HTML. That can improve the TTFB subpart when uncached page generation is the bottleneck.

Keep the detailed server-response investigation in the TTFB Optimization Guide. Do not cache personalized or private responses incorrectly, and do not treat page caching as a fix for resource load delay or element render delay.

---

24. Redis Solves a Different Performance Layer

Redis object caching can reduce repeated application and database work for dynamic requests.

It does not directly:

• Compress the hero image.
• Remove render-blocking CSS.
• Prioritize an LCP resource.

Continue with our Redis vs Memcached Guide.

---

25. PHP-FPM Can Affect Dynamic TTFB

On Nginx-based WordPress servers, saturated PHP-FPM workers can cause dynamic requests to queue.

That can increase TTFB before the browser receives the HTML containing the LCP resource.

Continue with our PHP-FPM Tuning Guide.

---

26. CDN Does Not Automatically Fix Every LCP Problem

A CDN can help with resource delivery and geographic distance, but it cannot directly fix:

• Late resource discovery.
• Lazy-loaded hero images.
• Client-side rendering delays.
• Long JavaScript tasks.
• Render-blocking CSS.

Use a CDN when network delivery is actually part of the measured bottleneck.

For repeat-load freshness and revalidation, use the Browser Caching Guide. For HTTP text compression, use the Brotli & Gzip Compression Guide. Those layers can support delivery efficiency but do not replace LCP subpart diagnosis.

---

27. Mobile LCP Can Have a Different Element

Responsive design can change which element is largest in the viewport.

For example:

• Desktop may show a large hero image.
• Mobile may crop or hide the image.
• A heading can then become the mobile LCP candidate.

Always check both device categories rather than optimizing only a desktop Lighthouse test.

---

28. Field Data vs Lab Data

Field data tells you how real users experience the site across devices, networks, geographies and cache states. Where CrUX data is available for the affected URL or origin, use it to establish whether a real-user LCP problem exists before treating one Lighthouse run as representative.

Lab data helps diagnose a reproducible page under controlled conditions. If Lighthouse and CrUX disagree, use field data to understand actual user experience and the lab trace to investigate why. Confirm whether PageSpeed Insights is showing URL-level or origin-level CrUX data before drawing page-specific conclusions.

A useful workflow is:

1. Confirm poor LCP in field data.
2. Identify affected URL groups.
3. Reproduce representative pages in the lab.
4. Inspect the LCP element and subparts.
5. Apply a targeted fix.
6. Monitor subsequent field data.

---

29. Measurement Nuance for Cross-Origin LCP Images

Modern Chromium versions expose a coarsened render time for cross-origin LCP images even without a Timing-Allow-Origin response header. Where possible, setting an appropriate Timing-Allow-Origin header can still improve measurement accuracy across tools and browsers.

If you collect your own RUM, prefer Google's web-vitals library over hand-rolling the LCP calculation because the library handles several metric/API edge cases for you.

---

30. Do Not Chase Lighthouse 100

Lighthouse is useful for diagnosis, but a perfect lab score is not the objective.

Real visitors use:

• Different mobile devices.
• Different network conditions.
• Different geographic locations.
• Different browser states.

Prioritize actual Core Web Vitals outcomes and user experience.

---

31. Common LCP Optimization Mistakes

• Compressing every image before identifying LCP.
• Lazy-loading the primary hero image.
• Injecting the LCP element with JavaScript.
• Assigning high fetch priority to many images.
• Preloading unnecessary resources.
• Ignoring TTFB.
• Ignoring render-blocking CSS.
• Assuming AVIF alone fixes LCP.
• Upgrading hosting without confirming a backend bottleneck.
• Optimizing desktop while mobile remains poor.

---

32. Practical LCP Diagnostic Workflow

1. Confirm the affected URL group using field data.
2. Identify the LCP element.
3. Measure TTFB.
4. Determine when the LCP resource request starts.
5. Check whether resource discovery is delayed.
6. Measure resource download duration.
7. Measure the delay between resource completion and rendering.
8. Optimize the largest unnecessary delay first.
9. Re-test mobile and desktop.
10. Monitor subsequent field data.

---

33. LCP Optimization Decision Matrix

Observed Problem	Investigate First
HTML starts late	TTFB, redirects, caching, application/server processing
Hero image request starts late	HTML discovery, lazy loading, CSS background, JavaScript injection
Image download takes too long	Dimensions, compression, format, network distance, contention
Image downloads quickly but renders late	CSS, JavaScript, main-thread work, client-side rendering
Text is LCP	TTFB, fonts, CSS, client rendering, main-thread work

---

34. LCP and Search Performance

LCP is part of Core Web Vitals and page experience, but passing a particular LCP threshold does not guarantee a ranking increase.

Search performance also depends on:

• Relevance.
• Content usefulness.
• Crawlability.
• Indexability.
• Internal linking.
• Competition.
• Other quality signals.

Optimize LCP primarily because faster primary-content rendering improves user experience and technical quality.

---

35. LCP Specialist Guide Map

The broader Core Web Vitals pillar remains the parent framework for LCP, INP and CLS together; this specialist page should stay focused on LCP diagnosis and remediation.

---

36. Prevent LCP Regressions

LCP can regress after a theme change, new hero treatment, larger featured image, font change, added third-party script, cache change or server update even when the page previously passed.

Track representative article and commercial templates and record the LCP element plus its four subparts before and after important releases. Use the Web Performance Budgets & Regression Monitoring Guide for ongoing guardrails.

---

37. LCP Optimization Checklist

• Target LCP of 2.5 seconds or less at the 75th percentile.
• Identify the actual LCP element first.
• Measure TTFB separately.
• Measure resource load delay.
• Make the LCP resource discoverable in initial HTML.
• Do not lazy-load the primary LCP image.
• Use high fetch priority only for genuinely important resources.
• Use preload selectively when resource discovery would otherwise be late.
• Resize oversized images.
• Use responsive image variants.
• Choose WebP or AVIF according to actual output.
• Reduce unnecessary network contention.
• Investigate element render delay after the resource downloads.
• Reduce render-blocking CSS and excessive JavaScript.
• Optimize web fonts when text is the LCP candidate.
• Use page caching where eligible backend generation is slow.
• Do not assume Redis directly fixes frontend LCP.
• Review mobile and desktop independently.
• Use field data to validate improvements.

Frequently Asked Questions

What is a good LCP score?

A good Largest Contentful Paint value is 2.5 seconds or less at the 75th percentile of page visits.

What usually causes poor LCP?

Common causes include slow TTFB, late discovery of the LCP resource, lazy-loaded hero images, oversized media, network contention, render-blocking CSS, web fonts, JavaScript execution, and main-thread work.

Should I lazy-load my hero image?

Usually not when the hero image is visible immediately and is the likely LCP candidate. Lazy loading can delay when its request starts.

Does WebP or AVIF automatically fix LCP?

No. A smaller resource can reduce download duration, but LCP may still be limited by TTFB, late resource discovery, CSS, JavaScript, or element render delay.

Does faster hosting improve LCP?

It can help when server response time, PHP execution, database work, or origin capacity contributes to high TTFB. It cannot directly fix late image discovery, render-blocking frontend resources, or browser main-thread work.

Can text be the LCP element?

Yes. Large headings and text blocks can become the LCP candidate, particularly on layouts where a hero image is small, hidden, or absent.

Should I preload every above-the-fold image?

No. Preload should be reserved for genuinely critical resources that would otherwise be discovered too late.

Does good LCP guarantee higher rankings?

No. LCP is one page-experience metric. Search visibility depends on many technical, relevance, quality, internal-linking, and competitive factors.