LCP (Largest Contentful Paint)

What it represents

LCP represents the moment a page’s main, above-the-fold content becomes visible enough for users to feel that loading has meaningfully progressed. It does not measure when everything has finished loading; rather, it focuses on the single largest visual element within the initial viewport. That element can change during loading as layout and content evolve, so the browser tracks a sequence of candidates and finalises the one that ends up largest when the page stabilises or the user interacts.

Because LCP reflects what users actually see first, it is a more actionable signal than total load or onload. A fast LCP suggests the hero section appears promptly, even if other parts of the page continue to load. Conversely, a slow LCP often points to delays in image discovery, resource prioritisation, server response, CSS blocking, or client-side rendering that postpones the hero’s paint.

In image-led designs, the LCP element is typically the hero image or a video poster. On content-heavy pages, a large headline or introductory paragraph can be the LCP element. This user-centric focus explains why LCP is strongly correlated with perceived speed and early engagement metrics like bounce rate and time to first interaction.

Threshold bands (field data, Core Web Vitals):

Core Web Vitals classifies LCP performance using field data (real-user monitoring) at the 75th percentile, reported separately for mobile and desktop. The current target bands are widely referenced by SEO teams and developers as the benchmark for acceptable user experience at scale.

• Good: ≤ 2.5 seconds
• Needs improvement: > 2.5s to ≤ 4.0s
• Poor: > 4.0 seconds

These bands are applied to field distributions, not single test runs. Lab tools such as Lighthouse estimate LCP in a controlled environment, which is useful for debugging but may differ from field results due to network variability, device capability, and real-world page states (e.g., personalisation, A/B tests, or third-party content). Teams should monitor both lab and field views to diagnose issues and confirm user impact at the 75th percentile.

What LCP represents for UX

LCP is a proxy for when a page feels ready: the moment the primary content appears, users can orient themselves, assess relevance, and decide whether to continue. A fast LCP reduces uncertainty and abandonment, particularly on slower mobile connections where every second is noticeable. For ecommerce and content sites alike, a snappy hero section helps users form a positive first impression and increases the likelihood of scrolling, searching, or tapping a call to action.

User perception is not strictly linear with time. Many users perceive sub‑1 second as instant, 1–2 seconds as acceptable, 2–4 seconds as slow but tolerable, and beyond 4 seconds as frustrating. LCP focuses the team on shaving critical seconds from the first view rather than chasing marginal gains later in the page lifecycle that users may never notice or reach.

Because LCP targets the initial viewport, design and layout decisions can change the LCP element entirely. For example, placing a very tall hero image above the fold may dominate LCP, whereas moving it slightly below the fold may shift LCP to a headline. This linkage between UX design and performance outcome makes cross‑functional coordination essential when refining hero sections, fonts, and imagery.

Candidate scope: LCP considers <img> elements, <image> inside SVG, and the poster image of <video>. CSS background-image is not counted as an LCP candidate even if it visually represents the “hero” image.

Counted candidates

• HTML <img> elements, including responsive images resolved via srcset/sizes
• <image> elements within SVG documents
• Poster images for <video> elements (not the video frames themselves)
• Large block-level text nodes (e.g., headings or prominent paragraphs) rendered with web or system fonts

Not counted as LCP

• CSS background-image, even if it visually appears as the hero image
• Canvas/WebGL draws, inline SVG shapes, and video frames in motion

The browser continually evaluates LCP candidates as layout changes. It stops considering new candidates when the page is hidden or upon the first user interaction. If an intended hero image is supplied via CSS backgrounds, the LCP candidate may fall back to a headline or another large element, which can misalign performance efforts with visual priorities. Prefer semantic <img> for hero images when LCP matters.

Implementation notes

Identify and measure the real LCP element

Use Chrome DevTools (Performance panel), Lighthouse, or a PerformanceObserver for “largest-contentful-paint” to confirm which node is the LCP candidate in lab runs. In field data, rely on RUM tooling or the Chrome UX Report for distribution and percentiles. Validate mobile and desktop separately; viewport differences can change the candidate and the optimisation levers you prioritise.

Key levers that move LCP

1. Reduce server response time (TTFB): cache at the edge, optimise backend queries, enable compression, and use HTTP/2 or HTTP/3. Faster TTFB brings forward all subsequent work, often yielding a sizeable LCP win on mobile networks.
2. Prioritise the LCP resource: do not lazy‑load the LCP image; provide width/height or aspect-ratio to avoid reflow; supply correct sizes; add rel=preload for the exact URL when discovery is late; and consider fetchpriority="high" to signal importance without duplicate requests.
3. Minimise render‑blocking CSS and JS: inline critical CSS for the above-the-fold, defer or async non‑critical scripts, and avoid client‑rendered heroes when server‑side rendering can paint earlier. Excessive hydration and main‑thread work delay LCP even when the image arrives on time.
4. Optimise the media itself: serve appropriately sized images via srcset/sizes, modern formats like WebP or AVIF where supported, efficient encoding, and caching. Decode and render costs matter; oversized images inflate transfer and paint time without adding visual value.
5. Stabilise fonts and layout: use font-display strategies to prevent invisible text delaying a text LCP; preconnect to font origins; and set explicit dimensions for images and containers to avoid layout shifts that can change the LCP candidate mid‑load.

Common pitfalls

• Lazy‑loading the hero image or discovering it late via CSS or client‑side routing
• Oversized hero assets or missing responsive variants, especially on mobile
• Blocking CSS/JS and long main‑thread tasks that postpone first paint of the hero
• Hero imagery implemented as CSS backgrounds, removing it from LCP candidacy

Comparisons

LCP vs FCP (First Contentful Paint)

FCP marks when the first pixel is painted, which could be a small logo or background. LCP focuses on the largest meaningful element. A page can have a fast FCP and a slow LCP if the hero is delayed by render‑blocking CSS, slow images, or client rendering. For perception of readiness, LCP is generally more predictive than FCP.

LCP vs TTFB (Time to First Byte)

TTFB measures server responsiveness. It is a leading indicator for LCP because late HTML delays discovery of critical resources. However, excellent TTFB with heavy CSS/JS or large images can still yield a slow LCP. Effective optimisation couples fast TTFB with early discovery and high priority for the hero content.

LCP vs CLS (Cumulative Layout Shift) and INP (Interaction to Next Paint)

CLS tracks visual stability, and INP reflects responsiveness during interactions. LCP is about loading. All three compose a balanced view of page experience. For instance, an image with no dimensions might paint quickly (acceptable LCP) but then shift layout (poor CLS), undermining perceived quality. Good LCP should not come at the expense of stability or responsiveness.

FAQs

Does LCP include CSS background images?

No. CSS background-image is not an LCP candidate. If your hero is implemented as a background, the browser will likely choose a large text block or another image as the LCP element. To target LCP improvements on a hero image, use an <img> (with responsive attributes) or a <video> poster, and provide explicit dimensions and appropriate priority.

Why does the LCP element change between visits?

Viewport size, personalised content, late-loading banners, A/B variations, and layout shifts can change which element ends up largest at paint time. Third‑party widgets and consent prompts may also displace the intended hero. Stabilising layout, reserving space, and keeping the hero semantic and early in the DOM reduce variability.

How are SPA route changes handled for LCP?

Modern browsers attempt to detect “soft navigations” in single‑page apps and report LCP for route transitions. Coverage and tooling support continue to evolve, and field reporting may differ across analytics stacks. As a rule, prioritise making the initial load fast, then ensure route changes discover and prioritise new hero content early, with minimal main‑thread work and blocking assets.

Should I preload the LCP image or use fetchpriority?

If the LCP image is discovered late (e.g., deep in HTML or CSS), rel=preload or fetchpriority="high" can improve priority and start the request earlier. Preload is stronger but must match the final URL and type exactly to avoid duplication and cache misses. In many cases, ensuring the image is not lazy‑loaded, is present early in the HTML, and uses correct srcset/sizes covers most gains with less complexity.

Do web fonts affect a text LCP?

Yes. If a large headline is the LCP element and the font blocks rendering (e.g., no fallback and font-display: block), LCP will be delayed. Prefer font-display: swap or optional, preconnect to the font origin, and limit large, render‑blocking font files. Stabilise text layout with predictable fallbacks to avoid shifts that might change the LCP candidate.