That's a pretty old tech. So old that many existing software package do that for you e.g. ImageOptim for OSX will run all of Zopfli, PNGOUT, OptiPNG, AdvPNG and PNGCrush using a nice drag-and-drop interface.
Or it's because HN's commenting system is a trash fire and whoever coded it decided they couldn't be arsed to implement escapes, quotes, lists or fucking tables but just had to strip out arbitrary symbols and obviously U+2495 NUMBER FOURTEEN FULL STOP (⒕) is important but god forbid anybody use U+262C "ADI SHAKTI" (<should be here but HN strips it out, see https://en.wikipedia.org/wiki/Khanda_(Sikh_symbol) >) or even better U+2299 "CIRCLED DOT OPERATOR" (⊙) makes the cut but U+2609 "SUN" (<also a dot inside a circle just a different one>) shall be banned from using or discussing.
I knew HN stripped symbols pretty arbitrarily, I just checked a few non-letter Unicode blocks (Enclosed Alphanumerics[0], Mathematical Operators[1], Misc Symbols[2]) and checked which one HN strips.
Font, sadly. There have been proposals for e.g. a font variant to select a monochrome v color version but I don't think it stuck. So you get whatever your font does.
There is a CSS draft, I think, but the Unicode 'patch' for this is already real and it works 100% reliably in Safari and with varying and limited success in other browsers, which hopefully will climb aboard the clue train eventually. Just append code point FE0F (Emoji) or FE0E (Symbol) to the ambiguous character.
The story is deeper than just 'font' being the deciding factor, though.
The key thing to know is that a lot of emoji, especially many of the 'first' ones, were actually just existing (black & white) symbols that were mapped to new, color pictograms on emoji-supporting devices. This might sound like a nice backwards-compatible path, but it was, is, and will always be a disaster!
The Unicode Corsortium stupidly, naïvely, regrettably dictated that such characters should render as emoji "in the mobile context" but as symbols elsewhere. A half a moment's thought shows the folly of this incredibly dumb proposal. Say I text you an emoji. Great. Mobile context. And then you copy my text and paste it into an email your phone to your mother. Should the email look dramatically different depending on whether she checks her email on her phone or on a desktop? Madness. On what planet does it make sense for a writing system incorporate the viewing device into its decoding algorithm?
The ambiguity is resolved differently, even character-to-character in the same browser on the same device, as my tiny three-character test suite reveals.
Upsettingly to me, this means that a lot of documents written before emoji existed, or even written today on a non-emoji device such as a Windows 7 box, HAVE BEEN RETROACTIVELY AND PERMANENTLY BROKEN by the Unicode Consortium. Because, let's not kid ourselves: The meaning and tone of a document absolutely changes when one symbol is replaced with a conceptually similar but decidedly different cartoony pictogram.
