Why This Problem Happens
A largest contentful image delay in WordPress 6 Gutenberg usually means the browser is discovering, downloading, or rendering your main image too late. In practice, that often comes down to one of four issues: the hero image is lazy-loaded, WordPress cannot safely prioritize it, the file is heavier than it should be, or the block is inserted in a way that delays discovery.
Google’s LCP guidance breaks the metric into TTFB, resource load delay, resource load duration, and element render delay. That framing is useful here because Gutenberg image block problems are rarely about one checkbox alone. You need the image to appear early in the HTML, load with the right priority, use sensible dimensions, and arrive in an efficient format. WordPress core documentation also matters because WordPress 6 introduced stronger automatic loading optimizations for images, including `loading`, `decoding`, and `fetchpriority` behavior when the markup gives core enough context to act correctly.
What WordPress 6 Already Does
WordPress 6 uses loading optimization logic through `wp_get_loading_optimization_attributes()`. Core may add:
- `loading="lazy"` for non-critical images
- `fetchpriority="high"` for the most important in-viewport image
- `decoding="async"` for images
That sounds helpful, but there is an important catch. Core only makes good decisions when the image markup is complete and the image is actually eligible to be treated as the likely LCP element. The same documentation notes that an image should not be both lazy-loaded and marked with high fetch priority.
The WordPress Image block documentation also shows that Gutenberg images can come from the Media Library or from an external URL. That distinction matters. Images inserted from a URL or handled outside the normal media flow are more likely to miss the clean attachment metadata, responsive variants, and predictable markup that help WordPress optimize delivery.
How To Diagnose The Delay
Start by checking PageSpeed Insights or Lighthouse and confirm that the LCP element is actually the Gutenberg image block you suspect. Then inspect the final HTML for that image.
Use this quick checklist:
| Check | Good State | Bad State |
|---|---|---|
| Loading attribute | No `loading="lazy"` on the hero image | Hero image is lazy-loaded |
| Fetch priority | `fetchpriority="high"` on the main above-the-fold image | No priority hint on the likely LCP image |
| Dimensions | Explicit `width` and `height` are present | Missing intrinsic dimensions |
| Source | Media Library image with generated responsive sizes | Hotlinked or manually inserted image URL |
| File size | Compressed WebP or AVIF where appropriate | Large JPEG or PNG hero image |
| Discovery | Image is in the initial HTML | Image is injected late by JS or hidden in a slider |
If the image fails two or more of those checks, you likely found the cause of the delay.
Fix Lazy Loading On The LCP Image
The most common mistake is lazy loading the image that is supposed to become the largest contentful paint element. Google explicitly advises against lazy loading LCP images in its LCP optimization guidance, because that increases resource load delay.
In WordPress 6, core tries to avoid lazy loading the most important early content image. But that logic can be undermined when:
- a performance plugin rewrites image attributes
- a theme outputs custom image markup
- the image appears inside a slider, cover pattern, or conditional block
- the block is transformed or filtered after WordPress assigns attributes
If your hero image still shows `loading="lazy"`, remove it for that image. The cleanest fix is to ensure the hero image is a normal above-the-fold Image block from the Media Library and not an injected or transformed element. If a plugin forces lazy loading globally, exclude the hero section or LCP image from that rule.
Make Sure WordPress Can Assign High Fetch Priority
WordPress can add `fetchpriority="high"`, but only when it can confidently identify the image as important. According to the core function documentation, width and height are part of the decision path. If those are missing, optimization logic may bail out early.
To improve fetch priority handling:
- use a standard Gutenberg Image block instead of a raw custom HTML image where possible
- keep the hero image in the initial viewport
- make sure the rendered image has `width` and `height`
- avoid wrapping the image in components that hide it initially
If WordPress still misses the right image, you may need a theme-level override so the actual hero image receives high fetch priority. That should be done carefully, because high priority is meant for the single most important above-the-fold image, not every image near the top.
Reduce File Weight Without Breaking The Layout
If discovery is fine but the download is still slow, the issue shifts to resource load duration. That is usually a file format, compression, or responsive sizing problem.
A useful reference here is this Flux Plugins article on web image performance, which summarizes how modern formats affect transfer size and LCP. The practical takeaway matches broader web performance evidence:
- use WebP or AVIF for photographic hero images when quality holds up
- avoid oversized PNGs for photos
- do not serve a much larger source than the rendered slot needs
- make sure responsive image candidates are available
For a WordPress 6 Gutenberg page, that means uploading the image into the Media Library, letting WordPress generate intermediate sizes, and using the block normally so `srcset` and `sizes` can do their job. If you paste in a giant original and force it to display smaller with CSS alone, you are paying for bytes the user never needs.
Avoid Block Configurations That Delay Discovery
Some Gutenberg layouts look fine visually but still harm LCP because the browser discovers the image too late or cannot render it immediately.
Watch for these patterns:
- hero images inside sliders or carousels
- images hidden behind tabs, accordions, or animation gates
- images loaded from external URLs instead of the Media Library
- CSS background images used where a real `img` element would be better
- JavaScript swapping the source after load
Google’s LCP documentation warns that a large gap between FCP and LCP often means the LCP resource was not immediately available to the browser. That is exactly what happens when the hero image is buried in behavior-heavy components.
If the image is truly the main content, use a direct image element in the initial markup. In Gutenberg, a plain Image block is usually safer than a complex interactive wrapper.
Confirm The Image Block Markup Is Healthy
The Gutenberg Image block itself is not inherently the problem. The problem is usually how it is used.
A healthy hero image block should end up with markup that includes:
- a normal `img` element
- a valid `src`
- responsive `srcset` and `sizes` when available
- `width` and `height`
- no lazy loading on the LCP image
- high fetch priority when it is clearly the main above-the-fold image
If your current block does not render that way, rebuild the block instead of endlessly patching around it. Replace hotlinked images with local Media Library assets. Reinsert the image block if an old pattern or block transform stripped useful metadata.
Recommended Fix Order
Follow this order so you solve the biggest bottlenecks first:
- Identify the actual LCP element in PageSpeed Insights or Lighthouse.
- Remove lazy loading from that image if it appears.
- Ensure the image is a standard Gutenberg Image block from the Media Library.
- Confirm `width` and `height` are present in the rendered HTML.
- Check whether WordPress assigns `fetchpriority="high"`.
- Compress or convert the file to WebP or AVIF when appropriate.
- Verify the image is not hidden by sliders, tabs, or JS-driven effects.
- Re-test on mobile, because image-related LCP failures are often worse there.
When A Theme Or Plugin Is The Real Cause
Sometimes WordPress core is doing the right thing, but the theme or optimization plugin overrides it later.
Common conflicts include:
- blanket lazy loading rules
- image CDN rewrites that strip attributes
- page builder sections that replace `img` with background images
- performance plugins that defer or transform above-the-fold media too aggressively
If you see correct markup in the editor but incorrect markup on the front end, the conflict is downstream from Gutenberg. In that case, test with the offending optimization feature disabled, then add a narrow exclusion for the hero image rather than disabling the whole plugin stack.
Conclusion
To fix largest contentful image delay caused by a WordPress 6 Gutenberg image block, focus on the real bottleneck: make the hero image discoverable early, do not lazy load it, give WordPress enough markup to apply fetch priority correctly, and keep the file lean enough to download fast. In most cases, the best fix is surprisingly simple: use a normal Media Library-based Image block for the above-the-fold image, preserve intrinsic dimensions, and avoid any plugin or theme behavior that treats your hero image like offscreen media.
Once that is in place, rerun PageSpeed Insights and confirm that both the LCP element and its load timing improved. That is the signal that you fixed the underlying delivery path rather than just moving the delay somewhere else.