Oversized Images Despite srcset: Getting sizes Right

Selection happens in three steps. First, the browser goes through the list in sizes from left to right and takes the first media condition that matches; the entry without a condition at the end applies if none matches (MDN Web Docs). This width is the space the image gets in the layout. Next, it divides every w descriptor in srcset by that width. With a space of 400 pixels, 800w becomes an effective density of 2. Finally, it compares these densities with the pixel density of the device and loads the file that fits most closely.

Because the first matching condition wins, order matters. MDN puts it plainly: the browser ignores everything after the first matching condition (MDN Web Docs). If you write (min-width: 576px) 50vw before (min-width: 1200px) 300px, desktop gets half the window width, because the first condition matches there as well. With min-width, the widest condition goes first; with max-width, the narrowest.

The following table works this through for a listing tile with a srcset of four steps: 400, 600, 1000 and 1600 pixels. It is a worked example; the browser may decide differently in individual cases, as the next section shows.

Pixel density is the part many underestimate. A file twice as wide has four times as many pixels, and the file size grows with it. In the MDN example, the same motif weighs 93 KB at 640 pixels wide and 39 KB at 320 pixels (MDN Web Docs). That is why sizes matters so much on high-resolution smartphones: every error in the stated width is multiplied by the pixel density, and a small slip in the markup turns into a much larger file.

The standard leaves the browser room to choose. Besides pixel density, it may take zoom level and network conditions into account (HTML Living Standard), and the actual selection step is explicitly left to the implementation (HTML Living Standard). In practice, this means: if a larger version of the same image is already in memory, the browser may reuse it. In a test with Chrome, a lazy-loaded image with sizes="auto" loaded the large file in most runs, because the same motif appeared further up without sizes and had already loaded the large version; on its own, the same image loaded the matching small file. A missing sizes in one place can therefore drag a second place along with it.

A matching sizes does not come from trial and error but from the grid of the template. At each breakpoint, you need four values: the column count, the gap between columns, the side margin and the maximum width of the content area. Together they give the width of one column, and exactly this width goes into sizes as an expression. If you already group your pages by template, as described in the article template performance beyond the home page, you almost have the list of image slots together. For a listing tile, the result looks like this:

Two details make the difference. First, sizes may be slightly larger than the real width, but not much smaller: a value that is too small leads to a file the browser upscales, and the image looks blurry. The Almanac explicitly calls sizes a hint where a little inaccuracy is fine (Web Almanac 2024). Second, an expression with calc() follows the window smoothly, while a fixed pixel value is inevitably too large or too small between two breakpoints. Fixed values are therefore mainly suited to widths above the maximum container width.

For Shopware themes, this means: the values for the listing tile sit in a Storefront template that a custom theme can override. Whoever changes the grid adjusts these values in the same step instead of inheriting them from the default. Further levers in the theme are summarized on the Shopware performance page.

For images outside the first screen there is now a shortcut. With sizes="auto", the browser takes the width from the computed layout instead of reading it from a list; this only applies to images with loading="lazy" (Web Features Explorer). The HTML standard requires auto to be the first entry and allows a fallback list after it for browsers without support (HTML Living Standard). Without width and height or a width in CSS, such an image will likely render at 300 × 150 pixels (HTML Living Standard).

According to MDN browser-compat-data, auto is supported in Chrome from version 126, in Firefox from version 150 and in Safari from version 27, there with a limitation for SVG images with object-fit (MDN browser-compat-data). Some overview pages still list Safari without support; with a fallback list, the difference does not matter in practice, because older versions read the list after auto. For the LCP image, auto does not help, because it should not load lazily; it still needs an explicit list. The Almanac recommends exactly this: fix critical images and use auto for deferred images (Web Almanac 2024). How this looks in the thumbnail strip of a product page is also covered in the article on the product gallery.

A matching sizes saves transfer without making any image look worse. How much depends on the starting point. By the Almanac estimate, a quarter of desktop pages using w descriptors load 180 KB or more in excess, while at least half of these pages load nothing in excess (Web Almanac 2024). Whether your shop belongs to the first or the second group is shown by a measurement per template.

The fix has limits where the problem is not the width. Format and compression are a separate matter; more on that in the article on WebP and AVIF. Nor does sizes change the loading order: an LCP image that is discovered late or loaded lazily stays late, even if the file is small. And whether the improvement reaches real visitors only shows in field data, for example in the Core Web Vitals report in Search Console.

In an image optimization project, we follow exactly this path: we list the image slots per template, measure loaded against needed width at several window widths and pixel densities, derive sizes from the grid and measure again afterwards. In Shopware shops, we adapt the theme templates for this. If you first want to know where your shop stands, it starts with an analysis of the most important templates. Which metrics matter here is explained on the Core Web Vitals page.