The zstd library is already included by most major browsers since it is a supported content encoding. Though I guess that does leave out Safari, but Safari should probably support Zstd for that, too. (I would've preferred that over Brotli, but oh well.)
Btw, could you 'just' use no compression on this level in the PNG, and let the transport compression handle it?
So on paper (and on disk) your PNG would be larger, but the number of bits transmitted would be almost the same as using Zstd?
EDIT: similarly, your filesystem could handle the on-disk compression.
This might work for something like PNG, but would work less well for something like JPG, where the compression part is much more domain specific to image data (as far as I am aware).
If there is a particular reason why that wouldn't work, I'm not aware of it. Seems like you would eat a very tiny cost for deflate literal overhead (a few bytes per 65,535 bytes of literal data?) but maybe you would wind up saving a few bytes from also compressing the headers.
