@debt don't add parent tags -- we will have to resort it afterwards, once @herald is fixed

From some discussion while waiting for a download

• https://www.mediawiki.org/wiki/Extension:Kartographer#/map/0 loads 2.5MB of tile images for users on big screens
• We'd want to use accept headers, and possibly strip the png suffix from tile URLs. The latter is not required, and Mapquest served JPEG tiles with a .png name for years

The 30 tiles from that page can be gotten with

for x in `seq 125 130`; do for y in `seq 83 87`; do curl -o 8_${x}_${y}.png "https://maps.wikimedia.org/osm-intl/8/$x/$y.png"; done; done

Recompressing them with pngnq and cwebp gives the following sizes

format            size (kb)
png               1565
png256            691
webp lossless z3  1281
webp lossless z6  1258
webp lossless z9  1243
webp nl 80        1047
webp nl 40        760
webp jpeg-like 40 111
webp jpeg-like 80 309
webp jpeg-like 90 482
webp jpeg-like 95 618
webp jpeg-like 98 752

webp compression numbers are done with -jpeg_like to make the quality resemble that of a jpeg of the same quality, nl is -near_lossless.

What struck me is how blazingly fast webp lossy 95 and 98 were. Visible artifacts are hard to see at 90 and above, even when zoomed in.

I forgot to mention that these 2.5MB were on a 2.0 DPR (device pixel ratio). For 1.0 DPR it seems to be around 1.1MB. But still.

Since Firefox 65 released, all major web browsers except Safari got support for WebP format, so it's reasonable to provide WebP images directly to them. We can try to detect the request header firstly while the server received the request, then we decide weather sending WebP images to the client.