Largest Contentful Paint: diagnosis and optimization

LCP measures how quickly the largest visible element on a page becomes visible to a user. Good LCP (under 2.5 seconds) signals to Google that the page renders fast enough to satisfy users. Poor LCP (over 4 seconds) signals the opposite, with ranking consequences.

LCP is one of the three Core Web Vitals Google uses as a ranking signal. The metric was introduced in 2020 and became a ranking factor in 2021. By 2026, Google representatives including Martin Splitt and John Mueller have confirmed in multiple public Q&A sessions that LCP is part of the page experience signal, with stronger effect in competitive queries where rendering performance separates similar-quality pages, particularly on mobile.

Here’s the picture: what LCP actually measures, how to diagnose poor LCP, and the optimization patterns that consistently produce improvement versus the patterns that produce marginal change.

What LCP measures:

LCP records the render time of the largest visible content element within the viewport during the page’s loading phase. The element is typically:

A hero image or product image
A video poster frame
A block of text (a heading or a paragraph that takes the most visual space)
A background image displayed as content
An SVG or other inline image

The browser identifies the LCP element by measuring the rendered size of candidates as the page loads. Once an element is rendered and the user begins interacting with the page (or the page finishes loading), the final LCP value gets recorded.

The thresholds Google uses:

Performance	LCP value
<strong>Good</strong>	≤ 2.5 seconds
<strong>Needs improvement</strong>	2.5 – 4.0 seconds
<strong>Poor</strong>	> 4.0 seconds

The thresholds apply to the 75th percentile of page loads. A site whose median LCP is 1.5 seconds but whose 75th percentile is 5 seconds is classified as poor, because the experience for the slowest quarter of users determines the rating.

The four components of LCP:

LCP isn’t a single thing to optimize. It’s the sum of four sequential components, each of which can be the bottleneck:

Component	What it measures	Typical share of LCP
<strong>TTFB (Time to First Byte)</strong>	Server response time	20-40%
<strong>Resource load delay</strong>	Time between TTFB and when the LCP resource starts loading	0-30%
<strong>Resource load time</strong>	Time to download the LCP resource	10-50%
<strong>Element render delay</strong>	Time between LCP resource being fully loaded and element being rendered	0-20%

The diagnosis starts with which component dominates. A site with LCP of 4.5 seconds composed of 3 seconds of TTFB and 1.5 seconds of everything else has a server problem. A site with LCP of 4.5 seconds composed of 500ms TTFB and 4 seconds of resource load time has an image or JavaScript problem.

Chrome DevTools Performance panel, Lighthouse, and PageSpeed Insights all show the component breakdown. For real-user monitoring data, services like Cloudflare Browser Insights, New Relic, Datadog Real User Monitoring, or SpeedCurve report the components from actual page loads.

TTFB: the foundation:

TTFB is the first component of LCP and often the easiest to improve. The factors that contribute:

Server processing time. The application generating the response. Database queries, business logic, template rendering all run during this window.
Network latency. The time for the request to reach the server and the response to start coming back. Geographic distance matters.
TLS handshake. On first-time connections, the TLS negotiation adds 100-300ms.
DNS resolution. Usually fast, but slow DNS can add hundreds of milliseconds.

The optimizations that consistently move TTFB:

CDN with edges near users. Reduces network latency by serving cached responses from nearby locations.
Caching the HTML response itself. A site that serves cached HTML for the homepage cuts TTFB by the full server processing time.
Database query optimization. A page that runs 50 unindexed queries on every load can drop hundreds of milliseconds with proper indexes.
HTTP/2 or HTTP/3 with connection reuse. Reduces handshake overhead on subsequent requests.
Origin shielding to reduce variance in cache miss latency.

A site with TTFB consistently under 500ms has eliminated TTFB as the bottleneck. A site with TTFB over 1 second has 60-80% of its LCP improvement potential in TTFB alone.

Resource load delay: the discovery problem:

Resource load delay is the time between TTFB completing and the LCP resource starting to download. The delay exists when the browser can’t begin fetching the LCP resource until other resources are processed.

Common causes:

The LCP resource is referenced in CSS, not HTML. The browser has to download and parse the CSS before discovering the background image.
The LCP resource is loaded by JavaScript. The browser has to download and execute JS before discovering the resource.
The LCP image is lazy-loaded. Lazy-loading is correct for below-fold images; for above-fold LCP elements, it delays the load by waiting for the image to enter the viewport.
The LCP resource requires authentication or session state that takes time to establish.

The fixes:

Preload the LCP resource. <link rel="preload" as="image" href="hero.webp"> tells the browser to start fetching immediately, before normal discovery.
Mark LCP images with fetchpriority=”high”. A 2022 addition that tells the browser to prioritize specific resources, overriding the default heuristics the browser uses to decide what loads first.
Remove lazy-loading from above-fold images. Lazy-load only below-fold content.
Inline critical CSS so background-image references in CSS don’t require a separate CSS download.
Reference LCP images directly in HTML with <img> tags rather than loading them via CSS or JS.

A note on preload and fetchpriority misuse: both hints work by overriding browser prioritization, and overriding too much breaks the system. The browser’s default priority logic distinguishes critical from non-critical resources reasonably well; preload hints applied to non-LCP resources compete with the actual LCP candidate for bandwidth. Common failure patterns: preloading every hero image variant (only one will render), preloading fonts that aren’t used above the fold, preloading the wrong responsive image size, marking multiple images as fetchpriority="high" (which cancels the priority signal). The correct discipline is one preload per page targeting the actual LCP element, plus fetchpriority="high" on that element only.

Resource load time: the bandwidth problem:

Resource load time is the actual download time for the LCP resource. The factors:

Resource size. A 2MB hero image takes longer to download than a 200KB optimized version.
Image format and compression. WebP and AVIF produce smaller files at the same visual quality as JPEG.
Responsive images. Serving a 4000-pixel-wide image to a mobile viewport wastes bandwidth.
Compression on the wire. Brotli compression for text resources (HTML, CSS, JS) typically produces 15-20% smaller files than gzip, based on Cloudflare’s published comparisons; Google’s original Brotli announcement reported a median around 17%.
HTTP/2 multiplexing. Older HTTP/1.1 connections serialize requests; HTTP/2 and HTTP/3 fetch resources in parallel.

The optimizations:

Convert images to modern formats. WebP for broad compatibility, AVIF for additional savings where supported.
Implement responsive images. <img srcset> and <picture> elements let the browser choose the right size for the viewport.
Optimize image quality. Aggressive quality reduction (typically 75-80% JPEG, lower for some formats) cuts size with minimal visible degradation.
Enable Brotli compression on the server or CDN.
Use a modern HTTP version. HTTP/2 is widely supported; HTTP/3 (QUIC) adds further improvements on lossy networks.

For LCP images specifically, the workflow is: identify the LCP element using PageSpeed Insights or Lighthouse, check its size and format, optimize the source, serve via CDN with proper compression.

Element render delay: the layout problem:

Element render delay is the time between the LCP resource being fully downloaded and the element actually being rendered on screen. The delay usually comes from:

JavaScript blocking rendering. A large JS bundle parsing and executing prevents the browser from rendering until JS completes.
CSS that hasn’t loaded yet. The browser may have the image but can’t render it until the CSS arrives.
Web fonts blocking text rendering. When the LCP element is text, font loading delays can hold rendering until the font arrives.
Layout thrashing. Multiple style recalculations during page load that push the LCP render later.

The optimizations:

Reduce JS bundle size. Tree-shaking, code splitting, dynamic imports for non-critical code.
Defer non-critical JS. <script defer> and <script async> keep JS out of the critical rendering path.
Inline critical CSS. The above-fold styles get inlined; the rest loads asynchronously.
Use font-display: swap or optional. Text renders immediately with fallback fonts, then swaps when the web font loads.
Reduce layout thrashing. Minimize style changes during page load, batch DOM updates.

For text LCP elements (often the case on content-heavy sites), the font loading strategy alone can make hundreds of milliseconds of difference (the gap between font-display: swap and font-display: block with slow webfonts, per web.dev font performance documentation).

Mobile vs desktop LCP:

Mobile LCP is consistently slower than desktop LCP on the same site. The reasons:

CPU throttling on mobile devices. JS execution takes 2-5x longer on a mid-range Android than on a desktop.
Slower network conditions. Cellular connections are slower and higher-latency than typical desktop wired or wifi.
Variable network quality. A mobile user might be on fast 5G or slow LTE depending on location.

Google’s evaluation uses the 75th percentile of real-user data, which on mobile typically reflects users on slower devices and weaker connections. A site that’s 1.8 seconds LCP on a tester’s iPhone might be 4 seconds at the 75th percentile of actual mobile users.

The implication: mobile-first LCP optimization is the right priority for most sites. Desktop LCP usually takes care of itself if mobile LCP is solid.

Diagnostic workflow:

The workflow that consistently produces fixable findings runs in five stages.

Start with field data from Search Console’s Core Web Vitals report. The report shows aggregate LCP performance for URLs grouped by similarity. Pages categorized as “Poor” or “Needs improvement” are the diagnostic starting points.

Move next to PageSpeed Insights for specific representative URLs. PSI runs both lab tests (Lighthouse) and reports field data from the Chrome User Experience Report. The field data shows real user performance; the lab data shows what the page is capable of under ideal conditions.

Identify the LCP element. PSI and Lighthouse highlight which element is the LCP candidate on the tested page. The element type (image, text, video) determines which optimizations apply.

Break LCP into components. The diagnostic question “is this a TTFB problem, a resource load problem, or a rendering problem” determines where the optimization effort goes.

Test optimizations and measure impact. Changes deployed to production show up in field data over weeks; lab tests show immediate before/after but don’t reflect real user variability.

Common mistakes in LCP optimization:

Patterns that recur:

Optimizing the wrong element. Working on a hero image that turns out not to be the LCP element. The diagnostic shows what to optimize; assumption shows what to waste time on.
Optimizing lab scores without monitoring field data. Lighthouse scores improve while real users still experience slow loads. The change matters only if field data improves.
Adding image preload tags broadly. Preloading too many resources defeats the purpose; the browser can’t prioritize when everything is high priority.
Aggressive lazy-loading that includes the LCP image. Lazy-loading is a Core Web Vitals positive for below-fold content, negative for above-fold LCP elements.
Ignoring TTFB because it’s “infrastructure.” TTFB is often the largest LCP component, and reducing it often produces the biggest single improvement.

Third-party scripts as the hidden LCP cost:

The LCP optimizations above assume a site that controls what loads. Most production sites don’t. Tag managers, analytics platforms, advertising scripts, consent management platforms, customer support widgets, A/B testing tools, and heatmap recorders all inject JavaScript that competes with the LCP candidate for bandwidth and main thread time.

The mechanism: third-party scripts download, parse, and execute on the main thread. While they run, the browser can’t process other work, including the work needed to render the LCP element. A 200KB tag manager that loads synchronously can delay LCP by hundreds of milliseconds even when the LCP image is small and well-optimized.

The patterns that cause the most damage:

Google Tag Manager loaded in the head without async or defer. GTM itself is small, but the tags it loads (analytics, conversion pixels, retargeting scripts) compound quickly. Each tag GTM injects becomes part of the LCP critical path.
Consent management platforms that block until user interaction. Many CMPs (OneTrust, Cookiebot, Didomi, Usercentrics) defer non-essential scripts until consent, but the CMP itself loads eagerly. A 100KB CMP script in the head adds parse and execute time before LCP can complete.
Ad-tech header bidding wrappers. Prebid, Amazon TAM, and similar header bidding setups make multiple network calls before the first ad renders. The wrapper script runs on the main thread and competes with LCP work.
Customer support chat widgets loaded immediately. Intercom, Drift, Zendesk Chat, and similar widgets ship 100-300KB of JavaScript that often loads before the page is interactive.
Synchronous A/B testing scripts. Optimizely, VWO, and Adobe Target sometimes load synchronously to avoid flicker; the cost is LCP delay.

The diagnostic: open the Chrome DevTools Performance panel, filter by main thread activity during the LCP window, and identify which scripts are running. The biggest blockers are usually clear in the flame graph.

The fixes:

Audit which third-party scripts are essential to first paint. Most aren’t. Analytics, retargeting, and chat widgets can wait until after LCP completes.
Load non-essential scripts with defer or after the load event. Defer waits until HTML parsing finishes; load-event handlers wait until the page is fully loaded.
Use GTM’s built-in trigger conditions. Tags can be configured to fire on Window Loaded or Page Loaded triggers instead of Page View, deferring their execution past LCP.
Move consent management to a lighter implementation. Some CMPs (Klaro, Cookie Consent) ship under 30KB; the heavy enterprise CMPs often exceed 100KB.
Self-host critical scripts where licensing allows. Self-hosting eliminates the additional DNS lookup, TCP connection, and TLS handshake for each third-party origin.

The harder organizational reality: third-party scripts often belong to marketing, security, or compliance teams rather than engineering. LCP optimization in this category requires cross-functional agreement about which scripts are worth the performance cost.

LCP drifts. Plan for it:

LCP optimization isn’t a one-time project. The metric reflects ongoing decisions about content, infrastructure, and code. A site that’s tuned to good LCP can drift back to poor LCP through a single image upload (uncompressed hero), a font swap (slow-loading webfont becomes the LCP element), or a CMS change (template that defers critical CSS).

The operational habit that holds: LCP monitoring built into the deployment pipeline, regression alerts when scores degrade, and explicit LCP budgets that production code can’t exceed without review. The sites that maintain good LCP treat it the same way they treat error rates: a continuous-monitoring metric with owners and accountability.

The sites that don’t maintain it find themselves rediscovering the problems quarterly, with the rediscovery cost showing up in ranking each time.

A useful mental anchor: LCP is the cost of waiting. Every millisecond above 2.5 seconds is a millisecond the visitor waited for the page to deliver its main content. The optimization work isn’t abstract performance theater; it’s the user actually getting what they came for, sooner.

Related posts: