Learn
LCP Optimization Guide: Improve Largest Contentful Paint and Page Speed
A deep guide to Largest Contentful Paint: the four phases that make it up, how to identify your LCP element, and the fixes that actually move it.
Run a fresh DomainLens audit and use the report as your priority list.
What LCP measures
Largest Contentful Paint (LCP) marks the moment the largest piece of content in the viewport — usually a hero image, a video poster, or a big block of text — finishes rendering. It is the metric that best answers "when did this page actually look ready?", which is why it maps so closely to whether a landing page feels fast.
A good LCP is 2.5 seconds or less at the 75th percentile of real users; above 4 seconds is poor. Because it is measured in the field across your slowest quarter of visits, a page that feels instant on your office connection can still fail.
The four phases of an LCP
The single most useful thing you can do is stop treating LCP as one number and break it into its four sub-parts. Almost every fix targets one of these, so measuring the split tells you where the time actually goes:
- Time to First Byte (TTFB): how long the server takes to send the first byte. Slow backends, no caching, and distant hosting live here.
- Resource load delay: the gap between the first byte and the browser starting to fetch the LCP image — usually caused by late discovery or low priority.
- Resource load time: how long the LCP image itself takes to download. Oversized, uncompressed, wrong-format images live here.
- Element render delay: time from the image being downloaded to it actually painting — usually blocked by render-blocking CSS or JavaScript.
How to find your LCP element
You cannot fix what you have not identified — and the LCP element differs by template and viewport.
- In the Performance panel, record a load and look at the "LCP" marker in the Timings track; it names the exact element.
- Run PageSpeed Insights and read the "Largest Contentful Paint element" diagnostic, which shows the node and its phase breakdown.
- Check both mobile and desktop — the LCP element is frequently a different image on each.
- Confirm against field data so you are optimising the element real users wait for, not the one your fast lab test happens to pick.
How to make the LCP element arrive sooner
- Cut TTFB: cache HTML at the edge/CDN, warm slow database queries, and host close to your audience.
- Make the LCP image discoverable immediately: put it in the initial HTML with fetchpriority="high", and preload it if it is set via CSS or injected by JavaScript.
- Never lazy-load the LCP image — loading="lazy" on the hero is one of the most common self-inflicted regressions.
- Shrink the file: serve a correctly sized, modern-format image (AVIF/WebP) with responsive srcset so mobile does not download a desktop hero.
- Remove render-blocking work: inline critical CSS, defer non-critical CSS and JavaScript, and avoid injecting the hero with a client-side framework after hydration.
Mistakes that inflate LCP
- Optimising the Lighthouse lab score while ignoring field TTFB, which the lab under-represents.
- Preloading everything, which floods the network and delays the one resource that matters.
- Serving the hero from a slow third-party origin without a preconnect.
- Rendering the main content only after a client-side data fetch, so the LCP waits on JavaScript and an API round-trip.
How to validate LCP
Re-run the Performance trace and confirm the phase you targeted actually shrank — a lower TTFB, an earlier image request, or removed render-blocking. Then watch the field LCP in Search Console trend down over the following weeks, since it aggregates 28 days of real visits.
In DomainLens, read LCP together with server response time and the render-blocking resources it reports: the fastest win is usually getting the real hero image requested earlier and downloaded smaller, on the mobile connection your visitors actually use.