Why This Happens In WooCommerce 10
A render-blocking hero image on a WooCommerce 10 product page usually is not caused by the image file alone. More often, it comes from how the first product image is delivered inside the gallery: the main image is wrapped in WooCommerce gallery markup, then enhanced by JavaScript for thumbnails, zoom, and pop-up behavior. WooCommerce documents that the gallery uses a larger viewer plus thumbnails, and that structure matters because only the first visible viewer image should be treated as critical, not the whole gallery (Product Gallery block).
WordPress core also matters here. Since WordPress 6.3, core can automatically add `fetchpriority="high"` to the image it believes is the LCP image, and it avoids combining that with `loading="lazy"` because that combination is a performance anti-pattern (WordPress 6.3 image performance note). If your theme, optimization plugin, or a WooCommerce gallery customization overrides that behavior, the first product image can load too late and show up in audits as a render-blocking or delayed hero image.
Quick Diagnosis
Use this table before changing code.
| Check | What You Want To See | Why It Matters |
|---|---|---|
| Main product image | Loaded in initial HTML | Prevents JS-only discovery delay |
| `loading` attribute | `eager` or omitted on the first visible image | LCP images should not lazy-load |
| `fetchpriority` attribute | `high` on the first visible image only | Tells the browser this image matters most |
| Gallery thumbnails | Can stay lazy | They are not the hero image |
| Image format | WebP or AVIF where supported | Reduces transfer size |
| Image dimensions | Realistic for the product layout | Oversized files delay paint |
If you want background on why image delivery choices matter so much for Core Web Vitals, this overview from Flux Plugins is a useful companion reference on formats, compression, and LCP behavior (web image performance).
Fix The First Gallery Image First
WooCommerce’s single-product image template renders the main image first and then outputs the rest of the thumbnails through gallery hooks (WooCommerce product-image.php code reference). That means your fix should target the first visible product image, not every gallery asset.
A practical fix is to force the main product image to load eagerly and receive high fetch priority on single-product pages:
add_filter( 'wp_get_attachment_image_attributes', function( $attr, $attachment, $size ) {
if ( ! is_product() ) {
return $attr;
}
if ( empty( $attr['class'] ) || strpos( $attr['class'], 'wp-post-image' ) === false ) {
return $attr;
}
$attr['loading'] = 'eager';
$attr['fetchpriority'] = 'high';
$attr['decoding'] = 'async';
return $attr;
}, 10, 3 );This works with WordPress instead of fighting it. Core’s loading optimization system is designed to manage `loading` and `fetchpriority` consistently, and the official dev note is explicit that the same image should never be both `loading="lazy"` and `fetchpriority="high"` (WordPress 6.3 image performance note).
What Not To Do
- Do not set every gallery image to `fetchpriority="high"`.
- Do not disable lazy loading sitewide just to fix one product template.
- Do not preload every variation image.
- Do not rely on a slider script to inject the first visible image after page load.
Those changes usually make bandwidth competition worse and can hurt LCP instead of helping it.
Keep The Gallery Interactive Without Delaying LCP
WooCommerce’s gallery supports zoom, thumbnails, and modal behavior for product media (Adding product images and galleries). Those features are fine, but they should enhance an already visible main image rather than gate it.
If your theme or plugin rewrites the product gallery into a carousel, check these common failure points:
- The first image is hidden with CSS until the slider initializes.
- The first image is replaced by a placeholder and swapped in later with JavaScript.
- A lazy-load plugin adds `loading="lazy"` or `data-src` to the visible hero image.
- The gallery script waits on non-critical assets before revealing the viewer.
The safest pattern is simple:
- Render the first product image in HTML.
- Let it load eagerly.
- Let thumbnails and off-screen gallery items lazy-load.
- Attach zoom, pop-up, and slider behavior after the first paint.
That aligns with WordPress’s own lazy-loading guidance. The WordPress 5.9 performance note explains that in-viewport images should not be lazy-loaded and that skipping lazy loading for the first likely viewport image improves LCP substantially (Enhanced lazy-loading performance in 5.9).
Reduce The File Weight Of The Hero Image
Even with the right priority hints, a huge product image can still delay rendering. WooCommerce recommends high-quality product images and notes that the main single-product image is reused in multiple contexts, so starting with the right source asset matters (Adding product images and galleries).
For most stores, the best cleanup steps are:
- Export the main product image to WebP or AVIF when your stack supports it.
- Keep the displayed dimensions close to the actual layout size.
- Avoid serving a massive PNG or original camera upload as the hero image.
- Make sure `srcset` and `sizes` are not overridden by a theme in a way that forces oversized downloads.
If your catalog relies on detailed photography, compress carefully rather than blindly shrinking dimensions. The biggest gains usually come from format choice and sane sizing, not from making product photos visibly soft.
Validate The Fix In DevTools And PageSpeed Insights
After the change, test one representative product page and verify:
| Validation Step | Pass Condition |
|---|---|
| View page source | Main product image exists in HTML |
| Inspect image element | First visible image has `fetchpriority="high"` |
| Inspect image element | First visible image does not have `loading="lazy"` |
| Network panel | Hero image starts early, before most gallery extras |
| Performance audit | LCP element is the main product image and loads sooner |
If the page still fails, the remaining issue is usually outside WooCommerce itself:
- a theme override of `single-product/product-image.php`
- a performance plugin forcing lazy loading onto all images
- a CDN optimization layer rewriting image markup
- slider CSS hiding the gallery until initialization
Conclusion
The clean fix for a render-blocking hero image caused by the WooCommerce 10 product gallery is to treat only the first visible product image as critical. Load that image eagerly, give it `fetchpriority="high"`, keep the rest of the gallery lazy, and shrink the file with a modern format where possible. That approach matches WooCommerce’s gallery structure, follows WordPress core’s image-loading guidance, and avoids the common mistake of turning the whole gallery into a high-priority download queue.