Which elements can be the LCP element
Browsers only consider certain elements: images, images inside an SVG, videos (using the poster image or first frame), elements with a CSS background image loaded through url() (gradients do not count) and block-level elements containing text. The candidate can change as the page loads: the largest element rendered before the user's first interaction is the one reported.
The official thresholds
LCP is good at 2.5 seconds or less, needs improvement between 2.5 and 4 seconds, and is poor above 4 seconds. Google evaluates the 75th percentile of page loads, separately for mobile and desktop. A page that feels fast on your office fiber connection still has to be fast for three quarters of your visitors, including those on a weak cellular signal.
Breaking LCP into four phases
To find where time is lost, the Chrome team splits LCP into four consecutive parts:
- Time to first byte (TTFB): how long the server takes to start sending HTML.
- Resource load delay: time before the browser discovers and requests the image.
- Resource load duration: downloading the image itself.
- Element render delay: the wait between download and display, often caused by render-blocking CSS or JavaScript.
How to fix a slow LCP
The most effective fixes are simple: compress the hero image and serve it in AVIF or WebP at the right size, never lazy-load it, give it high priority with the fetchpriority attribute, cut server response time with caching and a CDN, and avoid building the main content only with client-side JavaScript.
Work through the phases in order. If server response time alone eats most of the 2.5-second budget, image work will not be enough: look at hosting, caching and redirects first. If resource load delay dominates, the image is discovered too late, usually because it is set in CSS or injected by JavaScript, so reference it directly in the HTML instead.