How the browser picks the LCP element
While the page loads, the browser keeps a running “largest element so far”. Each time something bigger paints, it replaces the candidate, and it stops as soon as the visitor taps, clicks or scrolls. The final candidate’s paint time is the LCP.
Scrub through a page load
Largest element painted so far: nothing yet
Final LCP: 2.6 s (hero image) → Needs improvement
The browser keeps replacing its LCP candidate each time a larger element paints, and stops when the visitor first interacts. Fast text doesn't help if a big image arrives late: the image is the one that counts.
The four parts of LCP
Google splits every LCP into four phases. The speed test shows them for your page under “Your largest element”.
| Phase | What happens | Typical fix |
|---|---|---|
| Time to first byte | Server sends the HTML | Edge caching, fewer redirects |
| Resource load delay | Browser discovers the image | Put the image in the HTML (not in JS or CSS), add fetchpriority="high" or a preload |
| Resource load time | Image downloads | AVIF/WebP, correct size via srcset, image CDN |
| Element render delay | Image is ready but not painted yet | Remove render-blocking CSS/JS, avoid client-side rendering the hero |
On a well-optimised page, the two “delay” phases should be close to zero. Google’s analysis of Chrome data found load delay, not download time, is the biggest part for most sites with poor LCP.
Common causes of a slow LCP
- The hero image is lazy-loaded, or injected by JavaScript after the page runs.
- It is set as a CSS background, so the browser can’t find it until the stylesheet has loaded.
- It is a multi-megabyte JPEG served at desktop size to phones.
- A cookie banner or popup becomes the largest element and loads late.
- Slow server response pushes everything back (check the TTFB checker).