Reference guide · performance · Published 2026-08-15 · 4 min read
Optimising LCP (Largest Contentful Paint)
Improve your LCP below 2.5 seconds: know the LCP element, split time into server, resource, and render legs, then work the fix list top to bottom.
- ·The LCP element
- ·Why LCP is slow
- ·Fix order
The LCP element
Largest Contentful Paint measures when the largest content element above the fold finishes painting. Only a small set of element types can hold this title: an img, an SVG image, a video poster or its cover, a CSS background image, or a block of text large enough to win. On a typical marketing page the hero shot or a big headline takes it; a 180px logo in the corner does not count.
Find the element before fixing, because the fix differs. The Lighthouse audit called "Largest Contentful Paint element" names it and shows the sub-phases it spent time in. If the element is an image, the win is in sizing and preloading; if it is a text node, the win is usually in font loading and render-blocking CSS. Chasing both at once is how optimisation time gets wasted.
Why LCP is slow
LCP time is the sum of three legs:
| Leg | What it covers | Typical fix |
|---|---|---|
| Server time | DNS, connection, TTFB | caching, hosting, server config |
| Resource time | Image and script download | resize, compress, preload |
| Render time | CSSOM, JavaScript, first paint, then the element | critical CSS, script loading |
Good LCP is 2.5 seconds or less at the 75th percentile. "Needs improvement" runs to 4.0 seconds, and anything above that is poor. The same page can be poor on mobile and good on desktop, so always test against the form factor that actually suffers.
The fix list, in order
Follow these in order. Each step builds on the last, and the later steps do not matter until TTFB and the image itself are under control.
Step 1: Name the element
Run the Lighthouse "Largest Contentful Paint element" audit and note the candidate plus its timing breakdown. Save the number; you will re-check it after each step.
Step 2: Cut server time
The server leg includes DNS, the connection, and TTFB. Static hosting, a CDN, and HTTP cache headers remove most of it. The Core Web Vitals explained page shows how TTFB sits inside LCP but is not a metric on its own.
Step 3: Make the candidate itself fast
- Serve the LCP image at the size it actually renders; do not send a 4000px file into a 1200px slot.
- Compress it into WebP or AVIF. The image optimisation guide walks the format and compression choices.
- Do not lazy-load the hero. For below-the-fold images,
loading="lazy"is fine.
Step 4: Preload the candidate
The hero image only starts downloading when the browser finds it in the HTML. A <link rel="preload" as="image" href="/hero.webp" fetchpriority="high"> in the head starts the fetch earlier. On WordPress you can set this at theme level rather than editing every page.
Step 5: Clear the path to first paint
Render-blocking CSS on the critical path delays first paint, which moves the whole timeline out. Inline the critical CSS for the hero region and defer the rest.
Step 6: Re-measure, then look for stability
Re-run the same Lighthouse audit and compare against the PageSpeed Insights field report (which reflects real mobile visitors, not your machine). If the lab is good but the field is not, the gap is usually server time or an unoptimisable third-party on mobile.
Keep one rule: LCP is only as good as its slowest leg. Optimizing the render leg while the origin delivers the hero at 2 MB shows a small number moving in the report. The visual: the largest element, loaded exactly as large as it needs to be, with nothing blocking the first paint.