The single most common LCP mistake on WordPress sites in 2026 is deceptively simple: lazy-loading the hero image. That image is very often your page’s actual LCP (Largest Contentful Paint) element, and lazy-loading tells the browser to defer it — which is precisely backward for the one image you most need to load immediately.
Why This Keeps Happening
Since WordPress 5.9, lazy loading doesn’t apply to the very first image or iframe on a page specifically to avoid this exact problem — but that default protection breaks down the moment a theme, page builder, or custom template structure changes what WordPress considers the “first” image, or when an image optimization plugin applies lazy-loading more aggressively than core’s own safeguard. The mistake isn’t usually a developer deliberately lazy-loading a hero image; it’s a plugin or theme configuration silently overriding the protection that should have prevented it.
The Full LCP Optimization Checklist
| Step | Why it matters |
|---|---|
| Identify the actual LCP element via Chrome DevTools | Confirms exactly which element you’re optimizing for, rather than assuming |
| Preload the LCP image | Tells the browser to fetch it as early as possible in the load sequence |
| Serve it in WebP/AVIF at correct dimensions | Reduces file size without sacrificing visible quality — WebP is roughly 30% smaller than JPEG, AVIF around 50% |
| Skip lazy-loading specifically on the LCP image | The core fix this piece is about — never defer the one image the browser needs immediately |
| Serve via CDN with edge caching | Reduces distance/latency between the visitor and the image file |
| Reduce server TTFB via page caching | A slow server response delays everything downstream, including the LCP image request itself |
Self-host fonts with font-display: swap |
Prevents render-blocking font loading from indirectly delaying LCP |
How to Actually Catch This on Your Site
- Open Chrome DevTools’ Performance panel and identify your actual LCP element on a few key page templates (homepage, a typical content page) — don’t assume it’s the hero image without confirming.
- Inspect that element’s HTML for a
loading="lazy"attribute — if present on your confirmed LCP element, that’s the direct bug to fix. - Check your image optimization plugin’s settings for an LCP-exclusion feature — several current plugins (EWWW Image Optimizer, Smush, among others) specifically support excluding the detected LCP image from lazy-loading automatically.
- Re-test after any theme or plugin update that touches image rendering — this is exactly the kind of regression that can silently reappear after a change to a system that previously had it correctly configured.
This pairs with fetchpriority: The One-Line Fix That Cuts LCP and AVIF vs WebP for WordPress in 2026. Want your site’s LCP element and lazy-loading configuration audited? Get in touch.
Frequently Asked Questions
Does WordPress core protect against this automatically?
Since WordPress 5.9, core excludes the first image/iframe from automatic lazy-loading — but that protection can be overridden by theme markup structure or a plugin applying its own lazy-loading logic on top, so it’s not a guarantee, just a default.
Should I lazy-load any images at all?
Yes — below-the-fold images should still be lazy-loaded; that’s the correct, performance-positive use of the technique. The mistake is specifically applying it to the above-the-fold hero/LCP image.
How do I know if this is actually affecting my site’s score?
Check your Core Web Vitals field data (Search Console or PageSpeed Insights) for LCP specifically, and cross-reference with a DevTools inspection of whether your confirmed LCP element carries a lazy-loading attribute.
Featured image: original illustration.