以開發跟推出時間來時間，其實不算長…可是對流量傳輸來說倒是真的有加分…
一般來說，在 Brotli 推出之前，大部份網頁的壓縮技術是 gzip, deflate ，以 gzip 為主流…以 compression level 開到 10 來說， text/html, text/palin, text/css 或 js 經過壓縮後，傳輸的大小約為原始檔案的 3/10 ，100K 的 html 檔，實際傳輸約是 30K …
而 Brotli 在靜態文字檔的壓縮，一樣以 level 10 來說，大約是 2/10 …不要小看這 10% ，因為壓縮不但是縮小了大小，也縮短了時間…
請看最近的一則新聞「Google實習生立大功！她的專案每天為Android用戶省下1.5PB資料傳輸量」
-----
不過呢，也不用想說這是萬靈藥…為什麼？
天下沒有白吃的飯，以目前普遍的壓縮方式，大多是吃 cpu 的，也就是說，如果用來跑網頁服務的機器的 cpu 等級沒有多好，或者也不是多核多緒，我建議還是不要開壓縮，或者把 compression level 降低比較好…（不過，現在就算不是拿伺服器架站，桌機等級的 cpu 也沒有多弱，當然，請找多核心的)
當然，這我只是建議啦，這年頭很多東西都講原生支援，很多東西只要原生支援後，都可以省更多的效能，這在網路設備上很常見…所以，哪天 brotli 的方式以原生指令集活在 cpu 中，就算用單核可能所花的資源也不會覺得多，只是，這東西再怎麼省都是要秏 cpu 的…
-----
優點：
- 更高的壓縮率代表節省更多的傳輸資源與時間
- 只支援 https 協定，強迫網站安全性？（抱歉，我這個只是單純以為算優點）
- 更高的壓縮率代表有「可能」更需要 cpu 的效能
- 只支援 https 協定，強迫網站安全性？（跟優點一樣？因為要跑 https 要花時間找憑證或更新憑證…很煩）
沒有留言:
張貼留言