Zopfli Optimization: Literally Free Bandwidth

188 点作者 temp超过 9 年前

18 条评论

roeme超过 9 年前

Somewhat OT; As a swiss, the omitted ö is really beginning to bug me.It's Zöpfli. Gopferteckel.(The second word is a somewhat soft cuss word - But don't try to use it as a non-native).Also, you can't "zopfli" something - it's a noun! You "zöpf" - or, since we're in the alemannic german space; "zöpfle"./rant /vent

评论 #10828810 未加载

评论 #10828862 未加载

评论 #10830011 未加载

评论 #10830140 未加载

评论 #10828592 未加载

评论 #10829829 未加载

评论 #10831344 未加载

评论 #10828588 未加载

评论 #10829535 未加载

arcameron超过 9 年前

Regarding the avatar images:Why not a <div> with a border-radius & background color? Seems you could achieve the same thing without another HTTP request (1 for each unique avatar), no need to zopfli 45,000 unique files.

评论 #10828274 未加载

评论 #10828076 未加载

评论 #10828237 未加载

评论 #10828080 未加载

评论 #10828009 未加载

millstone超过 9 年前

> It's a smaller file to send over the wire, and the smaller the file, the faster the decompression.Can someone elaborate on this? Why do smaller files decompress faster?> However, remember that decompression is still the same speed, and totally safeWait, what? Didn't we just establish that it's faster to decompress?

评论 #10828889 未加载

评论 #10830287 未加载

评论 #10828869 未加载

jonsneyers超过 9 年前

The original PNG of that PBF comic is 671,012 bytes. ZopfliPNG crunches it down to 585,117 bytes.Not bad, but if you use newer image formats, you can do better.Lossless WebP brings it down to 429,696 bytes (using -lossless -m 6 -q 100)FLIF with default options (which means interlaced for progressive decoding) takes it down to 322,858 bytes. Non-interlaced FLIF reduces it further to 302,551 bytes.

HeyImAlex超过 9 年前

If anyone is interested in PNG optimization in general, a wrote an article about it a while back. The deflate step is only one part of it!<a href="http://heyimalex.com/journal/png-optimization" rel="nofollow">http://heyimalex.com/journal/png-optimization</a>

callumjones超过 9 年前

You could probably have a worker system that eventually produces a Zopfli compressed file.User uploads a provided PNG, you perform the quickest compression compression but then queue up a Zopfli compression. Up front you're only returning the less compressed file but after time you begin serving up the lesser bandwidth file.If the uploaded file or associated post is deleted then you can wipe it from the queue.

评论 #10828956 未加载

eridius超过 9 年前

Are the reported Zopfli numbers for PNGs achieved by recompressing the original, or by recompressing the output of PNGout? The wikipedia page for PNGout says> PNGOUT also performs automatic bit depth, color, and palette reduction where appropriate.Assuming the Zopfli numbers were created by recompressing the original, I wonder if there's any further savings to be had by recompressing the output of PNGout?Alternatively, PNGcrush can also do the same sort of lossless bit depth and palette reduction, so I'd be curious about the combination of PNGcrush + Zopfli as well.

评论 #10828468 未加载

legulere超过 9 年前

And you could save even more bandwidth if you changed the PNG standard to also allow Brotli compression. Even more probably if you created a better file format.That's not free anymore, but it's technologically easily possible to drastically reduce the amount of resources we use. What holds us back is that it's hard to get other people to do stuff like supporting new file formats or even have a better output in their image manipulation program.

评论 #10828440 未加载

评论 #10828863 未加载

Rygu超过 9 年前

It's not even just about bandwidth. You're reducing page load time, and therefore increasing revenue. <a href="http://www.fastcompany.com/1825005/how-one-second-could-cost-amazon-16-billion-sales" rel="nofollow">http://www.fastcompany.com/1825005/how-one-second-could-cost...</a>If you're a designer/developer on Mac I would strongly recommend ImageOptim (<a href="https://imageoptim.com/" rel="nofollow">https://imageoptim.com/</a>). It supports Zopfli and has a simple drag-n-drop user interface.

评论 #10830266 未加载

ck2超过 9 年前

Batch files which go though all the tools and find the smallest sizes for various images and .gz files<a href="http://css-ig.net/tools/" rel="nofollow">http://css-ig.net/tools/</a>Personally I've found this tool is faster and does a better job than most others and it's free:<a href="http://psydk.org/pngoptimizer" rel="nofollow">http://psydk.org/pngoptimizer</a>

jibsen超过 9 年前

I don't think tools like pngquant should be so easily dismissed. With the pixel density of todays monitors, the lossy changes they introduce can be very hard to see (which may be surprising for those of us who remember the pixelated horrors of Floyd-Steinberg from a couple of decades ago).For some image types, lossy png has the huge advantage over jpg at the same file size that they have no jpg artifacts.<pre><code> 671.012 original 584.677 zopflipng -m 580.180 zopflipng -m --lossy_transparent 576.637 pngwolf --max-stagnate-time=0 --max-time=300 --normalize-alpha --strip-optional 190.598 pngquant --speed 1 179.638 pngquant + pngwolf</code></pre>

jzelinskie超过 9 年前

His example use case seems a little contrived. We have a similar default avatar at Quay.io, but we handle it all client-side with CSS. There's some more free bandwidth!

评论 #10829747 未加载

leni536超过 9 年前

> ~250 color schemesTheoretically one could use one of the indexed PNG formats and only change the palette. I don't think that those avatar images use too much number of colors (even with anti-aliasing) so 8 bit indexed PNG should be more than enough.

manigandham超过 9 年前

This is interesting - but really don't we have better things like FLIF that should be gaining developer momentum first?That would solve basically everything wrong with today's decades old formats.

bartvk超过 9 年前

Just checked; on my MacBook it installs with a quick$ brew install zopfliThat's assuming you have Homebrew installed, if not: <a href="http://brew.sh" rel="nofollow">http://brew.sh</a>

sandGorgon超过 9 年前

the lions share of image creation these days happens on the mobile. and I cant seem to find a Zopfli library for android. I wonder why - is it too heavy duty for a mobile CPU ?

评论 #10830130 未加载

Qwertious超过 9 年前

Sounds like there should be a system to JIT images with this.

jMyles超过 9 年前

> it's about as close as it gets to literally free bandwidth in our line of work.Listen, I'm all about inventive ways to lighten the yoke of static media on the web today.But, in two important ways, this is not "literally free bandwidth":1) The weaker: Despite the tone of obviousness in this article, it acknowledges that the choice of which technology to use is not made for you: there are edge cases where other methodologies are indeed superior. So, far from being free, these sorts of solution do have a time cost.2) The stronger: We live in a world where, on a great day, the user's realized downstream bandwidth is 20% their LAN connection; their upstream 5% or less.Connecting to a next-door neighbor via a conventional web application served through a typical corporate ISP probably means pushing packets a thousand miles or more, only for them to come back into our community.Complicating this issue: our name service and certificate distribution are implemented in a way that is reasonably called "incorrect."Our ISPs have a "speak when spoken to mentality" about connectivity, and competition is rare.A solution bragging "literally free bandwidth" needs to service this concern - let me transfer a piece of media to a next door neighbor utilizing the other 95% of my network interface upstream capacity. That I'll call free bandwidth.

评论 #10827971 未加载