tech

How to fix: Largest Contentful Paint <=2.5s

Why this matters

Largest Contentful Paint measures when the main content finishes loading — Google's primary loading-speed Core Web Vital. <=2.5s is Good; >4s is Poor and tanks rankings. Optimise hero images, preload critical resources, fix slow TTFB.

Background

LCP measures when the largest above-fold element finishes rendering — usually a hero image, headline, or main content block. Google uses field-data p75 LCP as one of the three Core Web Vitals ranking signals. <=2.5s = Good; >4s = Poor and reduces rankings.

References

web.dev/lcp · Google Search Central · Core Web Vitals (LCP)

How to fix

Code snippet for each stack we cover. Pick the one matching your server / framework.

nginx

Enable HTTP/2 + gzip + Brotli + static asset caching. Add `Cache-Control: public, max-age=31536000, immutable` to fingerprinted assets.

apache

Same — mod_http2, mod_deflate, mod_expires.

cloudflare

Pro plan: APO (Automatic Platform Optimization). Polish for images. Tiered caching. Speed → Optimization → enable Brotli + Auto Minify.

wordpress

WP Rocket / FlyingPress: critical CSS, lazy-load below-fold images. Convert hero image to WebP. Add width+height on every <img>. Use ShortPixel / EWWW for image optimisation.

flask

Server-side render the hero text (don't wait on JS). `<link rel="preload" as="image" href="hero.webp">` for the hero. Inline critical CSS.

express

Same — preload critical resources, SSR the hero, use HTTP/2 push.

rails

Same — turbo_stream for SSR, importmap or jsbundling for module-loading control.

Verify it's working

Test at https://pagespeed.web.dev/ — Mobile LCP should be <=2.5s. Re-run after every optimisation.

Want to know if your site has this issue?

Run a free 53-check audit — security, GDPR, NIS2, and technical SEO.

Audit my site →