IMO, a profile pic is better for an "about" page. The 10 KB Club excludes favicons and the like from page size, since they're non-blocking and not needed to read an article's text.

All images are non-blocking, not just favicons.

If a site uses the loading=lazy attribute they won't even be loaded until they're on the screen.

Background images in in-line CSS can block rendering in some older browsers but that's really the url() bit that's blocking rather than the image.

For what it's worth, even a large 256x256 PNG favicon can fit within 1 KB to 2 KB size if properly optimized, say, using ImageOptim or another similar tool.

> For what it's worth, even a large 256x256 PNG favicon can fit within 1 KB to 2 KB size if properly optimized, say, using ImageOptim or another similar tool.

This is a heavily optimised PNG favicon [0], which is only 192x192. But without trashing the palette, I can't really deduce it further, and it's already 2.7K. Niether pngcrush nor imageoptim can do much with it.

[0] https://shatterealm.netlify.app/android-chrome-192x192.png

I tried zopflipng [1] with the very expensive option suggested from the usage and got 2,493 bytes (original 2,740 bytes, nowhere practical as it took 3 minutes) so you don't have to sacrifice the palette, though I'm not sure if 16 or even 4 color palette will significantly alter the visual.

[1] https://github.com/google/zopfli

It's already an 8bit grayscale image - significantly less than a 4 colour palette.

And whilst the server might use state of the art compression... There's still no way a much larger image is going to fit in the proposed 1-2K limit.

> if properly optimized

It's more about the content of the image, the optimization can only do so much. If it's a pixel art or the palette is reduced to hell, then yeah, probably; otherwise I don't think you can display a 256x256 photo in 2KB.