We cut the image bytes in half and the score did not notice

The change, measured on one file at a time

Our proxy takes third-party JPEG and PNG images, serves them from an endpoint of ours and re-encodes them to WebP on the way. It is the trade a whole category of plugins is sold on: fewer bytes, at the price of the file no longer arriving from wherever it used to arrive from.

On the nine sites here the rewrite is not a detail. It applies to between 56 and 147 images per page.

We measured what it does to a single file before asking what it does to a page. Twenty-five images from six different delivery networks, each pulled both ways from the same machine, both routes warmed first, three measurements each:

	Original CDN	Our endpoint
Median size	250 KB	54 KB
Median time to first byte	420 ms	925 ms
Median time to last byte	591 ms	1342 ms

Both halves are real. The saving is 43% of the bytes at the median, and the heaviest file in the set went from 3.7 MB to 920 KB. So is the delay: 509 ms added to the first byte at the median, never less than 371 ms.

Put together, one image out of twenty-one arrived sooner through our endpoint. Even the file that shrank fourfold arrived later, because a quarter of the bytes over a slower route is still a slower route. Four more of the 25 came back unconverted, because the endpoint declines a conversion that would not pay for itself. Those four cost the latency and returned nothing at all; one of them was a 97 MB PNG that reached us 2.4 seconds later than it would have on its own.

The same change, measured on the page

If the file-level numbers were the whole story, the page-level result would follow from them. It does not.

For each of the nine sites we ran an A/B where the two versions differ by exactly one thing: whether that rewrite happens. Three rounds per cell, mobile, alternating between the cells so that drift in network conditions is shared, a fresh cache-busting parameter every round, both versions warmed identically first. We verified the two cells really were different by counting the rewritten URLs in the HTML that came back: 147 in one cell and 0 in the other on the first site, and the same pattern on the rest.

Result without the rewrite	Sites
Scored higher	4
Scored lower	4
Unchanged	1

The median difference is zero. The number that matters more than the median is the noise it sits in: the median spread inside a single cell, three runs of one unchanged URL, was 19 points. Not one site produced a difference larger than its own spread. On the site with the widest swing, the version without the rewrite scored 47, 91 and 55 on three consecutive runs.

So the honest statement is not “the rewrite makes no difference”. It is that a change touching up to 147 requests and removing megabytes from a page produced nothing this measurement could separate from the measurement’s own noise.

Why a metric can miss half a megabyte

The performance score is a weighted average of five metrics, and each of them is a timing on the way to a usable first screen. None of them is a byte count.

An image that is not in the viewport when the page first renders is not on that path. It can weigh 400 KB or 45 KB and the arithmetic behind the score is the same, because nothing waits for it. That is not a flaw in the score. It is the score correctly reporting that the visitor was not kept waiting by that file.

The uncomfortable half of the same fact is what happens to the one image that is on the path. The hero image, the one the browser picks as the largest element in the viewport, pays the +509 ms in full and pays it into the metric carrying the most weight of the five. A change that is invisible on ninety images is decisive on one, and it is the one image most tools rewrite along with the rest.

The one measurement that went the other way

We have exactly one case where this same rewrite was not invisible, and it is worth publishing next to the nine, because it is the shape of the exception.

On a site built with a page builder whose images all come from the builder’s own network, turning the rewrite on cost the mobile score 66 against 38, with the largest contentful paint moving from 10.5 seconds to somewhere between 19 and 33. That is a single site measured three times per side, so it is a case and not a rate. But the mechanism is legible: on that page the images were not decoration around the content, they were the content and the first screen both. Every one of them was on the path.

The rule that reconciles the two results is not about images. It is about whether the resource you are optimizing is something the visitor is waiting for.

What we did with our own filter

We narrowed it, the same week we measured it.

It now leaves alone any image the page has marked as its priority, whether by fetchpriority or by preloading it, because that is the one where the added latency lands in the metric that counts. It also leaves alone images that already come from a delivery network, on the grounds that replacing a network of edges with one server in one city is not an optimization we can defend. On the nine sites here, those two rules took the rewrite from 799 images to 14.

That is close to switching the feature off, and we would rather say so plainly than describe it as tuning. What remains is the case the feature was actually for: images sitting on an ordinary origin, a sibling domain or a plain storage bucket, where our copy has something to improve on. Across our full base that is about a fifth of the third-party images we see, on 38% of the sites.

We are publishing the measurement that made our own feature smaller because the alternative is worse. A saving of 43% per file is a genuine number, it is the number we would have put on a feature page, and it would have been true and useless at the same time.

What to take from it

If you are compressing images to raise a score, the question that decides whether it will work is not how much smaller the files get. It is whether the browser is waiting for those files at the moment the score is taken.

For the hero image, it almost always is, and that is where format, dimensions and priority earn their points. For everything below the first screen, the saving is real but it is a bandwidth saving, not a score saving. Both are worth having. They are not the same thing, and a tool that reports one while promising the other is easy to build by accident.