---
title: "Largest Contentful Paint: Definition, Thresholds & Fixes"
description: "Largest Contentful Paint (LCP) measures how long the biggest visible element on a page takes to render, and it's one of Google's three Core Web Vitals."
canonical_url: "https://kinetixseo.com/articles/largest-contentful-paint"
published_at: "2026-10-05T07:29:02+00:00"
updated_at: "2026-10-01T13:52:23+00:00"
author: "Rogier Bruggeman"
category: "Technical SEO"
---
# Largest Contentful Paint: Definition, Thresholds & Fixes

Largest Contentful Paint (LCP) measures how long the biggest visible element on a page takes to render, and it's one of Google's three Core Web Vitals.

## What is largest contentful paint?

Largest Contentful Paint (LCP) measures how long the biggest visible element on a page takes to render, and it's one of Google's three Core Web Vitals. It's recorded in seconds, timed from when a user requests a page to the moment the largest image, video poster, or block of text finishes painting inside the viewport. Google groups the result into three bands — good, needs improvement, and poor — with the exact cutoffs published in Google's own Core Web Vitals documentation and covered in full in our guide to [Core Web Vitals 2026](https://kinetixseo.com/articles/core-web-vitals-2026-what-actually-moves-rankings). LCP exists because older load metrics like "time to first byte" or "DOMContentLoaded" told you when the server responded or when the HTML parsed, not when the page actually looked finished to the person waiting on it.

That gap between a technical load event and a visual one is exactly what LCP closes. A server can return a 200 status quickly and still leave a user staring at a blank screen while a hero image downloads. LCP is the metric that catches that case, because it tracks the single largest element a user actually sees, not the plumbing behind it. It's one of three Core Web Vitals alongside Interaction to Next Paint (responsiveness) and Cumulative Layout Shift (visual stability), and Google uses field data from real Chrome users, not just lab tests, to decide whether a page passes. Treating LCP as the whole of "page speed" is the first mistake most teams make — it's one narrow measurement of one specific render moment, not a general verdict on how fast a site feels.

## How LCP is actually measured

The browser calculates LCP by watching every paint event on a page, keeping a running record of whichever rendered element currently has the largest visible area, then locking in that element's render time once the user interacts with the page or the page finishes loading, whichever comes first. The elements that qualify are limited to a specific list: `<img>` tags, the `poster` image of a `<video>`, background images loaded via CSS, and block-level text elements like a heading or paragraph that contains the first text node a user sees. Elements that are hidden off-screen, have zero opacity, or get removed before paint don't count, and elements added after the user starts scrolling or clicking are ignored, since LCP is only meant to describe the initial, uninterrupted load experience.

In practice, the "largest" element is almost always one of three things: a hero image, a background-image banner, or a large headline sitting above a hero image before that image has loaded. A news homepage with a full-width photo under its masthead will typically clock LCP against that photo. An ecommerce product page will clock it against the main product shot. A text-heavy blog post with no hero image might clock it against the `<h1>` itself, which is why removing a hero image sometimes lowers LCP faster than optimizing one. This is a useful diagnostic step on its own: before changing any code, check which element Chrome DevTools or PageSpeed Insights is flagging as the LCP candidate, because fixing the wrong element wastes a sprint.

## The common misunderstanding about LCP

LCP measures the render time of one specific element, not the total time every resource on a page takes to load — treating it as a page-load stopwatch is the most common mistake made about it. A page can have dozens of images still loading below the fold, ads still fetching, and third-party widgets still initializing, and none of that affects LCP once the largest above-the-fold element has painted. Teams sometimes chase a lower LCP by optimizing every image on a page, when the actual fix was compressing or preloading the one specific hero image Chrome is measuring.

LCP and overall page speed are not the same thing, and conflating them leads to false confidence in both directions. A site can genuinely feel fast to a user — fast enough to start reading or scrolling immediately — while still failing LCP, because the metric cares specifically about the largest element, not the elements the user actually looks at first. The reverse also happens: a page can pass LCP comfortably while still feeling sluggish, because LCP says nothing about how responsive the page is once the user starts clicking around, which is what Interaction to Next Paint measures instead. Each Core Web Vital measures a narrow, specific moment in the load sequence, and all three need to be read together rather than treated as one undifferentiated speed score.

## Why LCP shows up so often in technical audits

Most slow LCP scores trace back to one of six causes: a slow server, render-blocking code, an unoptimized hero image, missing preload hints, client-side rendering of above-the-fold content, or web fonts that delay text paint. Each cause delays the browser from reaching the moment it can paint the LCP element, just further back in the chain — a slow server delays everything downstream, while a missing preload hint delays only the one resource the browser hasn't discovered yet. Diagnosing which of the six applies to a given page is what the next section's fix sequence is built around, because the right fix only works once you know which link in that chain is actually broken.

The parallel to content structure is exact, which is why this shows up in audits across formats, not just code. According to the [KinetixSEO crawl study](https://kinetixseo.com/learn/studies/seo-guide-articles-answer-block#run-01m3c60nrk6qdbky9hgeke7hy5), only 31% of 35 public SEO and web-performance guide articles from software vendors and developer publications answered their own headline question in the first paragraph — the rest buried the direct answer under a preamble. That's a content-structure finding, not an LCP measurement, but it describes the same underlying failure: a page that makes a user wait through render-blocking scripts and late-loading images before showing the element that matters is making the same mistake in render order that a buried answer makes in prose. In both cases, the fix is the same instinct — put the thing the user came for first, and strip out whatever delays it.

Each of the six causes has a distinct fix, and diagnosing which one applies to a given page is what makes an LCP fix effective rather than cosmetic:

- **Slow server response time** — a high Time to First Byte delays every render event downstream of it, including LCP, since nothing can paint until the HTML arrives.
- **Render-blocking CSS and JavaScript** — stylesheets and scripts loaded in the `<head>` without `async` or `defer` delay the browser from reaching the point where it can paint the LCP element.
- **Unoptimized hero images** — large, uncompressed, or wrongly-formatted images (full-size JPEGs instead of WebP or AVIF) take longer to download and decode.
- **Missing image preloading** — if the LCP image is discovered late because it's set via CSS background or loaded by JavaScript, the browser can't start fetching it early.
- **Client-side rendering of above-the-fold content** — pages that render their hero content via JavaScript after the initial HTML load push LCP later, since the browser has to execute scripts before anything appears.
- **Web font loading that delays text render** — if the LCP element is text and the custom font hasn't loaded, some browsers block the paint until the font resolves.

## Fixing LCP: the practical sequence

Fixing LCP follows a logical order, because each fix depends on correctly identifying what the browser is actually measuring on that specific page. Skipping the diagnostic step and jumping straight to "compress images" is the single most common reason teams ship a fix that doesn't move the number — the six causes above only turn into fixes once you know which one is actually present.

1. **Identify the actual LCP element.** Open Chrome DevTools' Performance panel or PageSpeed Insights and find the specific element flagged as the Largest Contentful Paint candidate — don't assume it's the hero image until you've confirmed it.
2. **Check if it's server-side or client-side.** If the element is present in the initial HTML response, the fix is about delivery speed. If it's injected by JavaScript after load, the fix is about rendering strategy — consider server-side rendering or static generation for that section.
3. **Preload the LCP resource.** Add a `<link rel="preload">` tag for the hero image or font so the browser starts fetching it immediately, rather than discovering it only after parsing CSS.
4. **Compress and right-size the image.** Serve the image in a modern format (WebP or AVIF), sized to the actual display dimensions rather than the source upload size, and avoid serving an oversized image into a small container.
5. **Remove render-blocking resources above it.** Defer or async any CSS and JavaScript that isn't needed to paint the above-the-fold content, so the browser reaches the LCP paint step sooner.
6. **Re-test in the field, not just the lab.** Lab tools like Lighthouse run once under controlled conditions; confirm the fix holds up in Chrome User Experience Report (CrUX) field data, which reflects real users on real networks.

## LCP compared to the other Core Web Vitals

LCP measures loading speed specifically, which separates it clearly from the two metrics it's grouped with under Core Web Vitals. Misdiagnosing which Core Web Vital is actually failing is a common audit mistake, and it happens because all three get lumped together under "page speed" when each measures something different. The three together are meant to cover the full experience of a page, from first appearing to being usable to staying visually stable.

MetricWhat it measuresWhat determines a passLargest Contentful Paint (LCP)Time until the largest visible element rendersCompared against Google's published "good" thresholdInteraction to Next Paint (INP)Responsiveness to user interactions like clicks or tapsCompared against Google's published "good" thresholdCumulative Layout Shift (CLS)Visual stability — how much content shifts unexpectedlyCompared against Google's published "good" thresholdThe exact numeric cutoffs for each of these are set out in our [Core Web Vitals 2026](https://kinetixseo.com/articles/core-web-vitals-2026-what-actually-moves-rankings) guide rather than repeated here, since Google revisits them periodically. A page can fail any one of these independently. A product page with a fast, well-optimized hero image can still score poorly overall because a late-loading ad pushes content down after the user starts reading, which is a CLS problem, not an LCP one. Running all three metrics together, rather than treating "page speed" as one undifferentiated number, is what separates a useful technical audit from a cosmetic one.

## Where LCP fits in a broader technical SEO audit

A perfect LCP score doesn't protect a page from other technical problems that keep it out of search features entirely, so LCP work needs to sit inside a wider audit rather than standing alone. A page with a perfect LCP score but broken structured data still won't earn [rich results](https://kinetixseo.com/articles/rich-results) in search; our guide to [structured data and JSON-LD](https://kinetixseo.com/articles/structured-data-for-seo-a-practical-json-ld-guide) covers that side of the audit, and the shorter [structured data glossary entry](https://kinetixseo.com/learn/structured-data-glossary) is a faster reference if you just need the definition. Getting markup right also feeds directly into eligibility for enhanced listings, which our guide to [rich results](https://kinetixseo.com/articles/rich-results) and the companion [article schema setup guide](https://kinetixseo.com/articles/article-schema) both walk through. Similarly, a fast-loading page that search engines can't efficiently crawl at scale runs into the separate problem covered in our guide to [crawl budget optimization](https://kinetixseo.com/articles/how-to-fix-crawl-budget-waste-on-large-sites), which matters more on large sites than on a single landing page. None of these substitute for fixing LCP directly, but treating page speed as the only technical signal that matters is its own kind of blind spot.

## Frequently asked questions

### What is considered a good LCP score?

A good LCP score is one that falls under the threshold Google publishes as "good" in its Core Web Vitals documentation, measured from when the page starts loading to when the largest visible element finishes rendering. Google classifies scores above that into "needs improvement" and "poor" bands, with the exact cutoffs detailed in our Core Web Vitals 2026 guide. These thresholds are applied against a distribution of real-world page loads recorded in Chrome's field data, not a single lab test, meaning a page needs to clear the bar consistently across visits to pass, not just once under controlled conditions.

### Is LCP a ranking factor?

LCP is one of three Core Web Vitals that Google has confirmed are part of its page experience signals, though it's one of many factors in ranking and typically has limited weight compared to content relevance. Google has been explicit that Core Web Vitals act more as a tiebreaker among otherwise similarly relevant pages than as a dominant ranking signal. A page with excellent content and a poor LCP score can still outrank a page with strong Core Web Vitals and thin content, which is why LCP work should supplement a content strategy, not replace one.

### What usually causes a poor LCP score?

A poor LCP score is usually caused by slow server response time, render-blocking CSS or JavaScript, or an unoptimized hero image that takes too long to download and decode. Client-side rendering, where the above-the-fold content is injected by JavaScript rather than present in the initial HTML, is another frequent cause, since the browser has to download and execute scripts before it can paint anything. Checking which of these applies to a specific page requires looking at the actual LCP element flagged in DevTools, rather than assuming it's always the largest image on the page.

### Does LCP measure the whole page loading?

No, LCP only measures the render time of one specific element — the largest visible one in the viewport — not when the entire page, including below-the-fold content and background scripts, has finished loading. A page can have dozens of unloaded images and scripts still running after its LCP has been recorded, as long as those elements aren't the largest visible one and don't block it from rendering. This is the most common misunderstanding about the metric, and it's why optimizing unrelated page elements often fails to move an LCP score at all.

### How is LCP different from First Contentful Paint?

First Contentful Paint (FCP) records the moment any content — even a single word or a tiny icon — first appears on screen, while LCP records the moment the largest element finishes rendering. A page can have a fast FCP because a small loading indicator or a line of text appears quickly, while its LCP remains slow because the actual hero image or headline the user came to see takes several more seconds to finish painting. The gap between a page's FCP and LCP is itself a useful diagnostic: a large gap usually points to a late-discovered or slow-loading hero resource.

## Sources
- [KinetixSEO crawl study — Only 31% of the 35 public SEO and web-performance guide articles from software vendors and developer publications answer their own headline question in the first paragraph. Sample: 35 observations, measured Sep 25, 2026. Methodology: Fetched each of the 35 public SEO and web-performance guide articles from software vendors and developer publications and counted the pages whose first body paragraph runs under 80 words and repeats a distinctive word from the page's own H1 — an answer up front rather than a preamble.](https://kinetixseo.com/learn/studies/seo-guide-articles-answer-block#run-01m3c60nrk6qdbky9hgeke7hy5) (2026-09-25)