Fun fact, even though it's downloaded as compressed format, the windows drawing api bitblt requires bmp format, so it's probably saved in memory as bmp. A 1024x768x24bpp bmp is multiple megabytes, even though the jpeg is 100kb.

(I think..)

But Chrome doesn't use bitblt afaik. It's GPU composited, which does support a number of tile-level compression formats.

Not just the Windows drawing API, but essentially any drawing API requires that images be decompressed. Some sprite sheets are particularly egregious. I've seen sprite sheets with dozens of 32x32 sprites stacked above each other, and a single wide (let's say 1024x32) sprite at the bottom. This can give you a sprite sheet which is 1024x2048, decompressing to 8 MB, with literally 97% of the data being blank pixels. Fixing this on the browser side is very hard - it's a content problem.

The solution is to lay out sprite sheets to minimize blank space. Rearranging the sprites can easily get the number of blank pixels down to ~5-10%, thus saving ~7 MB, in essentially all browsers.

YEs, but images 2,336 x 3,504 = 8,185,344 pixels @ 24bit color roughly equals to 24MB. That is lots of images even if you are on native resolution retina display. And doubling that gives you 48MB only. ( And someone has pointed out they are compressed differently within memory, so likely only consuming 1/2 to 1/3 memory size )

That leaves with 200MB memory gods knows what they are.

I think that web stack has its problems, but generally problem is developers (or their managers) who don't care about performance. It's possible to create awesome and performant websites with current web stack.

Console yourself by remembering that the vast majority of people creating these websites don't have computer science degreees. They learned their "trade" over a few weekends. Their "profession" is the equivalent of self-taught backyard abortionists.

Please don't post unsubstantively like this here.