Test responsive images on product pages: srcset, sizes and correct thumbnails

A short, practical checklist you can run in your browser and CMS to confirm product images use srcset and sizes correctly — and to spot oversized downloads on phones or retina displays.

Editorial illustration: a pale mint background with an off-white browser card showing a product image area and a tablet and printed thumbnails beside it, using navy and teal accents to imply testing across sizes.

If your product pages still download 2,000+px files on phones, you need a repeatable test that shows which image the browser actually requested and whether that file is unnecessarily large for the displayed slot. This guide gives a clear checklist you can run in DevTools, how to compare the requested file to the rendered size (including DPR/retina), and the CMS actions (register sizes, regenerate thumbnails, clear caches) to fix common failures.

Contents

Prepare tools and choose a product page

Open a representative product page in a modern browser (Chrome, Edge or Safari). You need the Elements and Network panels in DevTools. Disable caching in DevTools while testing so the browser actually requests the chosen candidate each reload. Prepare a few viewport widths (mobile, tablet, desktop) and be ready to toggle device pixel ratio (DPR) emulation for retina tests.

This workflow follows the browser-side selection rules in the HTML spec and the guidance WordPress gives on core responsive-image support — useful background reading is the W3C srcset & sizes spec and WordPress’s responsive images documentation (developer.wordpress.org/apis/responsive-images).

Inspect the markup: picture, img, srcset and sizes

In DevTools’ Elements panel, find the product’s main image and gallery thumbnails. Look for either a <picture> element with <source> children or an <img> element that has a srcset and (optionally) a sizes attribute. Record three things for each visible image slot:

  • The fallback src URL (single-image fallback).
  • The srcset list of candidate URLs and their width descriptors (e.g. image-800.jpg 800w).
  • The sizes attribute value (if present) which tells the browser the expected slot width at different breakpoints.

WordPress core will add srcset and a default sizes attribute for many themes; see WordPress responsive images and the helper functions such as wp_get_attachment_image_srcset() and wp_image_add_srcset_and_sizes() if you or a developer are checking theme templates.

Observe which image the browser requested

Switch to the Network panel, filter by Img (or keep network visible) and reload the page for each viewport width / DPR combination you test. Note the exact image file the browser requested (the request URL). Then inspect the response (or the filename convention) to determine the intrinsic pixel width of that file.

Compare the requested file’s intrinsic pixel width with the image’s rendered display width (in CSS pixels) multiplied by DPR. For example, if the image displays at 300px CSS width on a DPR=2 device, an appropriate 2x candidate would be ~600px intrinsic width. If the browser requested a 2,400px file for that 300px slot at DPR=2, that’s an oversize download and worth fixing.

This selection behaviour follows the W3C srcset/sizes semantics and is the practical observation you need to interpret the values in srcset and sizes.

Test DPR / retina behaviour

In DevTools toggle device emulation and change Device Pixel Ratio (DPR) to 1, 2 and (if you like) 3. Reload at each DPR so the browser re-evaluates srcset selection. Confirm that higher‑density candidates (2x/3x where present) are available in srcset and are selected on higher DPRs. If srcset lacks candidates that match the device’s required pixel density, the user agent will choose the closest available candidate per the W3C srcset/sizes selection algorithm; if that nearest candidate happens to be a very large original file it can increase downloads on high‑DPR devices. To avoid this, add or generate appropriately sized higher‑density variants (2x/3x) or emit accurate sizes rules so the browser can pick a nearer‑sized candidate — see the WordPress responsive images guide.

WordPress and themes often generate only a set of intermediate widths; if those widths don’t include useful 2x candidates for your slot widths you should add or generate suitable sizes (see the CMS steps below).

Map CMS-generated image sizes and candidates

On WordPress/WooCommerce sites, inspect the attachment metadata to see which intermediate sizes exist (the Media Library item or the uploads folder contains that information). Compare those generated widths with the candidates listed in the page’s srcset. If a size you need is missing, register it (for themes: add_image_size() or via your theme’s image-width settings) so WordPress will generate matching derivatives on upload.

Useful developer docs: WordPress responsive images overview (developer.wordpress.org/apis/responsive-images) and how WordPress builds srcset (wp_calculate_image_srcset()).

Fix missing/incorrect sizes output in your theme

If sizes is absent or doesn’t reflect your CSS layout, the browser may choose an unnecessarily large candidate. Calculate the CSS slot width of the image at your breakpoints (for example: the product gallery column might be 100vw on small screens, 50vw on tablet, 33.3vw on desktop). Convert those slot widths into a sizes string matching your breakpoints and have the theme emit it (either by editing the template where the image is output or by using WordPress filters such as wp_calculate_image_sizes).

WordPress documents how themes can control these values; see responsive images and the function references for filters that let developers supply correct sizes.

Regenerate thumbnails and clear CDNs/image proxies

After you register new image sizes or change theme image-width settings, regenerate thumbnails so the new intermediate files actually exist (use a thumbnail-regeneration plugin or WP‑CLI). If you serve images through a CDN or an image-optimization proxy, clear its cache or follow the provider’s steps to re-sync derived images so the CDN will serve the new sizes.

WooCommerce’s documentation discusses regenerating thumbnails and checking theme image widths; see Adding product images and galleries and the theme image-widths guidance (set-theme-product-image-widths).

Repeat for thumbnails, gallery & variation images; run Lighthouse

Repeat the inspection for catalog thumbnails, gallery images and variation images — each slot can have different CSS widths and therefore different ideal candidates. Run Lighthouse or PageSpeed to surface responsive-image opportunities; its results point to images that are larger than the rendered size and show the potential savings.

Google’s guidance on image selection and responsive markup is helpful background: Google Images & responsive images.

Fictional example (labelled)

Fictional example: Imagine a shop’s product detail page shows its hero image at 360px CSS width on phones. DevTools showed the requested file was image-original-2400.jpg (2,400px). The srcset only listed 2400w and 1600w candidates, and sizes was missing. After adding a 720w and 480w generated size, emitting a sizes string that matched the CSS slot (“(max-width: 600px) 100vw, 50vw”), regenerating thumbnails and clearing the CDN cache, phones began requesting the 480w file (or 960px file on DPR=2). This reduced the bytes downloaded for that slot substantially. (This is an illustrative example; run the DevTools checks above on your site to confirm.)

Next action

Run this short checklist on one important product page now. The observable goal: at a chosen mobile viewport and DPR, the Network panel should show a requested image file whose intrinsic pixel width is close to your displayed CSS width × DPR, not several times larger.

  • Open the product page, disable DevTools cache, set mobile width & DPR, reload.
  • Record the requested image file (Network) and its intrinsic pixel width.
  • Measure the CSS display width (Elements) and compute display_width × DPR.
  • If requested_width > ~1.5 × (display_width × DPR), investigate srcset/sizes and CMS-generated sizes.
  • Register missing image sizes, update sizes output, regenerate thumbnails, clear caches, and re-test.

Related practical reads from this site: Optimize product image filenames, captions and image sitemaps and Improve product‑page LCP and image performance without re‑shooting photos.