Shopify Product Images in 2026: Formats Are Mostly Solved. Layout and Alt Text Are Not.

Key findings

1. On Shopify, 94.2% of product image files came back as WebP or AVIF. We asked for images the way a current browser does. AVIF showed up on 59.8% of pages (95% CI 52.9 to 66.4%).
2. WooCommerce is the opposite. 75.8% of image files on WooCommerce product pages came back as JPEG or PNG, and on 76.6% of pages the first-loaded image was JPEG or PNG (CI 66 to 84.7%, smaller sample of 81).
3. 42.6% of Shopify product pages have at least one first-loaded image with no width or height attribute (CI 35.8 to 49.6%). That is a layout-shift risk unless the theme reserves the space in CSS.
4. 1 in 5 Shopify product pages has a first-loaded image with no alt attribute at all (19.5%, CI 14.5 to 25.6%).
5. Heavy files are rare. The median image file on a Shopify product page is 42 KB. Only 3.1% of pages had a first-loaded image over 1 MB.

What we measured

For each store we picked one real product page and read its HTML the way a crawler sees it, without running JavaScript. For every image the HTML references, we asked the server for the file with the same Accept header a current Chrome sends (image/avif,image/webp,…) and recorded what came back: the format, from the Content-Type header, and the size, from Content-Length.

Two kinds of numbers appear below:

• Per file: every image file the page references, including each size variant listed in srcset. Useful for "what format do servers send".
• Per page: whether a page has at least one problem image. For layout, alt text and heavy files we only count first-loaded images: <img> elements with a src and no loading="lazy". These are the images a browser requests first, usually the main product photo.

We did not measure total page weight, which image a browser actually picks from a srcset, rendered image sizes, Largest Contentful Paint, images injected by JavaScript, or CSS background images. More in Limitations.

1. Image formats: Shopify has mostly solved this

That is 94.2% modern formats, and it does not look like 199 store owners each converted their images. 97.2% of those WebP and AVIF responses carried a Vary: Accept header, which means the server picked the format based on what the browser said it accepts. In other words, the platform's image CDN does this for every store, whether the owner uploaded a JPEG or not.

AVIF needs a caveat. In a follow-up spot check on 12 October 2026, we requested the main product image of 24 stores from the sample at 600px wide, telling the server we accept AVIF. 22 came back as WebP and 2 as JPEG; none as AVIF. AVIF only showed up on some small size variants, and not consistently. So read "AVIF on 59.8% of pages" as "at least one AVIF file somewhere on the page", not as stores choosing AVIF for their product photos.

The gap that is left is small but real: on 10.8% of Shopify pages (CI 7.2 to 15.9%) the first-loaded image still came back as JPEG or PNG. We stored only hashes of image URLs, so we cannot say where those files are hosted.

2. WooCommerce: still mostly JPEG and PNG

On 76.6% of WooCommerce pages (CI 66 to 84.7%) the first-loaded image was JPEG or PNG, and only 1 page in 81 served any AVIF. Only 17.6% of the WebP and AVIF responses we did get carried Vary: Accept. WordPress can serve WebP, but unless a plugin or CDN picks the format per browser, visitors get whatever file was uploaded.

This is a smaller sample (81 stores), so treat the exact percentages as rough. The direction is not in doubt. It was collected in two passes, 43 pages on 2026-09-22 and the rest on 2026-10-12 with a stricter robots parser; images were measured the same way in both.

3. Missing width and height

Without width and height, the browser does not know an image's shape until it loads, so the text below it can jump. Some themes prevent that with CSS (aspect-ratio or a fixed-ratio wrapper), so a missing attribute is a risk, not proof of layout shift. We read HTML only, so we cannot tell which themes cover it in CSS.

If lazy-loaded images are included, the Shopify figure rises to 55.3%. We keep the narrower first-loaded number as the headline, because lazy-loading markup can include <source> elements that never carry these attributes.

4. Missing alt attributes

We only counted images where the alt attribute is missing entirely. alt="" is the correct markup for a decorative image, so we counted it as present. Whether the existing alt text is any good is a separate question we did not try to answer. Including lazy-loaded images, the Shopify figure is 24.1%.

5. File sizes

These are sizes of individual files, including every size variant a page lists in srcset. A browser on a phone will not download the biggest variants, so do not add these up into a "page weight".

What to do with this

• On Shopify, format is not your problem. Check your theme's main product image for width and height attributes, and make sure product photos have alt text. Both are template fixes, done once. Shopify's own theme guidance recommends the image_tag Liquid filter, which adds both size attributes for you.
• On WooCommerce, serving WebP or AVIF is still the biggest easy win. A CDN or plugin that picks the format by Accept header fixes it for every image at once. Converting files before upload works too.
• Anywhere, check what your own pages actually serve before you trust a score. Open your product page in DevTools and look at the Content-Type of the main image, or scan the page with the free tool below.

How the sample was built

• Source: the HTTP Archive crawl of 1 September 2026 (mobile, root pages), filtered to e-commerce sites using the Wappalyzer "Ecommerce" category.
• Draw: a deterministic, seeded draw per platform with fixed quotas (200 Shopify, 100 WooCommerce, 100 other). Domains we had used while building our tools were excluded before the draw. A store that failed was replaced only from a pre-ordered reserve list, never by hand.
• Collected: 2026-09-22. One product page per store, chosen by a fixed ranking and confirmed to be a real product page, not a category or listing.
• Not completed: the WooCommerce group stopped at 50 of 100 stores and the "other platforms" group was not collected. We report Shopify and WooCommerce separately and never combine them. Shopify is about 19% of e-commerce sites in the source crawl, so none of this describes "all online stores".
• robots.txt: after the crawl we found that our collector's robots.txt parser was not fully standards-compliant (it ignored * and $ patterns and query strings). We re-checked every request we could reconstruct (376 domains, 462 origins) against each site's robots.txt with an RFC 9309 parser. We found 3 real violations, all on WooCommerce discovery requests, and removed those stores. We also removed every store whose robots.txt could not be read, and one site that turned out not to be a store. Two Shopify stores now block everything only because they closed after the crawl; we kept them.
• Final sample: 199 Shopify and 81 WooCommerce product pages.

Limitations

• Static HTML only. Images added by JavaScript and CSS background images are missing.
• Referenced, not downloaded. We fetched every candidate in srcset; a real browser picks one. That is why we publish per-file and per-page-presence facts, not page totals.
• First 40 image references per page. Long galleries are cut off.
• One product page per store. Other templates on the same store can differ.
• Sizes from headers. 2,790 of 2,863 Shopify sizes came from Content-Length on a HEAD request, the rest from a one-byte range request. Files with no size from either were left out, never counted as zero.
• Confidence intervals are 95% Wilson intervals on page-level shares. File-level shares have none, because files from the same page are not independent.
• robots.txt checks mostly used each site's file as of 12 October 2026, about three weeks after the crawl, because archived copies near the crawl date existed for only 6 of 462 origins.

FAQ

How to cite

Journalists and researchers: questions about the data or method are welcome at [email protected].