How to fix a slow Largest Contentful Paint
Largest Contentful Paint measures how long the biggest image or text block in the viewport takes to render after a visitor navigates to your page. Google's web.dev documentation sets one concrete target: “sites should strive to have Largest Contentful Paint of 2.5 seconds or less,” measured at the 75th percentile of real page loads across mobile and desktop. Four levers move it: server response time, render-blocking resources, image loading priority, and client-side rendering. Almost every slow LCP traces to one of the four.
The symptom: the page is up, but nothing is on it
A visitor taps your link and stares at a blank or half-painted screen. The connection worked. The server answered. But the thing they came to see, the hero image, the headline, the product photo, has not rendered yet. LCP is the metric that captures that exact moment: the render time of the largest visible element, counted from when the user first navigated to the page.
The number that matters is the field number. In PageSpeed Insights it appears under “Discover what your real users are experiencing,” sourced from the Chrome UX Report. If your 75th-percentile LCP sits above 2.5 seconds, a quarter or more of your real visitors are waiting longer than Google's documented threshold for a good experience. They do not know the metric's name. They know the page feels slow, and some of them leave before it finishes.
The cause: four levers, and usually one is stuck
Every slow LCP decomposes into the same four parts, and they add up in sequence.
- Server response time. Nothing can render before the first byte arrives. A slow origin, a cold serverless function, or an uncached HTML response spends the budget before the browser has anything to work with.
- Render-blocking resources. Stylesheets and synchronous scripts in the head stop the browser from painting anything until they download and execute. Every blocking third-party tag is a toll booth in front of your content.
- Image loading. The most common failure we see: the hero image, the LCP element itself, is discovered late or explicitly deprioritized. Lazy-loading the above-the-fold image is the classic self-inflicted wound. The browser is told the most important thing on the page can wait.
- Client-side rendering. If the largest element only exists after a JavaScript bundle downloads, parses, and runs, LCP inherits the cost of all three. The HTML arrived fast and empty.
The fix: work the levers in order
Start at the server and move toward the pixel. Fixes earlier in the chain make everything after them faster.
- Cache the HTML response at a CDN or shorten origin work so the first byte leaves fast. Measure time to first byte before touching anything else.
- Cut render-blocking weight. Inline the small amount of CSS the first paint needs, defer scripts that do not shape the initial view, and drop third-party tags that no one can justify.
- Tell the browser the hero matters. Never lazy-load the LCP image, and raise its priority explicitly:
<!-- The LCP image: discovered early, fetched first --> <link rel="preload" as="image" href="/hero.webp" fetchpriority="high" /> <img src="/hero.webp" alt="What the page is about" fetchpriority="high" width="1200" height="640" /> <!-- Below-the-fold images only --> <img src="/further-down.webp" loading="lazy" width="800" height="450" />
Last, put the largest element in the HTML itself. Server-render or statically generate the above-the-fold content so the browser can paint it without waiting for a bundle. If your headline only exists after React hydrates, no image trick will save the metric. Google's optimize LCP guide walks the same four levers in depth, with the breakdown timings to diagnose which one is yours.
Be honest: field data decides, and speed is one signal
Two honest cautions. First, lab tools like Lighthouse simulate one throttled load on one simulated device. That is useful for debugging and useless as a verdict. The number Google's ranking systems see comes from field data, real Chrome users in the CrUX dataset, at the 75th percentile. A clean lab run on your fast laptop proves nothing about the phones your visitors actually hold. Judge yourself on field data or not at all.
Second, speed is one signal among many, and it is not a rescue. A page that loads in 1 second with nothing worth citing on it will lose to a slower page that actually answers the question. We have watched owners spend a month chasing milliseconds while their content said nothing an engine could quote. Fix a genuinely slow LCP, then spend the rest of your effort on the words. That is where citations come from.
Verify: read the field number, then re-run
Run your URL through PageSpeed Insights and read the field section first. If your page has enough traffic for CrUX data, that 75th-percentile LCP is your real score. Under 2.5 seconds is documented as good. Note that field data is a rolling 28-day window, so a fix you ship today takes weeks to fully show up. The lab section confirms the mechanism moved in the meantime: check that the LCP element is what you think it is and that its load delay collapsed.
Then verify it the way the engines will. Paste your link into our GEO audit or the full Brimm audit and we read the page the way a crawler does, including whether your largest content exists in the raw HTML at all. If your LCP problem is really a rendering problem, our guide on sites that don't render without JavaScript is the deeper fix, and the rest of the fix library covers the failures that speed alone cannot solve.