How to Fix a Render-Blocking Hero Image in WordPress 6 Gutenberg

Why This Problem Happens In WordPress 6 Gutenberg

A render-blocking hero image in WordPress 6 Gutenberg is usually not caused by the Image block alone. The bigger issue is how that block delivers the image to the browser. If the hero image is oversized, inserted from an external URL, missing responsive markup, or delayed by lazy-loading and JavaScript, it can drag down Largest Contentful Paint.

Google's LCP guidance is clear on the main pattern: the browser needs to discover the LCP resource early, download it quickly, and render it without unnecessary delay. WordPress core also tries to help by adding `loading`, `fetchpriority`, and `decoding` attributes through `wp_get_loading_optimization_attributes()`, but those optimizations only work when the image output and context are correct.

For Gutenberg sites, the practical fix is to make sure the hero image is served from the Media Library, uses an appropriate generated size, is not lazy-loaded, and gets high fetch priority when it is the main above-the-fold image.

Quick Diagnosis Table

Symptom	Likely Cause	Best Fix
Hero image loads late in Lighthouse or PageSpeed Insights	Browser discovers image too late	Use Media Library image output, avoid JS injection, consider preload
Hero image is huge on mobile	Full-size file served instead of responsive variant	Use registered image sizes and proper `srcset`/`sizes`
Hero image has `loading="lazy"`	Theme, plugin, or custom filter overrides core behavior	Exclude the hero image from lazy loading
Image block uses external URL	WordPress cannot fully optimize attachment markup	Upload image to Media Library
LCP image finishes downloading but paints late	CSS, JS, or layout work delays rendering	Reduce blocking CSS/JS around the hero section

What WordPress Core Already Does

WordPress does more for images than many editors realize. The core `wp_get_attachment_image()` function generates image markup with width, height, and responsive attributes such as `srcset` and `sizes`. It also pulls in loading optimizations from core media logic.

According to the WordPress developer docs, that optimization layer may add:

`loading="lazy"` for non-critical images
`fetchpriority="high"` for the most important in-viewport image
`decoding="async"` for images

That matters because the browser should not receive both `loading="lazy"` and `fetchpriority="high"` on the same image. WordPress explicitly warns against that combination in its loading optimization documentation.

The catch is that these benefits are strongest when the image is treated as a real attachment image in WordPress. If your hero image is pasted in from an external URL or rewritten by a performance plugin or page builder layer, the browser may not get the markup it needs.

Fix The Image Block Delivery Path First

The safest first fix is to stop treating the hero image like an arbitrary file and let WordPress handle it as an attachment.

The WordPress Image block documentation notes that Gutenberg supports both Media Library images and externally inserted URLs. For performance, the Media Library route is better because it gives WordPress enough metadata to generate variants and responsive markup.

Use this checklist:

Open the page or template in the block editor.
Select the hero Image block.
If it was inserted from a URL, upload it to the Media Library.
Replace the block image with the uploaded attachment.
Choose an image size that matches the rendered layout instead of leaving a massive original file in place.

If the hero image is still being served at a much larger size than the layout needs, the page will pay the network penalty even if everything else is configured correctly.

A related internal reference worth reading is Web Image Performance in 2026, which explains why large image payloads remain one of the biggest Core Web Vitals bottlenecks.

Make Sure The Hero Image Is Not Lazy-Loaded

A hero image above the fold should usually load eagerly. Google's LCP guidance specifically warns against delaying the main image, and the Flux Plugins article above reaches the same conclusion for LCP-heavy pages.

WordPress core usually omits lazy loading for important in-viewport images, but themes and optimization plugins can override that behavior. Check the rendered HTML for your hero image. If you see this, it is a problem:

<img src="/uploads/hero.jpg" loading="lazy" fetchpriority="high" alt="...">

That combination is contradictory. WordPress core documentation for `wp_get_loading_optimization_attributes()` says an image should not be lazy-loaded and marked high priority at the same time.

If a plugin or theme forces lazy loading, exclude the hero image by class, ID, or context. If you control the image output in PHP, you can override attributes directly.

add_filter( 'wp_get_attachment_image_attributes', function( $attr, $attachment ) {
    if ( ! empty( $attr['class'] ) && str_contains( $attr['class'], 'hero-image' ) ) {
        $attr['loading'] = false;
        $attr['fetchpriority'] = 'high';
        $attr['decoding'] = 'async';
    }
    return $attr;
}, 10, 2 );

That filter is supported by the WordPress hook reference for `wp_get_attachment_image_attributes`.

Fix Responsive Sizing And File Weight

Even with the right priority hints, an oversized hero image can still hurt LCP. WordPress core recommends using registered image sizes rather than relying on the browser to shrink a huge original. The documentation for `wp_get_attachment_image()` explicitly says that using a registered size is more efficient than finding a larger image and scaling it down in the browser.

Focus on these fixes:

Serve a compressed WebP or AVIF version where your stack supports it
Use a registered hero size rather than the full upload
Preserve `width` and `height` so layout space is reserved
Verify that `srcset` and `sizes` are present in the final markup

A practical rule is simple: if your hero renders at 1440 pixels wide, do not send a 3200-pixel image to every visitor unless there is a real layout reason.

Check Whether CSS Or JavaScript Is Delaying Paint

Sometimes the image is discovered and downloaded on time, but it still paints late. That usually means the hero section is wrapped in a slider, animation, fade-in effect, or JavaScript-controlled layout.

Google's LCP optimization guide breaks LCP into discovery delay, resource load duration, and render delay. If the image request starts early but the element appears late, you are dealing with render delay rather than image discovery.

Common Gutenberg-era causes include:

Hero images inside carousel blocks
Hidden sections revealed after JavaScript runs
Heavy above-the-fold CSS
Background images used instead of normal image markup

If the hero is decorative, a background image can be fine. If it is the main LCP candidate, a normal `img` element is usually easier for the browser to prioritize correctly.

When To Add Preload

Preload is useful when the browser cannot discover the hero image early enough from the initial HTML. That can happen with background images, delayed template output, or theme logic that buries the image behind other work.

Use preload carefully:

Add it only for the actual above-the-fold hero image
Do not preload multiple competing images
Keep `fetchpriority="high"` aligned with the same resource

If the image block already outputs a normal attachment image near the top of the document, preload may not be necessary. Overusing preload can steal bandwidth from other critical resources.

Recommended Fix Order

Move the hero image into the Media Library if it came from a raw URL.
Use a properly sized attachment variant instead of the full original.
Confirm the final HTML includes `srcset`, `sizes`, `width`, and `height`.
Remove lazy loading from the hero image.
Ensure the hero image gets `fetchpriority="high"` only if it is the primary above-the-fold image.
Reduce CSS and JavaScript that delay hero rendering.
Add preload only if discovery is still late after markup fixes.

Conclusion

The cleanest way to fix a render-blocking hero image in WordPress 6 Gutenberg is to correct the media delivery path rather than fight the symptom. Let WordPress output the hero as a real attachment image, make sure it is not lazy-loaded, serve the right size, and avoid theme or plugin logic that delays paint.

In most cases, the winning combination is straightforward: Media Library image, responsive markup, eager loading for the hero, and lighter above-the-fold rendering. That aligns with both WordPress core image handling and Google's LCP guidance, and it fixes the problem at the layer that actually causes it.