This also applies to e.g. https://en.wikipedia.org/static/images/project-logos/enwiki-2x.png

In T109040#1615502, @Krinkle wrote:

This also applies to e.g. https://en.wikipedia.org/static/images/project-logos/enwiki-2x.png

PNGs shouldn't gzip well, right?

Change 237369 had a related patch set uploaded (by BBlack):
Compress js (and other text) in varnish

https://gerrit.wikimedia.org/r/237369

In T109040#1623650, @BBlack wrote:

In T109040#1615502, @Krinkle wrote:

This also applies to e.g. https://en.wikipedia.org/static/images/project-logos/enwiki-2x.png

PNGs shouldn't gzip well, right?

True. Graphite does it it, though. And shaves off 0.3KB on a 25KB PNG graphic (25,470 bytes uncompressed; 25,152 bytes compressed; via cURL). – graphite/render?png. But I wouldn't be surprised if it actually caused the response to be larger in other cases.

Change 237369 merged by BBlack:
Compress js (and other text) in varnish

https://gerrit.wikimedia.org/r/237369

I've merged a change that should fix this and some other related cases. It's only recently that we started trusting varnish's gzip support in general, and it's about time we expanded on that trust a little.

However, the varnish-level gzip stuff happens on entry of new objects into the cache; it won't re-encode existing cache hits. So, we won't see effects on particular existing URLs until they expire naturally. The max cache lifetime in general is 30 days, but since this the new gzip stuff is applied at all layers, odds are good of any given object falling out of the frontend layer considerably sooner than that and getting gzipped as a result.