Compress data more densely with Zopfli

Re:Compress data more densely with Zopfli by afhof on Friday March 01, 2013 @04:22AM (#5303491)

340 bytes is not worth 20x time increase. 0.4% decrease in file size IS worth the time. If you can measure the amount of time it takes to download those last 340 bytes, then you can start to count how many downloads it takes before its worth it. (If download speed was constant, it would be about 224 downloads).

PNG seems like a good candidate for this style compression. A constant time initial cost for recurring savings in bytes transmitted seems like an excellent use of CPU time to me.

As an aside, I ran the Zopfli program with 10000 iterations on jquery-1.9.1.js:

  268381 jquery-1.9.1.js
   75622 jquery-1.9.1.js.gz

[ Parent | on HN ]

Re:Compress data more densely with Zopfli by ryalfalpha on Friday March 01, 2013 @05:13AM (#5303618)

"A constant time initial cost for recurring savings in bytes transmitted seems like an excellent use of CPU time to me."

Wish more people understood this aspect of web scale! well said :)

[ Parent | on HN ]

Re:Compress data more densely with Zopfli by CJefferson on Friday March 01, 2013 @07:54AM (#5303978)

A fairer (in my opinion) comparison, with minimised jquery:

    92629 jquery-1.9.1.min.js
    32666 (35.26%) gzip -9
    31691 (34.22%) zopfli with standard compress
    31688 (34.20%) zopfli with max compress

[ Parent | on HN ]

Re:Compress data more densely with Zopfli by ck2 on Friday March 01, 2013 @09:28AM (#5304336)

     31783 gzip with 32KB dictionary and 128 word size
     31764 above with filename stripped

I am too lazy to strip out the filename so there is a few bytes penalty, so it's more like 31764

So in this case it's

    31688 
      vs
    31764

76 bytes

I guess the real question is what is the decode penalty time if any?

[ Parent | on HN ]