The zlib format includes uncompressed* chunks, and CRC is only non-trivial if you're also trying to do it quickly, so a faux-zlib can be much, much smaller.
(I don't recall if I've done this with PNG specifically, but consider suitably crafted palettes for byte-per-pixel writing: quick-n-dirty image writers need not be much more complex than they would've been for netpbm)
* exercise: why is this true of any reasonable compression scheme?
https://github.com/a-e-k/canvas_ity/blob/f32fbb37e2fe7c0fcae...
Any? I wouldn't say that. If you took LZ4 and made it even simpler by removing uncompressed chunks, you would only have half a percent of overhead on random data. A thousandth of a percent if you tweaked how it represents large numbers.
If you wanted to go even simpler, here's an entire compression format described in one line:
one byte literal length, one byte match length, two bytes match offset, 0-255 literal bytes, repeat