Largest Contentful Paint (LCP) diagnosis
Largest Contentful Paint (LCP) measures when the largest content element in the viewport finishes rendering — a proxy for how quickly the main content becomes visible. It is one of the three Core Web Vitals. A good LCP is 2.5 seconds or less; the most common culprits are slow server response, render-blocking resources, slow resource load, and client-side rendering delays. This page breaks down the metric and its diagnosis.
What LCP measures
LCP reports the render time of the largest image, text block, or video element visible in the viewport during page load. It approximates when the user perceives that the main content has loaded.
Thresholds: a good LCP is 2.5 seconds or less at the 75th percentile of page loads; 2.5 to 4 seconds needs improvement; over 4 seconds is poor. The 75th-percentile rule means most users, not just the median, should have a fast experience.
- Measures render time of the largest viewport element
- Good: ≤ 2.5s; Needs improvement: 2.5–4s; Poor: > 4s
- Assessed at the 75th percentile of real loads
- One of the three Core Web Vitals
Common causes of slow LCP
LCP breaks down into four sub-parts: time to first byte (slow server or no caching/CDN), resource load delay (the LCP resource discovered late), resource load time (large unoptimized images), and element render delay (render-blocking CSS/JS or client-side rendering).
To diagnose, look at which sub-part dominates. A slow TTFB points at the server or CDN; a late-discovered LCP image points at preload/priority; a heavy image points at compression and format; a long render delay points at render-blocking resources or CSR. Field data confirms whether real users hit the problem.
Fixing LCP
Address the dominant sub-part: improve server response and caching for TTFB, preload and set high fetch priority on the LCP image, serve appropriately sized modern image formats, and remove or defer render-blocking resources.
For client-side rendered pages, server-render or pre-render the above-the-fold content so the LCP element is present in the initial HTML. Re-measure with field data after changes, since lab improvements do not always translate to the real-user metric Google uses.
How it appears in analytics and logs
A poor LCP means the largest visible element renders slowly for users. It is a page experience ranking input, not a crawl gate — Googlebot still crawls and indexes slow pages. LCP problems are a ranking-refinement and UX concern, not the reason a URL is absent from the index.
Diagnostic use case
Identify why a page feels slow to display its main content, attribute LCP to server, resource, or rendering causes, and confirm whether real users (field data) are affected.
What WebmasterID can help detect
WebmasterID's contribution is upstream: it records crawler fetches and server response timing, which relates to the time-to-first-byte component of LCP. It helps confirm a page is reachable and responds promptly to crawlers before you optimize the rendering chain.
Common mistakes
- Treating slow LCP as a reason a page is not indexed — it is a ranking input, not a crawl gate.
- Optimizing the lab LCP while the field (CrUX) LCP stays poor.
- Ignoring a slow time-to-first-byte and only optimizing images.
- Lazy-loading the above-the-fold LCP image, which delays its discovery.
Privacy and accuracy notes
Field LCP is aggregated from anonymized real Chrome users via CrUX, not individuals. WebmasterID does not capture per-user performance traces or fingerprint visitors; it observes crawler fetches only.
Frequently asked questions
- What is a good LCP score?
- 2.5 seconds or less at the 75th percentile of page loads is considered good. Between 2.5 and 4 seconds needs improvement, and over 4 seconds is poor.
- Does slow LCP stop my page from being indexed?
- No. LCP is a Core Web Vital that feeds the page experience ranking signal. Googlebot still crawls and indexes slow pages; fix indexing issues separately from performance.
Related pages
- Core Web Vitals and crawling
Core Web Vitals are Google's three user-centric performance metrics — Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint. They are a page experience signal used in ranking, but they do not gate crawling or indexing: a slow page can still be crawled and indexed. This page explains how vitals are measured in the field versus the lab and where they fit in the crawl-to-rank pipeline.
- Render-blocking resources and crawling
Render-blocking resources are scripts and stylesheets the browser must fetch and process before it can display a page. They slow the first paint for users and add work when search engines render pages to evaluate content. Reducing render-blocking — deferring non-critical JavaScript, inlining critical CSS, and minimising blocking requests — speeds rendering for both visitors and crawlers.
- Server response time and crawling
Server response time directly affects how much Google can crawl. Googlebot adjusts its crawl rate to avoid overloading a server, so consistently slow responses reduce the number of pages it fetches. Persistent slowness or 5xx errors cause Google to back off. This page explains the crawl-rate-versus-response-time relationship, its connection to time-to-first-byte, and how to keep responses fast under crawl load.
- Website observability
Watch server response timing to crawler fetches, the TTFB part of LCP.
Sources and verification notes
- web.dev — Largest Contentful Paint (LCP)Definition, thresholds, and the four LCP sub-parts.
- web.dev — Optimize LCP
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.