It's something to do with the responsive image code. I suspect both devices are being detected as having retina displays.

Note the thumbnail requests are for thumbnails that are double the size:

cc'ing @brion who has worked on that code.

One thing that I saw now when I tested: our retina images can be smaller (ping @Gilles seems like the PNGs match the size the people from Google talked about). Tested with imageoptim (disabled lossy format as default) with default setup (tested only on the Facebook page though):
PNGs can be >20% smaller (for icons even 40-50%).
JPG:s can be 3-5% smaller (seems like MOZJpeg works best).

I remember the Swedish newspaper aftonbladet.se (they wrote about it in Smashing magazine) did a study a couple of years ago when they implemented their mobile site and they compressed the retina images really hard, because the human eye can't actually see the difference on that kind of displays. Their final solution was that they compress all images except like the hero image (that's easy for a newspaper) really hard. If we would do the same we could cut the size with 50% or something like that. Think we should look around and see how others do it and talk to them (a start could be theguardian, think they are fully responsive).

@Peter the PNG claims are being investigated but could be metadata: T111633: Optimize thumbs right after creation

Beyond metadata (I suspect we might not be removing as much "junk" metadata as we could), more involved PNG compression is usually quite time-consuming and thus would require a new async process to be re-generated with better compression (currently thumbnails are generated on demand). It's kind of a bad effort-to-reward ratio and in the current thumbnailing infrastructure could mean a significant storage cost (we currently store all thumbnails forever, regenerating a better PNG might require storing an extra copy).

As for compressing things further in a lossy fashion because "people won't see the difference", this is not something we can afford to do. Unlike a magazine where the content provider delivers whatever they want and can do that kind of trade-off, our content contributors care deeply about the quality of the thumbnails we deliver, retina or otherwise. Rendition of details even in thumbnails matters more in an encyclopedic context. The only kind of extra compression that can be considered is some that would somehow reduce the file size and keep the visual quality equal, with absolute proof with a tool like DSSIM that can measure it. I've tried several times and that's never the case:

T70145: Generate JPG thumbnails with ImageMagick + mozjpeg instead of IM alone
T105319: Investigate serving webp and JPEG-XR thumbnails to browsers capable of it
T107885: Investigate graphicsmagick performance
T108115: Investigate OpenCV performance for JPG thumbnailing

The main explanation is that what's "90" quality in IM isn't "90" in MOZJpeg, etc. At the end of the day, when you compare the visual information deviation from a perfect thumbnail, all tools that generate JPGs seem to end up with the same score for a given file size. When you find a 3-5% gain with a new tool, it's pretty much guaranteed that the visual quality will be 3-5% lower. You might not see it, or it would require squinting and having a very keen eye to spot it, but believe me, Commons contributors will notice and they will be very unhappy, because on some images it will be visually more pronounced than others. The current quality choice for JPG is pretty reasonable for thumbnails. It's worth testing new tools, or new version of tools, as they appear, but so far every time I thought there was some gain it was still the deception of slightly worse quality that you don't always notice at first glance. And if you're going to serve worse quality images to save on size, no need for a new tool, just lower the quality setting in IM.

Also if you play with such tools, always pay attention to the ICC profile (it has to be kept) and basic metadata (author, description, source, etc. I can't remember the list of the vital ones we need to always keep, but that's the general idea). Optimization tools will almost always get rid of that metadata for thumbnails, but again, in our context it matters and we have to keep it.

In T113997#1682146, @Jdlrobson wrote:

It's something to do with the responsive image code. I suspect both devices are being detected as having retina displays.

On the contrary, the desktop isn't retina and the phone is retina. That explains it all. The tests are comparing apples and oranges. For a fair comparison the desktop test needs to be retina.

Now, in the hypothetical world of no community backlash, if you wanted to compress retina thumbnails more aggressively, you'd be facing a caveat. Currently, the retina sizes are using the same thumbnails coming from the same pipeline, same quality, as the regular ones. Meaning that if by any chance the same size needed for retina is the "base" size somewhere else on a page, then it guarantees better cache hit rate. If you decide to make retina thumbnails a lower quality, that means an extra parameter on the thumbnail url, and not only extra storage for that thumbnail, also a higher likelihood of misses for retina users. Meaning that thumbnails will have to be generated on the fly for them more often than before, when there was an overlap with thumbnails in non-retina context of the same size. On high traffic pages you'll be fine, but it would introduce a penalty on infrequently visited pages. Also, whenever you turn that on, you basically invalidate all thumbnails for retina users, which will have a significant performance impact short term.

Wikipedia Zero has a qlow parameter already, but I think it might be too aggressive for that purpose. And there's basically zero chance of overlap between the sizes used for Zero and the sizes needed for retina.

But before all those technical challenges, the biggest one would be to successfully get community approval to increase the compression of retina thumbnails.

In T113997#1684498, @Gilles wrote:

In T113997#1682146, @Jdlrobson wrote:

It's something to do with the responsive image code. I suspect both devices are being detected as having retina displays.

On the contrary, the desktop isn't retina and the phone is retina. That explains it all. The tests are comparing apples and oranges. For a fair comparison the desktop test needs to be retina.

Yup. When I said both devices I meant both mobile devices (we are testing on two mobile devices) :)

Let me check the numbers again and see what it looks like now. For the initial load this have changed since we lazy load on mobile.