srcset and sizes Measured: Which File Chrome Downloads on 3 Screens

The question: how many bytes does srcset actually save, and how much does it matter whether the sizes attribute is correct? We served one photo three ways, as a single large file, as srcset without sizes, and as srcset with a sizes value that matches the layout, and recorded which file Chrome downloaded on a phone, a tablet and a desktop screen.

The test

The image is the CC0 desert dunes photo from our corpus, cropped to 16:9 and encoded as WebP quality 75 at five widths:

It sits in a plain article column that is 728 CSS pixels wide on large screens and the full width minus 32 pixels of padding on small ones, similar to a typical blog article layout. The three variants differ only in markup:

• Single file: src="desert-2400.webp", no srcset.
• srcset, no sizes: all five widths in srcset, no sizes attribute. The browser then assumes the image is as wide as the viewport (100vw).
• srcset with sizes: the same list plus sizes="(max-width: 792px) calc(100vw - 32px), 760px", which describes the column.

Each variant was loaded three times per viewport in a fresh Chrome 154 profile: mobile 390 × 844 at 3× density, tablet 768 × 1024 at 2× and desktop 1440 × 900 at 1×. The file choice was identical in all three runs of every combination.

Which file did Chrome download?

The single 2400-pixel file cost 140 KB on every device. With srcset, the desktop browser downloaded the 768-pixel file (16 KB) when sizes was correct, but the 1600-pixel file (64 KB) when sizes was missing. A missing sizes attribute quadrupled the download on desktop: the browser assumed a 1440-pixel-wide image for a 728-pixel column.

On the phone and the tablet, both srcset versions chose the same 1600-pixel file. At 3× density, a 358-pixel column needs 1,074 device pixels, and at 2× a 736-pixel column needs 1,472, so the 1600-pixel candidate is the first one big enough in either case. Here the missing sizes happened to cost nothing, because the viewport and the column were almost the same width.

What surprised us

We expected the correct sizes to matter most on phones. It mattered most on desktop, where the gap between the viewport width and the content column is largest. The phone downloaded the most bytes of all (64 KB for a 358-pixel-wide image) purely because of its 3× screen. If that is too much for your audience, the fix is to cap the density you serve (see our high-DPI test), not to change sizes.

Load time barely changed in this test because we used a fast connection. What we measured here is bytes: 124 KB saved per desktop page view for one image, compared with the single large file. On a slow connection those bytes turn into time, as our lazy-loading test shows.

How to write sizes from your layout

1. Measure the image’s rendered width at a few viewport widths (DevTools, or img.getBoundingClientRect().width).
2. Write one media condition per layout change, from narrowest to widest, and end with the fixed width. For a centred column with 16 pixels of padding and a 760-pixel maximum: (max-width: 792px) calc(100vw - 32px), 760px.
3. Check the choice: open DevTools, select the image and read currentSrc at each viewport. The tables above were produced from exactly that property.
4. For lazy-loaded images, modern Chrome also accepts sizes="auto", which uses the real layout width. We tested how WordPress uses this in our WordPress size audit.

Practical conclusion

• Any srcset beat the single large file: 54 % fewer bytes on phones, 89 % fewer on desktop with a correct sizes.
• A missing or lazy sizes value (the implicit 100vw) wastes the most on wide screens with narrow content columns: four times the bytes in our desktop case.
• Offer a candidate close to each common need: here 768 px (desktop 1×), 1600 px (phones at 3×, tablets at 2×). Extra candidates in between are only useful if they are actually chosen.

How this connects to our other tests

The bytes saved here add up with the other results in the lab. The 1600-pixel file a phone downloaded was WebP at quality 75; our format comparison found that AVIF needed about 29 % fewer bytes than JPEG at equal quality, so a correctly sized AVIF candidate would save more on top. Our high-DPI test explains why the phone needed such a large file in the first place: at 3× density, a 358-pixel column needs over a thousand device pixels to look sharp. And for WordPress sites, our size audit found the same desktop problem in real WordPress markup, with the same fix.

Repeat this test on your own images

To check which candidate your own page downloads, open it in Chrome, enable device emulation in DevTools, pick a phone, reload with the cache disabled, then select the image in the Elements panel and type $0.currentSrc in the console. Repeat with a tablet and a desktop size. If the desktop downloads a much wider file than the column it fills, your sizes value is missing or too generous. Our srcset builder writes the markup, and the loading script run_loading.mjs in our archive automates the three-device check with Playwright. One more check worth doing: measure the image’s real width at each breakpoint with $0.getBoundingClientRect().width, and compare it with what your sizes rule claims. In our test the difference between 728 pixels and the default 1,440 was what multiplied the desktop download by four.

Limitations

One photo, one layout and one browser. Chrome may pick a smaller cached candidate or a lower-density one in data-saver mode, which we did not test. Browsers are allowed to choose differently for the same markup; Safari and Firefox were not measured.

Data and files

Download loading-srcset.csv (9 rows, 1.4 KB) · Method: testing methodology. Photo: image credits.