Zopflinator:計算 Zopfli 效果比 gzip -9 好多少的網站...

前幾天 Google 推出 Zopfli:「Google 發表與 zlib/deflate 相容的壓縮程式,再小 5%...」,是個壓縮率比目前實做的 deflate/zlib 還高的新演算法。

Zopflinator 則是提供比較的網站,你可以把網址丟進去後看到未壓縮的大小、用 deflate 預設值壓縮後的大小,gzip -9 的大小,以及 zopfli 後的大小。

原文出自 Steve Souders 的「Zopflinator」...

Google 發表與 zlib/deflate 相容的壓縮程式,再小 5%...

GoogleApache License, Version 2.0 發表了與 zlib/deflate 相容的壓縮程式:「Compress Data More Densely with Zopfli」。

與 zlib/deflate 相容代表現有的 browser 都不需要變動,而在 project 頁面上是這樣寫:

Zopfli Compression Algorithm is a new zlib (gzip, deflate) compatible compressor. This compressor takes more time (~100x slower), but compresses around 5% better than zlib and better than any other zlib-compatible compressor we have found.

比起現有的 zlib-compatible compressor 大約慢 100 倍 (XDDD),但對於靜態內容的幫助會很大,因為壓一次後就可以用很多次。

同時用 mod_deflate 與 mod_fastcgi 所產生的問題...

今天花了不少時間找到的問題...

問題是使用 mod_fastcgi 以及 mod_deflate 時,Content-Encoding 會是 gzip,但 Content-Length 會是未壓縮的長度。

也就是說,伺服器端在 header 提供的 Content-Length 可能寫 8KB,但實際上只丟出 2KB (壓縮後的大小),於是瀏覽器讀完這 2KB 後會停下來一直等,等到 Keep-Alive timeout 斷線 (在我機器上預設是 5 秒)。

在 timeout 斷線後 browser 會就抓到的資料直接解開執行 (因為這 2KB 都有抓到,於是都正確執行)。如果用瀏覽器這邊的 debugger 觀察,就會發現從 first byte 後 5.00 秒才 document ready。

解法有人在 2008 年給過:「Content-Length header should be set using ap_set_content_length」,不過因為 mod_fastcgi 一直沒出新的正式版,所以大家都還是拿到舊的版本。

所以,與之前修正 multi-threading 的問題一樣,往 ports 本身丟 patch:「Update www/mod_fastcgi to fix mod_deflate issue.」,修正後再測試就正常了。

利用 AWS CloudFront 的 Custom Origin 實做標準 deflate/gzip 壓縮

在「gzip support for Amazon Web Services CloudFront」這篇提到了要如何用 CloudFront 的 Custom Origin 實做標準 deflate/gzip。

之前 CloudFront 就有支援 Vary header,雖然只支援 Accept-Encoding,但這就是我們要的:(Appendix: Custom Origins)

The only acceptable value for the Vary header is Accept-Encoding.

本來 S3 沒有能力依據 Accept-Encoding 送出不同的結果,這次有了 Custom Origin 出來以後掛個有能力 gzip-on-the-fly 的 Web Server 就可以做到了,檔案也不一定要放到 S3 上 (可以放 EBS)。

基本上這個功能可以用現有的外部機器做 (因為 CloudFront 連到 Origin 的量應該不大),或是 EC2 的 micro instance 應該也夠用了...