Largest Contentful Paint measures how long the biggest element in the first viewport — almost always a hero image or headline — takes to finish rendering. Google wants it under 2.5 seconds on real devices. When it is slow, the cause sits somewhere on a four-step chain, and the fix is to walk the chain in order.
1. Find your actual LCP element
Run the page in PageSpeed Insights and expand the LCP audit — it names the exact element. Everything that follows depends on what it is: an image, a background image, or a text block each has a different fix. Do not optimise blind.
2. Cut server time (TTFB)
Nothing can paint before the server responds. If time-to-first-byte is over ~600ms, fix that first: enable full-page caching, upgrade PHP to a current version, and if the host is simply slow under load, move. A slow origin makes every other optimisation cosmetic.
3. Unblock rendering
CSS files block painting until they download. Reduce the blocking chain:
- Remove unused CSS — page builders and theme bundles ship far more than a page uses.
- Inline the critical CSS for above-the-fold content and defer the rest.
- Load fonts with
font-display: swapand preconnect to the font host, so text paints immediately.
4. Fix the LCP image itself
For an image element: serve it in WebP or AVIF at the size it is actually displayed, add fetchpriority="high", preload it, and — critically — exclude it from lazy loading. WordPress lazy-loads by default, and a lazy-loaded hero is the single most common LCP fault we find. The hero should start downloading in the first round trip, not after the layout settles.
5. Verify with field data
Lab tests confirm the mechanics, but Google ranks on the Chrome UX Report. After the fixes, watch the Core Web Vitals report in Search Console for the 28-day field number to move. That is the number that counts — and the one to show whoever asked you to fix it.