Hundreds of emoji PNGs, and the advice HTTP/2 reversed

The asset inventory is the whole story: an img/emoji/ directory of individually requested PNGs, plus 238KB of CSS, on a single landing page.

In 2018 that was expensive in a specific way. HTTP/1.1 limits a browser to around six connections per host, so several hundred images queue behind each other regardless of how small each is. And each one being small is the problem, a 3KB PNG carries request and header overhead comparable to its own payload, so most of the cost is not the bytes you wanted.

The contemporary fixes were a sprite sheet with CSS background positions, one request and a maintenance burden; data URIs inlined into the CSS, which kills caching and inflates the stylesheet; or an icon font or SVG sprite, which scales and can be recoloured. For full-colour emoji, the sprite sheet was right.

The reason to write it down is that HTTP/2 reversed the advice. Multiplexing removed the connection limit and header compression removed most per-request overhead, making concatenation actively counterproductive, because one large sprite invalidates entirely when one icon changes. A generation of performance advice became wrong and plenty of sites still follow it.

238KB of CSS for one page is the more common problem.