On most WordPress sites, the LCP element is the hero image — which means the theme’s handling of that one image largely decides your Core Web Vitals grade. We find the same four mistakes in audit after audit, and each has a known fix.
Mistake 1: The hero is a full-size upload
A 4000×2600 original, 1.8 MB, displayed at 1400px wide. The browser downloads all of it. Themes that print the full-size URL in the hero slot (instead of using WordPress’s responsive srcset) make this easy to miss — it looks fine, it loads terribly.
Fix: use the theme’s image-size options or ensure the hero goes through WordPress’s responsive image functions. Convert to WebP while you are at it — every cover on this site is WebP for exactly this reason.
Mistake 2: No priority hint on the LCP image
By default the browser discovers your hero image only after parsing CSS and markup. fetchpriority="high" on the hero img tag tells Chrome to start fetching immediately — worth 0.2–0.6s in our tests. Conversely, the hero must not have loading="lazy": lazy-loading your LCP element is an automatic LCP penalty, and themes that lazily load featured images in templates commit this constantly.
Mistake 3: CSS background heroes
Themes that implement heroes as CSS backgrounds lose the browser’s preload scanner: background images wait for CSS download and parsing. If your theme renders the hero as a background-image, that image cannot be prioritized at all.
Fix: prefer an <img>-based hero. If the design demands a background, preload it manually.
Mistake 4: Double downloads via srcset mistakes
Mismatched sizes attributes make browsers fetch a larger candidate than needed — a 1920px file for a 700px slot. Check the DevTools network panel for what actually loaded versus what rendered.
The checklist
- Hero served as WebP, sized to its slot (1280–1600px wide for full-width heroes).
fetchpriority="high", noloading="lazy".<img>markup, not CSS background.- Sane
sizesattribute; verify actual downloaded file in DevTools.
Measured impact
Across client sites where the hero was the LCP element: fixing sizing plus priority hints moved LCP by 0.3–1.1s. On one site with a lazy-loaded hero, removing just the lazy attribute recovered 0.5s.
Hero handling is one of the checks in the slow-theme diagnostic. If you would rather not audit templates yourself, the free audit reports your LCP element and what it loaded. The web.dev LCP guide covers the browser side if you want the theory.
It is usually the LCP element: oversized files, missing fetchpriority, or lazy-loading on it delays the largest paint. Size it to the slot, serve WebP, add fetchpriority high, and never lazy-load it. Never. Lazy-loading the LCP element directly worsens your most important speed metric. Lazy-load below-the-fold images instead. img tags. Background images cannot be preloaded or prioritized by the browser's scanner, so they always start downloading later. 1280–1600px wide in WebP, typically 100–300 KB. Serve responsive variants via srcset so mobile does not download the desktop file. It tells the browser to start fetching that image immediately at high priority, before other resources. In our tests it saved 0.2–0.6s of LCP on hero images.Why is my hero image making my site slow?
Should hero images be lazy-loaded?
CSS background or img tag for heroes?
What size should a full-width hero be?
What does fetchpriority high do?
