Largest Contentful Paint (LCP)

TL;DR — Largest Contentful Paint (LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good.) measures how long it takes for the biggest thing on screen — usually a hero image or a big block of text — to show up after someone clicks to your page. Under 2.5 seconds is good. It’s one of Google’s three Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data., and it’s the one most sites struggle with.

What LCP is

The first impression people have of your site is how fast it appears to load. LCP tries to put a number on that. It measures the amount of time it takes to load the single largest visible element in the viewport — the part of the page you can see without scrolling.

That “largest element” is usually one of two things:

• A big image — a hero banner, a product photo, a featured image.
• A big block of text — common on article pages that don’t lead with an image.

LCP is the moment that element finishes renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM., measured from when the page first started loading. The lower the number, the faster your page feels.

The score

Google sorts LCP into three buckets:

• Good: 2.5 seconds or less
• Needs improvement: 2.5 to 4 seconds
• Poor: more than 4 seconds

You’re aiming for that 2.5-second mark. And it’s judged on real visitors to your site, not a test you run once — so it’s the experience your actual audience gets on their actual phones and connections.

Why it can be hard

LCP is the Core Web Vital people struggle with the most. That’s because it has the most moving parts: your server has to respond, the browser has to find and download the image, and then it has to actually paint it. A slowdown at any of those steps drags the whole number up. Compressing your images is a common first guess — and it sometimes helps — but it’s often not the real bottleneck.

It’s also harder on mobile than desktop, because phones have slower connections and less processing power.

What to do first

Three quick wins that fix the most common mistakes:

1. Don’t lazy-load your main image. “Lazy loadingLazy loading defers loading of off-screen or non-critical resources — usually images and iframes — until they're about to enter the viewport. The native way to do it is the loading=\"lazy\" HTML attribute, which needs no JavaScript.” tells the browser to wait before fetching an image. That’s great for stuff far down the page — but if you do it to your hero image, you’re deliberately delaying the most important thing on screen. Evidence for this claim An LCP image should not be lazy-loaded, and reducing resource load delay is a primary LCP optimization. Scope: web.dev guidance for image-based LCP elements. Confidence: high · Verified: 2026-07-14 web.dev: Optimize LCP
2. Tell the browser the main image is important — there’s an attribute (fetchpriority="high") that does exactly that. Put it on the one image that’s actually your LCP candidate; slapping it on several images dilutes the signal.
3. Speed up your server. If your server is slow to respond, nothing else you do matters much.

Want the full mental model — the four sub-parts of LCP, how to find your LCP element, the renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. and font stuff, and how much this actually matters for rankings? Switch to the Advanced tab.

TL;DR — LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. is the render time of the largest image or text block visible in the viewport, relative to when the page started loading. Good is ≤ 2.5 s at the 75th percentile of real users (split by device); 2.5–4 s needs work, over 4 s is poor. It’s one of three Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. and breaks into four sub-parts — TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good., resource load delay, resource load duration, element render delay — where TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. and load duration usually dominate (guidelines, not fixed shares — diagnose your own page). Top fixes: never lazy-load the LCP image, add fetchpriority="high" on the actual candidate, preloadResource hints are <link> elements (or equivalent HTTP Link headers) that tell the browser to do network work — DNS lookups, connection setup, or fetching a resource — earlier than it would discover the need on its own. The main ones are dns-prefetch, preconnect, preload, modulepreload, and prefetch. it when it isn’t in the HTML, kill render-blocking CSSRender-blocking resources are CSS and synchronous JavaScript files a browser must download and process before it can paint any visible content. They sit on the critical rendering path and delay First Contentful Paint and Largest Contentful Paint./JS, and fix TTFB. It’s a field metric — lab tools only approximate it — and the LCP element can change during load. Google confirms Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. feed ranking systems but doesn’t publish an exact LCP weight or call it a tiebreaker; content relevance still dominates.

What LCP actually measures

LCP reports the render time of the largest image or text block visible in the viewport, measured relative to when the user first navigated to the page. Google’s own framing: it’s the closest standardized proxy for when the main content appears to the user. It replaced earlier, fuzzier metrics like First Meaningful Paint and Speed IndexSpeed Index measures how quickly content is visually displayed during page load — the average time at which visible parts of the page appear, scored in seconds (lower is better). It's a lab-only Lighthouse metric, not a Core Web Vital and not a ranking factor..

A few things that trip people up right away:

• It’s not “page load time.” A page can have every resource fetched and still post a slow LCP if renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. the largest element was blocked. LCP is about that one element, not the whole page.
• It’s not the same as FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital.. First Contentful Paint fires when any content first appears; LCP waits for the largest element. A page can have a fast FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. (the navbar paints) and a slow LCP (the hero image loads late).
• It’s a dynamic metric. The browser dispatches a new LCP candidate every time a larger element becomes visible. The last entry before the user interacts (tap, scroll, keypress) or the page unloads is the value that counts — interaction often changes what’s visible, so reporting stops there. A candidate that’s later removed from the DOM doesn’t erase its own entry — it stays the reported element unless a still-larger one renders before reporting stops.

The thresholds — and why 2.5 seconds

Assessed at the 75th percentile of real-user page loads, segmented by device type. So three out of four visits need to come in under 2.5 s for an origin to pass.

Why 2.5 specifically? Google’s threshold methodology leaned on two things: human perception research pointing at roughly 1–3 seconds as the band that feels “immediate,” and CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. achievability data showing 2.5 s was consistently achievable for well-optimized sites without being trivially easy. Tighter targets like 1.5 s or 2.0 s weren’t consistently achievable across enough origins, so they didn’t make the cut.

What counts as the LCP element

The element types considered for LCP:

• <img> elements
• <image> elements inside an <svg>
• <video> elements (the poster image load time, or the first frame, whichever is earlier)
• An element with a background image loaded via the CSS url() function
• Block-level elements containing text nodes or other inline text children

The reported size is what’s actually visible in the viewport — portions clipped or scrolled off don’t count, and for images it’s the visible size or the intrinsic size, whichever is smaller. Margins, padding, and borders are ignored. A handful of elements get excluded by heuristics: anything with opacity: 0, elements that cover the whole viewport (treated as backgrounds), and low-entropy placeholder images.

About three-quarters of pages have an image as their LCP element — so image work is usually the right first move. But not always, and not always compressionCompression (HTTP content encoding) shrinks text-based responses — HTML, CSS, JS, JSON, SVG, XML sitemaps — before they're sent over the network, using an algorithm like Gzip, Brotli, or Zstd, so the browser or crawler downloads fewer bytes. It's not a ranking factor, but it speeds up page loads and helps pages stay under crawler fetch limits. (more on that next). The remaining chunk are text LCPs, where the lever is entirely different: it’s font loadingFont loading is how a browser fetches, applies, and renders custom web fonts — and specifically what it shows while the font file downloads. Those choices, controlled mainly by the CSS font-display property, directly affect two Core Web Vitals: LCP and CLS., not image weight.

The four sub-parts — the part most articles skip

This is the framework I’d start any LCP diagnosis with. web.dev breaks LCP into four sequential sub-parts:

1. Time to First Byte (TTFB) — from when the user starts loading the page to when the browser receives the first byte of HTML. Typical share: ~40% of total LCP.
2. Resource load delay — the gap between TTFB and the browser starting to load the LCP resource. This is discovery time. Typical share: under 10%.
3. Resource load duration — how long the LCP resource itself takes to download. Typical share: ~40%.
4. Element render delay — from when the resource finishes loading to when the element actually paints. Typical share: under 10%.

The principle behind the table: the vast majority of LCP time should be spent loading the HTML document and the LCP resource. Any stretch where neither is loading is an opportunity to improve.

web.dev is explicit that these percentages are guidelines, not strict rules — don’t convert them into absolute-second targets, and don’t force every page to match the split. They’re only meaningful relative to each other, and if your LCP is consistently within 2.5 seconds already, the relative proportions don’t matter at all. Use the table to spot which sub-part is eating an outsized share on your page, then fix that one — not to chase an exact 40/10/40/10 split.

And here’s the bit that upends the common assumption: as of February 2025 these four sub-parts are available in the CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. API for image LCPs, and the Chrome team’s analysis of HTTP Archive data found that image download time was often the smallest part of LCP time. In other words, “just compress my images” frequently fixes the wrong sub-part. TTFB and discovery delay are often the bigger levers.

How to find your LCP element

Before you optimize anything, find out which element is your LCP and which sub-part is the bottleneck:

• PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. — the Diagnostics section flags the LCP element, and the field-data tab shows your real-user score.
• Chrome DevTools — the Performance panel marks the LCP node on the timeline.
• The web-vitals JS library — log LCP (and the element) from your own real-user monitoring.

How to improve LCP

Map each fix to the sub-part it targets:

Fix resource load delay (discovery). This is the highest-leverage and most commonly broken one.

• Never lazy-load your LCP image. loading="lazy" on the LCP element always adds unnecessary load delay. Reserve lazy loadingLazy loading defers loading of off-screen or non-critical resources — usually images and iframes — until they're about to enter the viewport. The native way to do it is the loading=\"lazy\" HTML attribute, which needs no JavaScript. for below-the-fold images.
• Add fetchpriority="high" to the likely LCP image so the browser fetches it early at high priority.
• Preload it with <link rel="preload"> when the image isn’t discoverable in the initial HTML — for example, when it’s loaded via CSS or JavaScript. Loading the hero image via JS is an anti-pattern precisely because it hides the URL from the browser’s preload scanner.
• Host critical resources on the same origin so the browser doesn’t pay extra connection setup.

Preload and fetchpriority solve different problems, so don’t reach for both by habit. Preload exposes a resource the browser’s preload scanner would otherwise discover late (a JS- or CSS-loaded image, for example); fetchpriority changes the fetch priority of a resource the browser already found. If discovery and priority are already correct — the image is a plain <img> in the initial HTML — adding either can do little beyond extra requests. Check a trace, apply the one that matches the actual problem, and confirm the field number moved.

TIP

To identify the current LCP candidate and separate field status from lab debugging, run the Core Web Vitals Checker Free

1. Run the public page and confirm which element the fresh lab trace reports as LCP.
2. Check whether discovery delay, load duration, render delay, or TTFB is actually the largest sub-part.
3. Apply the matching fix, rerun the lab trace immediately, then use field data to confirm the real-user outcome.

Tap to enlarge

The focused Core Web Vitals Checker finding says Improve the largest contentful paint and recommends optimizing and preloading the hero image, then verifying the LCP element in a fresh lab trace.

Fix element render delay.

• Reduce or inline render-blocking CSS; defer non-critical styles.
• Avoid synchronous scripts in the <head>.
• Prefer server-side renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. or static generation so the markup arrives ready to paint, and break up long main-thread tasks.

Reduce resource load duration.

• Modern image formatsThe file encoding used to store an image (JPEG, PNG, WebP, AVIF, SVG, GIF) — it drives file size and Core Web Vitals, but carries no direct ranking weight. (WebP, AVIF), sensible compression, and a CDN.
• Efficient Cache-Control. And don’t ignore network contention — lazy-loading the other below-fold images can free up bandwidth so the LCP image lands sooner.

Reduce TTFB.

• Minimize redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't., drop unnecessary unique URL parametersThe `?key=value` data tacked onto the end of a URL after a question mark — used for tracking, sessions, filtering, sorting, and search — and one of the biggest sources of duplicate URLs and wasted crawling in SEO., and optimize server response time. Note that LCP includes any unload time from the previous page, connection setup, and redirect time — all of which roll into TTFB.

Special case: text-based LCP. When the largest element is text, the critical path is font loading, not image weight. font-display: optional or system fonts eliminate font-induced render delay; font-display: swap without preloading the font file can introduce it.

Lab vs. field — this distinction matters

LCP is fundamentally a field metric. Google assesses it on real users via CrUX, surfaced in PageSpeed Insights’ field tab and the Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. Core Web VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors. report. That field dataPerformance metrics captured from real users, not lab tests. is what feeds rankings.

Lab tools — LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal., Chrome DevTools, WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. — only approximate it under simulated conditions, and they don’t even use the same scoring. Lighthouse applies stricter desktop thresholds (Good ≤ 1.2 s) than the field standard (≤ 2.5 s). So a passing Lighthouse score doesn’t guarantee a passing CrUX score, and vice versa. Use lab tools to debug and reproduce; trust the field data for the actual verdict.

There’s a second reason lab and field numbers can diverge, worth knowing so an odd reading doesn’t send you chasing a phantom bug: the current LargestContentfulPaint browser API (still a W3C Working Draft) is scoped to a single document load. It doesn’t itself reset on back/forward cache (bfcache) restores or same-document SPA navigations, and pages that start off-screen — background tabs, prerendered pages — can report inflated values because timing runs from load rather than from when the page actually became visible. The reporting algorithm also halts on qualifying user input, so if a user interacts before your main content displays, LCP won’t capture it. None of this changes the threshold table above; it explains why a specific session’s number can look wrong when the underlying navigation isn’t a plain first load.

Does LCP affect rankings?

Yes, in the sense that Google confirms Core Web Vitals feed its ranking systems and recommends achieving good scores. But current Search Central documentation doesn’t publish an exact LCP weight and doesn’t describe it as a tiebreaker — Google’s own framing is that page experience “can contribute to success in Search” for queries where multiple pages already offer comparable, relevant content, and that a good score doesn’t guarantee a ranking boost. Content relevance and quality still dominate. Optimize LCP because a faster-feeling page is genuinely better for users (and conversions) — not because the mechanism is documented as a rankings tiebreaker, because it isn’t.

A couple of realities from the data: of the Core Web Vitals, LCP is the one sites struggle most to improve, and it’s noticeably harder on mobile than desktop — slower CPUs and connections. On 3G and slower, the 2.5 s threshold can feel almost impossible to hit.

Where this fits

LCP is one of three Core Web Vitals, alongside Interaction to Next Paint and Cumulative Layout Shift. Its first sub-part, Time to First Byte, is its own diagnostic metric, and First Contentful Paint sits right next to it on the loading timeline. You’ll see all of these in PageSpeed Insights, Lighthouse, and the Chrome User Experience Report (CrUX). Each is its own deep dive in this cluster.

AI summary

A condensed take on the Advanced version:

• LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. = render time of the largest visible image or text block, relative to when the page started loading. It’s the closest standardized proxy for “when does the main content appear.”
• Thresholds: Good ≤ 2.5 s, Needs improvement 2.5–4 s, Poor > 4 s — at the 75th percentile of real users, split by device. It’s one of three Core Web Vitals.
• Not page-load time, not FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital.. FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. = first pixel of any content; LCP = the largest element. LCP is also dynamic — the largest candidate can change during load; the last one before user interaction counts.
• LCP elements: <img>, <image> in <svg>, <video> poster, CSS background-image: url(), or a block-level text element. ~3 in 4 pages have an image LCP; the rest are text (where fonts, not image weight, are the lever).
• Four sub-parts: TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. (~40%), resource load delay (<10%), resource load duration (~40%), element render delay (<10%) — web.dev calls these guidelines, not fixed shares; diagnose per page rather than chasing an exact split. CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. 2025 data: image download is often the smallest part — so “just compress images” often fixes the wrong thing.
• Top fixes: never lazy-load the LCP image; add fetchpriority="high" on the actual candidate; preloadResource hints are <link> elements (or equivalent HTTP Link headers) that tell the browser to do network work — DNS lookups, connection setup, or fetching a resource — earlier than it would discover the need on its own. The main ones are dns-prefetch, preconnect, preload, modulepreload, and prefetch. it when it’s not in the HTML (preload and fetchpriority solve different problems — don’t reach for both by habit); cut render-blocking CSSRender-blocking resources are CSS and synchronous JavaScript files a browser must download and process before it can paint any visible content. They sit on the critical rendering path and delay First Contentful Paint and Largest Contentful Paint./JS; reduce TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good..
• Field, not lab. CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program./Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. drive rankings; LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. only approximates and uses stricter desktop thresholds (≤ 1.2 s). The current LargestContentfulPaint API is scoped to document loads and doesn’t itself reset for bfcacheThe back/forward cache (bfcache) is a browser feature that freezes a whole page in memory when you navigate away, so pressing Back or Forward can restore it instantly — no reload, no re-render, no network requests — as long as the browser hasn't evicted that frozen page first. It's a browser optimization, not a search ranking factor. restores or same-document SPA navigations.
• Rankings: Google confirms CWV feed ranking systems but publishes no exact LCP weight and doesn’t call it a tiebreaker; content relevance still dominates. Hardest CWV to improve, and harder on mobile.

Official documentation

Primary-source guidance from Google’s Chrome and Search teams.

web.dev (Chrome team)

• Largest Contentful Paint (LCP) — the canonical definition: what counts as an LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. element, how size is calculated, when reporting stops, and the measurement APIs.
• Optimize Largest Contentful Paint — the four sub-parts framework and the full optimization playbook.
• Core Web Vitals — where LCP sits among the three Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data..
• How the Core Web Vitals metrics thresholds were defined — the research and achievability data behind the 2.5 s mark.

Chrome for Developers

• LCP image subparts and RTT now available in CrUX — the Feb 2025 field-data release of the four sub-parts (image LCPs only).
• Largest Contentful Paint | Lighthouse — the lab metric and its device-specific scoring.

Google Search Central

• Understanding Core Web Vitals and Google search results — how Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. factor into Search.

Quotes from the source

On-the-record statements from Google’s documentation and team. Each link is a deep link that jumps to the quoted passage.

web.dev — definition and behavior (Philip Walton & Barry Pollard, Google)

• “LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. reports the render time of the largest image, text block, or video visible in the viewport, measured relative to when the user first navigated to the page.” Jump to quote
• On what’s measured: “LCP doesn’t consider margins, paddings, or borders applied using CSS.” Jump to quote
• On when reporting stops: “The browser will stop reporting new entries as soon as the user interacts with the page (via a tap, scroll, or keypress), as user interaction often changes what’s visible to the user.” Jump to quote
• On what’s included in the timing: “It is important to note that LCP includes any unload time from the previous page, connection set up time, redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. time, and other Time To First ByteTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. (TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good.) delays.” Jump to quote

web.dev — optimization (Philip Walton & Barry Pollard, Google)

• The single most important lazy-loading rule: “Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay.” Jump to quote
• The principle behind the sub-part targets: “The vast majority of the LCP time should be spent loading the HTML document and LCP source.” Jump to quote

Google Search Central — rankings

• “We highly recommend site owners achieve good Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. for success with Search and to ensure a great user experience generally.” (Relayed from the Search Central Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. doc; confirm against the live page before treating as final.)

LCP fix checklist

Work it roughly top to bottom — discovery and TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. first, because they’re usually the biggest, most commonly broken levers.

• FoundA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore. the actual LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. element (PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. Diagnostics, DevTools Performance panelThe Performance panel is Chrome DevTools' built-in, local profiler for recording and analyzing how a page loads and runs — CPU, main-thread work, rendering, network, and live Core Web Vitals. The recorded trace is local, lab data from your own browser — not what Googlebot sees — though the panel can optionally show real-user CrUX field data alongside it., or the web-vitals library) — don’t optimize blind.
• Checked the four sub-parts to see which one is the bottleneck before changing anything.
• LCP image is not loading="lazy" (lazy loadingLazy loading defers loading of off-screen or non-critical resources — usually images and iframes — until they're about to enter the viewport. The native way to do it is the loading=\"lazy\" HTML attribute, which needs no JavaScript. belongs below the fold only).
• LCP image has fetchpriority="high".
• LCP image is discoverable in the initial HTML — or preloaded (<link rel="preload">) if it’s loaded via CSS/JS.
• Not loading the hero image via JavaScript (hides it from the preloadResource hints are <link> elements (or equivalent HTTP Link headers) that tell the browser to do network work — DNS lookups, connection setup, or fetching a resource — earlier than it would discover the need on its own. The main ones are dns-prefetch, preconnect, preload, modulepreload, and prefetch. scanner).
• Render-blocking CSSRender-blocking resources are CSS and synchronous JavaScript files a browser must download and process before it can paint any visible content. They sit on the critical rendering path and delay First Contentful Paint and Largest Contentful Paint. minimized/inlined; non-critical styles deferred.
• No synchronous scripts in the <head>; long tasksAny main-thread task over 50 ms — the primary cause of INP regressions. broken up.
• Modern image formatThe file encoding used to store an image (JPEG, PNG, WebP, AVIF, SVG, GIF) — it drives file size and Core Web Vitals, but carries no direct ranking weight. (WebP/AVIF), sensible compressionCompression (HTTP content encoding) shrinks text-based responses — HTML, CSS, JS, JSON, SVG, XML sitemaps — before they're sent over the network, using an algorithm like Gzip, Brotli, or Zstd, so the browser or crawler downloads fewer bytes. It's not a ranking factor, but it speeds up page loads and helps pages stay under crawler fetch limits., served via a CDN with good Cache-Control.
• Below-fold images lazy-loaded so they don’t contend for bandwidth with the LCP image.
• TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. addressed: redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. minimized, server response optimized, junk URL params dropped.
• Text LCP? Using font-display: optional or system fonts, and preloading any swapped font file.
• Verified against field dataPerformance metrics captured from real users, not lab tests. (CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. / Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance.), not just a LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. lab run.

LCP cheat sheet

Thresholds (75th percentile of real users, by device)

The four sub-parts — what each is and the fix

What can be the LCP element

• <img> · <image> inside <svg> · <video> poster · CSS background-image: url() · block-level text

Excluded by heuristic: opacity: 0, full-viewport “background” elements, low-entropy placeholders.

Fast facts

• LCP is a field metric (CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. / Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. drive rankings); LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. only approximates and uses a stricter desktop Good of ≤ 1.2 s.
• The LCP element can change during load; the last candidate before user interaction counts.
• ~3 in 4 pages have an image LCP; the rest are text (fonts are the lever).
• Image download time is often the smallest sub-part — compressionCompression (HTTP content encoding) shrinks text-based responses — HTML, CSS, JS, JSON, SVG, XML sitemaps — before they're sent over the network, using an algorithm like Gzip, Brotli, or Zstd, so the browser or crawler downloads fewer bytes. It's not a ranking factor, but it speeds up page loads and helps pages stay under crawler fetch limits. isn’t always the answer.
• LCP ≠ FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital.; LCP ≠ total page load time.

Tools for measuring and fixing LCP

Field dataPerformance metrics captured from real users, not lab tests. (what rankings use)

• PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. — field tab shows your real-user CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good.; Diagnostics flags the LCP element.
• Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. — Core Web Vitals reportThe Google Search Console report (under Experience) that shows how your indexed URLs perform on the Core Web Vitals — LCP, INP, and CLS — using real-user field data from CrUX, grouped by device, status, and clusters of similar-performing URLs. — LCP status across your URLs, grouped, on real-user data.
• Chrome User Experience Report (CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.) — the underlying field dataset; as of Feb 2025 includes the four image-LCP sub-parts via the API.
• web-vitals JS library — log LCP and the LCP element from your own real-user monitoring.

Lab data (for debugging)

• LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. — quick lab LCP and an opportunities list (remember: stricter desktop thresholds than the field).
• Chrome DevTools — Performance panelThe Performance panel is Chrome DevTools' built-in, local profiler for recording and analyzing how a page loads and runs — CPU, main-thread work, rendering, network, and live Core Web Vitals. The recorded trace is local, lab data from your own browser — not what Googlebot sees — though the panel can optionally show real-user CrUX field data alongside it. — marks the LCP node and the full render timeline.
• WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. — waterfall view for pinning down which sub-part is slow.

SEO crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index.

• Ahrefs Site Audit — surfaces Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. / performance issues across the site at scale.

How the tools themselves score

A live example of the metric this page describes — well-known page-speed and monitoring services ranked on their own real-user mobile LCP (Chrome UX Report field data):

LCP fixes that target the wrong problem

Lazy-loading the hero image

loading="lazy" delays discovery of an above-the-fold image that is likely to become LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good.. Load it eagerly, give the likely candidate fetchpriority="high", and reserve lazy loadingLazy loading defers loading of off-screen or non-critical resources — usually images and iframes — until they're about to enter the viewport. The native way to do it is the loading=\"lazy\" HTML attribute, which needs no JavaScript. for below-the-fold images.

Compressing every image before finding the bottleneck

Image download duration is only one of four LCP sub-parts and may be the smallest. Identify the LCP element and inspect TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good., load delay, load duration, and render delay before choosing a fix.

Loading the hero through JavaScript

A JS-injected image hides its URL from the browser’s preloadResource hints are <link> elements (or equivalent HTTP Link headers) that tell the browser to do network work — DNS lookups, connection setup, or fetching a resource — earlier than it would discover the need on its own. The main ones are dns-prefetch, preconnect, preload, modulepreload, and prefetch. scanner and creates resource load delay. Put the image in the initial HTML or preload it when CSS or JS must own it.

Declaring victory from one Lighthouse run

LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. is a controlled diagnostic, while Google’s CWVGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. verdict comes from CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. field dataPerformance metrics captured from real users, not lab tests.. Use lab runs to verify the mechanism and wait for real-user data to show whether the p75 outcome improved.

The LCP resource starts late

Symptom: a long gap appears between TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. and the LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. resource request. Likely cause: lazy loadingLazy loading defers loading of off-screen or non-critical resources — usually images and iframes — until they're about to enter the viewport. The native way to do it is the loading=\"lazy\" HTML attribute, which needs no JavaScript., JS discovery, a CSS background image, or low fetch priority. Fix: make the resource discoverable in initial HTML, remove lazy loadingLazy loading defers loading of off-screen or non-critical resources — usually images and iframes — until they're about to enter the viewport. The native way to do it is the loading=\"lazy\" HTML attribute, which needs no JavaScript., apply fetchpriority="high", or preloadResource hints are <link> elements (or equivalent HTTP Link headers) that tell the browser to do network work — DNS lookups, connection setup, or fetching a resource — earlier than it would discover the need on its own. The main ones are dns-prefetch, preconnect, preload, modulepreload, and prefetch. it. Confirm the request moves earlier in a trace.

The resource loads but LCP still fires late

Symptom: load duration ends well before the LCP event. Likely cause: render-blocking CSSRender-blocking resources are CSS and synchronous JavaScript files a browser must download and process before it can paint any visible content. They sit on the critical rendering path and delay First Contentful Paint and Largest Contentful Paint., synchronous JavaScript, a long taskAny main-thread task over 50 ms — the primary cause of INP regressions., or font renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. for a text LCP. Fix: reduce blocking work and test font strategy for text; confirm element render delay shrinks.

Lab LCP is good but field LCP is poor

Symptom: LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. passes while CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. or Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. does not. Likely cause: real users have different devices, networks, cache states, geography, or LCP elements. Fix: segment field dataPerformance metrics captured from real users, not lab tests., capture RUM element/sub-part details, and reproduce the slow segment rather than tuning only the default lab profile.

The reported LCP element changes between runs

Symptom: DevTools identifies different images or text blocks. Likely cause: responsive breakpoints, personalization, late DOM changes, or competing candidates. Fix: test representative viewports and states, then optimize each recurring candidate instead of assuming one desktop hero covers every user.

Hero image discovery: delayed vs early

A simplified delayed implementation hides the image behind JavaScript:

<div id="hero"></div>
<script>
  document.querySelector('#hero').innerHTML = '<img src="hero.webp" alt="">';
</script>

The browser can discover and prioritize this version while parsing HTML:

<img src="hero.webp" alt="" fetchpriority="high" width="1200" height="675">

CSS background image: undisclosed vs preloaded

When the LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. image must remain a CSS background, disclose it before the stylesheet finishes:

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

The preloadResource hints are <link> elements (or equivalent HTTP Link headers) that tell the browser to do network work — DNS lookups, connection setup, or fetching a resource — earlier than it would discover the need on its own. The main ones are dns-prefetch, preconnect, preload, modulepreload, and prefetch. only helps when its URL and request attributes match the actual resource.

List recent LCP candidates in Chrome DevTools

Paste this into the Chrome DevTools Console, reload the page, and watch each candidate the browser reports. The last candidate before interaction is the relevant one.

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.table({
      lcp: Math.round(entry.startTime),
      element: entry.element?.tagName,
      url: entry.url || '',
      size: entry.size,
    });
  }
}).observe({ type: 'largest-contentful-paint', buffered: true });

Find likely lazy-loaded above-the-fold images

Run this in the DevTools Console. It lists lazy images whose top edge begins in the current viewport; verify the real LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. candidate before removing the attribute.

[...document.querySelectorAll('img[loading="lazy"]')]
  .filter((img) => img.getBoundingClientRect().top < innerHeight)
  .map((img) => ({ src: img.currentSrc || img.src, top: img.getBoundingClientRect().top }));

Extract image priority attributes in a crawler

Use this XPath in Screaming Frog custom extraction to return images marked as high priority:

//img[@fetchpriority='high']/@src

Prove an LCP fix landed

Discovery-order test

Test to run: record a DevTools Performance trace after changing the hero image. Expected result: the LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. request starts earlier and is not lazy-loaded. Failure interpretation: the resource remains hidden, deprioritized, or blocked behind another dependency. Monitoring window: immediate lab result. Rollback trigger: the change delays another critical resource or makes lab LCP consistently worse.

Render-delay test

Test to run: compare the LCP resource completion and LCP event in equivalent before/after traces. Expected result: element render delay shrinks without a new layout or visual regression. Failure interpretation: CSS, JavaScript, or fonts still block paint. Monitoring window: immediate across representative viewports. Rollback trigger: broken renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM., missing styles, or a worse recurring LCP.

Field-outcome test

Test to run: monitor URL-level CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. or first-party RUM p75 LCP after deployment. Expected result: p75 moves toward or remains within the Good threshold without regressing INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. or CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.. Failure interpretation: the lab case was not representative or another sub-part dominates real visits. Monitoring window: RUM can lead; CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. needs its rolling 28-day window to turn over. Rollback trigger: a sustained field regression tied to the release.

LCP metrics worth tracking

Field p75 LCP

Metric: LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. at the 75th percentile by form factor. What it tells you: whether real users meet the Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. loading threshold. How to pull it: CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program., Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results., or first-party RUM. Benchmark / realistic range: Good is at or below 2.5 seconds; segment mobile and desktop. Cadence: weekly, with the CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. rolling window recorded.

LCP sub-part distribution

Metric: TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good., resource load delay, load duration, and element render delay for LCP. What it tells you: which stage owns the wait. How to pull it: representative lab traces and image-LCP subparts from CrUX/RUM where available. Benchmark / realistic range: use the article’s approximate 40/10/40/10 diagnostic split as a guide, not a universal performance promise. Cadence: after template releases and monthly for priority templates.

Good-LCP URL coverage

Metric: important URL groups with Good field LCP. What it tells you: whether improvement is broad or limited to a sample page. How to pull it: Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. CWV groups plus URL-level CrUX for priority pages. Benchmark / realistic range: establish a baseline by template; low-traffic URLs may lack individual field dataPerformance metrics captured from real users, not lab tests.. Cadence: weekly.

Test yourself: Largest Contentful Paint

Five quick questions on LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. measurement and diagnosis. Pick an answer for each, then check.

Resources worth your time

My related writing

• What Is Largest Contentful Paint (LCP) & How To Improve It — my full LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. guide on the Ahrefs blog.
• What Are Core Web Vitals (CWVs) & How To Improve Them — how LCP fits with INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good., and why it’s the hardest to fix.
• The Beginner’s Guide to Technical SEO — where page performance sits in the bigger picture.

Official (Google / Chrome)

• Largest Contentful Paint (LCP) and Optimize LCP — the canonical pair.
• How CWV thresholds were defined — the why behind 2.5 s.

From others

• Fix your website’s Largest Contentful Paint by optimizing image loading — MDN’s developer-first take, strong on bandwidth contention and the JS-image anti-pattern.
• Performance — 2025 Web Almanac — HTTP Archive’s annual deep-dive; source for adoption stats on fetchpriorityHTML attribute that hints fetch priority; high on the LCP image is one of the quickest LCP wins., preloadResource hints are <link> elements (or equivalent HTTP Link headers) that tell the browser to do network work — DNS lookups, connection setup, or fetching a resource — earlier than it would discover the need on its own. The main ones are dns-prefetch, preconnect, preload, modulepreload, and prefetch. usage, image vs text LCP splits, and pass rates by device.
• Largest Contentful Paint (LCP) — DebugBear’s docs cover waterfall analysis for pinpointing sub-parts, progressive JPEG caveats, and iframeHTML element that displays one webpage inside another — how embeds work./soft-navigation edge cases.
• Largest Contentful Paint (LCP): What It Is, How to Measure & Optimize — corewebvitals.io; real RUM benchmarks, business impact case studies (Vodafone Italy), and the Google Flights fetchpriority result.
• Largest Contentful Paint | MDN Web Docs — MDN reference for the LargestContentfulPaint API, element types, and browser compatibility.

Stats worth citing

• LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. is the hardest Core Web Vital to pass. It has the most components, which is why sites struggle with it more than INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. or CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.. Source
• Mobile is harder than desktop. Slower CPUs and connections push LCP up, and on 3G/slow connections the 2.5 s threshold is nearly impossible to hit. Source
• Image download time is often the smallest part of LCP. Chrome’s analysis of HTTP Archive data foundA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore. download duration frequently isn’t the bottleneck — TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. and discovery delay usually are. Source
• CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. coverage is thin. In our study of 42 million pages, only ~11.4% had associated CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. field dataPerformance metrics captured from real users, not lab tests. — most pages don’t get enough real-user traffic to be measured. Source
• 62% of mobile pages vs 74% of desktop pages achieve Good LCP (2025 Web Almanac). The mobile gap reflects slower CPUs and network connections. Source
• Only 2.1% of mobile pages preloadResource hints are <link> elements (or equivalent HTTP Link headers) that tell the browser to do network work — DNS lookups, connection setup, or fetching a resource — earlier than it would discover the need on its own. The main ones are dns-prefetch, preconnect, preload, modulepreload, and prefetch. their LCP image, despite 76% having an image as their LCP element — a significant missed optimization opportunity (2025 Web Almanac). Source
• fetchpriority="high" adoption grew from 0.03% of mobile sites in 2022 to 17.3% in 2025, largely driven by WordPress core adding it (2025 Web Almanac). Google Flights saw a 700 ms LCP improvement from this single attribute. Source

Videos

• Google Search Central (YouTube) — the Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. and page-experience explainers, including Chrome team walkthroughs of LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. optimization. Channel

LCP

Largest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good.

Related: Core Web Vitals, TTFB, FCP

LCP

Largest Contentful PaintLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. (LCP) measures the render time of the largest image or text block visible in the viewport, relative to when the page first started loading. It’s the closest standardized approximation of when a page appears loaded to the user, and it’s one of Google’s three Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. (alongside Interaction to Next PaintInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. and Cumulative Layout ShiftCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.).

The scoring bands, measured at the 75th percentile of real-user page loads and split by device: Good ≤ 2.5 s, Needs Improvement 2.5–4.0 s, Poor > 4.0 s. The LCP element is usually an <img>, an image inside an <svg>, a <video> poster, a CSS background-image, or a block-level text element — and it can change during load, since the browser keeps reporting a new candidate each time a larger element paints, up until the first user interaction.

LCP is a field metric — Google assesses it on real users via the Chrome User Experience ReportChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. (CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.), surfaced in PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. and Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.. Lab tools like LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. only approximate it. web.dev breaks LCP into four sub-parts — Time to First Byte, resource load delay, resource load duration, and element render delay — with TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. and load duration usually dominating. The biggest fixes: don’t lazy-load the LCP image, give it fetchpriority="high", preload it when it isn’t in the initial HTML, cut render-blocking CSS/JS, and improve TTFB.

Related: Core Web Vitals, TTFB, FCP

Changelog