Top: mean WebP file size at each quality number, where the 2x line sits well above the 1x line the whole way. Bottom: mean SSIM against the same 512 pixel reference, where the 2x line crosses the 1x quality 80 target somewhere between quality 30 and 40. The distance between those two facts is the article: the 2x asset does reach the same picture, and it spends more bytes getting there. Charts generated from the measurement run described below.
The trick you hear is to serve a 2x image at a low quality number and let the browser shrink it, because downscaling hides the artifacts. It does hide them, and the file is still bigger. Matched on what the viewer actually sees, the 2x path costs a third more bytes and never once came out ahead.
The advice turns up in every performance thread. Serve a 2x image, set the quality number low, and let the browser downscale it. The downscale averages away the compression artifacts, so you get a sharp picture from a cheap file.
Half of that is true. The downscale really does hide the artifacts. So I measured whether the file is actually cheaper, and on eight gallery images it never was.
The display box is 512 pixels wide. That is the fixed thing. Everything below is a question about what to put in it.
Path A, the 1x asset: resize the source to 512 pixels with Lanczos, encode at quality q, decode, score.
Path B, the 2x asset: resize the source to 1024 pixels with Lanczos, encode at quality q, decode, then resize the decoded image down to 512 with Lanczos, which is what a browser does when it drops a 2x asset into a 1x box, and score that.
Both paths are scored against the same 512 pixel Lanczos reference with SSIM over 11x11 Gaussian windows, sigma 1.5, the standard Wang et al. formulation, on the luma channel. Eight source images, JPEG and WebP, sixteen quality settings from 5 to 95.
512 encodes. No cherry picking, no per image tuning.
| Quality | WebP 1x KB | WebP 2x KB | 1x SSIM | 2x SSIM | JPEG 1x KB | JPEG 2x KB | 1x SSIM | 2x SSIM |
|---|---|---|---|---|---|---|---|---|
| 40 | 16.6 | 41.8 | 0.95325 | 0.97925 | 23.2 | 66.7 | 0.94688 | 0.98518 |
| 50 | 18.7 | 47.5 | 0.95932 | 0.98219 | 26.6 | 76.7 | 0.95537 | 0.98871 |
| 60 | 20.9 | 53.5 | 0.96470 | 0.98460 | 30.2 | 87.3 | 0.96218 | 0.99092 |
| 70 | 23.5 | 60.1 | 0.96949 | 0.98664 | 35.6 | 103.5 | 0.96991 | 0.99309 |
| 75 | 24.9 | 64.1 | 0.97180 | 0.98762 | 38.9 | 113.8 | 0.97386 | 0.99401 |
| 80 | 29.9 | 77.5 | 0.97771 | 0.99006 | 44.0 | 129.9 | 0.97850 | 0.99517 |
| 85 | 36.6 | 96.8 | 0.98307 | 0.99237 | 51.0 | 152.6 | 0.98315 | 0.99601 |
| 90 | 46.9 | 131.4 | 0.98817 | 0.99454 | 62.7 | 192.5 | 0.98832 | 0.99689 |
| 95 | 65.9 | 202.1 | 0.99243 | 0.99613 | 87.5 | 279.3 | 0.99370 | 0.99761 |
The 2x column is roughly two and a half to three times the bytes at every setting, and it scores higher everywhere. Neither of those is surprising and neither of them answers anything, because the two columns are not two ways of doing the same job. They are two different pictures.
Any comparison that holds the quality number fixed across two different source resolutions is comparing quality targets, not encoding strategies. The number 80 does not mean the same thing when there are four times as many pixels underneath it.
Here is the honest version. Take the SSIM that the 1x asset achieves at quality 80, which is the setting most galleries actually ship. Then walk the 2x ladder down until you find the cheapest file that still reaches that score after the browser shrinks it.
| Image | 1x q80 KB | Target SSIM | 2x needs | 2x KB | Extra bytes |
|---|---|---|---|---|---|
| 00006 | 28.1 | 0.97885 | quality 35 | 35.6 | 26.88 percent |
| 00010 | 27.1 | 0.98053 | quality 40 | 35.9 | 32.86 percent |
| 00012 | 36.3 | 0.97341 | quality 40 | 50.4 | 39.01 percent |
| 00015 | 33.3 | 0.97738 | quality 40 | 46.7 | 40.29 percent |
| 00022 | 29.2 | 0.97845 | quality 40 | 43.9 | 50.49 percent |
| 00027 | 28.5 | 0.98122 | quality 35 | 37.1 | 30.15 percent |
| 00029 | 16.2 | 0.97834 | quality 40 | 19.8 | 22.23 percent |
| 00032 | 40.9 | 0.97351 | quality 35 | 54.5 | 33.37 percent |
| Total | 239.5 | 324.1 | 35.32 percent |
Eight images out of eight, the 2x file is bigger. The best case is 22.23 percent more bytes and the worst is 50.49. In JPEG the same exercise lands at 31.51 percent more, with the matched settings clustering at quality 30 and 35.
This is why the ladder had to be extended below 40. Every image cleared the target at 2x quality 40 on the first pass, which means 40 was not the matched point, it was just the floor of the run. Reporting the number from that first pass would have said 39.53 percent for WebP instead of 35.32. Both are bigger than 1x, and only one of them is the measurement.
Because it does work, in the sense people mean it. Look at the 2x SSIM column again: at quality 40 the downscaled 2x asset scores 0.97925, which is already better than a 1x file at quality 80. At quality 5, where a 512 pixel image would be unusable, the downscaled 2x asset still scores 0.94657 in WebP.
That is the artifact hiding, and it is real. Averaging four pixels into one removes most of the ringing and blocking that made the low quality setting look bad in the first place. You genuinely can crush a 2x asset far harder than a 1x one and get away with it.
What does not follow is that you end up with a smaller file. The 2x encode starts with four times the pixel data, and crushing it down to par costs more bytes than encoding the smaller picture properly in the first place.
All of the above assumes a 1x display. On a device with a 2x pixel ratio, which is every phone sold this decade and most laptops, the 1x asset is being stretched rather than shrunk, and no quality setting recovers detail that was never encoded.
So the finding is narrower than it sounds. It is not that 2x assets are wasteful. It is that serving one 2x asset to everybody, on the theory that it is cheap because it downscales well, costs about a third more than it needs to for every 1x viewer.
The answer is the boring one that has been in the HTML spec for a decade. Ship both, let srcset pick, and set each one's quality on its own merits rather than assuming the big file is doing the small file a favour.
Two files, not one. A 512 at quality 80 and a 1024 at quality 80, wired through srcset with a sizes attribute that tells the browser the box is 512.
Do not lower the quality on the 2x file to compensate. The people receiving it have the screen to see it. Compensating turns a sharp asset into a soft one for the only audience that can tell.
Never quote a 2x saving measured at a fixed quality number. It is the same mistake as comparing two codecs on a shared slider, and it goes the same way: the number moves, the picture moves with it, and the comparison measures neither.
Eight images from one gallery, all AI generated art with a similar palette, one display size, one downscaling filter. Lanczos in Pillow is not identical to what a browser does, and browsers do not agree with each other, so the 2x scores here are a good approximation rather than a promise.
SSIM on luma also flatters downscaling slightly, because averaging pixels raises structural agreement in flat regions faster than it damages edges. If anything that makes the 2x path look better than it is, and it still lost eight times out of eight.
Everything above is one measurement run on one set of files, reported exactly as it came out, including the first pass that got the number wrong.