Largest Contentful Paint is the Core Web Vital most sites fail. It measures when the biggest thing in the first screen, usually a hero image, product photo or headline, finishes rendering. Google counts 2.5 seconds or less at the 75th percentile of real visitors as good. Most slow LCPs come down to the same seven causes, and the trick is knowing which one you have before you start changing things.
First, find out where the time goes
Every LCP breaks down into four parts. Knowing which part is biggest tells you which fix to reach for.
- Time to First Byte: how long the server takes to start sending HTML.
- Resource load delay: the gap between the first byte and the browser starting to download the LCP image.
- Resource load duration: how long the image itself takes to download.
- Element render delay: the time between the image arriving and it actually appearing on screen.
Run your page through PageSpeed Insights and open the Largest Contentful Paint element diagnostic. It names the element and shows this breakdown. In Chrome DevTools, the Performance panel shows the same phases on a timeline.
Rule of thumb
1. The hero image is lazy-loaded
This is the single most common LCP mistake and the easiest to fix. Lazy-loading tells the browser to wait until it knows the image is in view, which means it waits for layout. That wait lands directly in your LCP. Lazy-load images below the fold, never the main image in the first screen.
<!-- Before -->
<img src="/hero.avif" loading="lazy" alt="Team at work">
<!-- After -->
<img src="/hero.avif" fetchpriority="high" width="1600" height="900" alt="Team at work">2. The browser discovers the image too late
The browser's preload scanner finds images in your HTML almost instantly. It cannot find images set as CSS backgrounds, injected by JavaScript, or swapped in by a slider script. If your hero lives in any of those places, the download starts late. Move it into an img tag, or preload it.
<link rel="preload" as="image" href="/hero.avif" fetchpriority="high">3. The server is slow to respond
If Time to First Byte alone is over about 800 milliseconds, no front-end change will rescue your LCP. Common causes are uncached pages generated on every request, slow database queries, cheap shared hosting and visitors far from your server.
- Turn on full-page caching for pages that are the same for every visitor.
- Serve the site through a CDN so HTML is delivered from a location near each visitor.
- Check for redirect chains, since every redirect adds a full round trip before the page starts.
4. The image is far too big
A 4000-pixel photo straight off a camera can weigh several megabytes. On a phone that only needs a 800-pixel version, that is wasted download time on the most important resource on the page. Serve AVIF or WebP, and use srcset so each device downloads a size it can actually use.
5. Render-blocking CSS and JavaScript
The browser will not paint anything until it has downloaded and processed the CSS and synchronous scripts in your head. A large render delay is the symptom. Inline the small amount of CSS needed for the first screen, add defer to scripts that do not need to run first, and remove stylesheets from plugins you no longer use.
6. Web fonts are hiding your headline
When the LCP element is text, a custom font can hold it hostage. Browsers hide text for up to three seconds while a font downloads. Preload your main font file and use font-display: swap so the headline renders immediately in a fallback font.
7. The page is rendered in the browser
Single-page apps that render everything with JavaScript have to download, parse and run that JavaScript before the hero even exists in the page. Server-side rendering or static generation puts the hero in the initial HTML, where the browser can find it immediately. This is the biggest change on the list, so rule out the first six first.
Verify the fix
Re-run PageSpeed Insights a few times and compare the median, not a single run. Field data in Search Console updates on a rolling 28-day window, so give real-user numbers a few weeks to catch up.
LightLoader handles causes one, two, four and six automatically: it detects the likely LCP element, raises its priority, stops it being lazy-loaded and prioritizes critical fonts. Whichever route you take, fix the biggest phase first and measure after every change.