That is indeed a very good example of why the article is unclear in it's aim: zopfli is not a codec, it's an encoder. And furthermore the 80% figure is probably

That is indeed a very good example of why the article is unclear in it's aim: zopfli is not a codec, it's an encoder. And furthermore the 80% figure is probably for the default configuration, as zopfli has an -i argument that can make it virtually arbitrarily slow. This is exactly what I was arguing: comparing encoding speed (and "energy efficiency") of a codec in the way it's done in the article it's basically pointless and misleading. It can be done, but you have to compare specific encoders and decoders, not the codecs per se, and you can only do it meaningfully by measuring different inputs and configurations, as is done e.g. in the squash compression benchmark (that, note, only deals with lossless data compression: lossy data compression is a order of magnitude harder to compare, and video compression is a couple of orders of magnitude harder still because you have to consider delivery as well when designing your benchmark scenarios)