WooCommerce 11.0 removes the Product Image block Resolution attribute and relies on responsive image output. A correct visual result can still download an oversized source, choose a poor sizes candidate, shift during variation changes, or delay the largest contentful paint image.
Use this for block themes, custom Product Image block filters, product gallery extensions, variation galleries, CDN image optimization, and stores with LCP or mobile bandwidth concerns.
Quick answer
WooCommerce 11.0 Product Image Resolution Attribute Responsive Test should be handled with a narrow evidence-first workflow: record current image evidence, test viewport matrix, exercise variations, then verify the result before making broader changes.
What to check first
- Capture the Product Image block markup, chosen currentSrc, rendered dimensions, bytes, and LCP timing before the update.
- Test WooCommerce 11.0 at mobile, tablet, desktop, and a high-density viewport with cache disabled once.
- Switch product variations and gallery images while watching srcset, sizes, layout shift, and duplicate downloads.
- Remove code that reads or writes the retired Resolution attribute and use supported responsive image filters only when needed.
- Warm CDN cache and repeat the test with real compression, lazy-loading, and above-the-fold behavior.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Record current image evidence | Capture the Product Image block markup, chosen currentSrc, rendered dimensions, bytes, and LCP timing before the update. | The browser chooses an appropriately sized source at every tested viewport. |
| Test viewport matrix | Test WooCommerce 11.0 at mobile, tablet, desktop, and a high-density viewport with cache disabled once. | The primary product image has stable dimensions and an intentional loading policy. |
| Exercise variations | Switch product variations and gallery images while watching srcset, sizes, layout shift, and duplicate downloads. | Variation changes update src, srcset, sizes, dimensions, and alt text together. |
| Remove retired attribute use | Remove code that reads or writes the retired Resolution attribute and use supported responsive image filters only when needed. | No obsolete Resolution attribute dependency remains in blocks, patterns, or extension code. |
Why this usually happens
- The browser chooses a srcset candidate from the sizes value, not from the image's visible appearance alone.
- A custom block transform can preserve an obsolete attribute without changing output.
- Variation gallery scripts may replace src but leave stale srcset or dimensions.
- Lazy loading the primary above-the-fold product image can hurt LCP even when other images should stay lazy.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
const img = document.querySelector('.wc-block-components-product-image img');
console.table({
currentSrc: img?.currentSrc,
rendered: `${img?.clientWidth}x${img?.clientHeight}`,
natural: `${img?.naturalWidth}x${img?.naturalHeight}`,
loading: img?.loading,
sizes: img?.sizes
});
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Record current image evidence
- Test viewport matrix
- Exercise variations
- Remove retired attribute use
- Retest through CDN
What to tell the client or owner
Share viewport, DPR, rendered size, currentSrc, transfer bytes, LCP, layout shift, variation action, CDN status, and extension owner.
Production verification checklist
- The browser chooses an appropriately sized source at every tested viewport.
- The primary product image has stable dimensions and an intentional loading policy.
- Variation changes update src, srcset, sizes, dimensions, and alt text together.
- No obsolete Resolution attribute dependency remains in blocks, patterns, or extension code.
Mistakes to avoid
- Do not judge the fix by one browser or the homepage only.
- Do not delete evidence before recording usernames, file paths, timestamps, and response headers.
- Do not add a cache, security, or tracking plugin while the original problem is still unclear.
- Do not leave test users, temporary debug logs, or broad API keys active after verification.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, malware risk, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, test WooCommerce product image performance.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references