Web前端性能優化教程04:壓縮組件

本文是Web前端性能優化系列文章中的第四篇,主要講述內容:壓縮組件。完整教程可查看:Web前端性能優化

基礎知識

gzip編碼:gzip是GUNzip的縮寫,是使用無損壓縮算法的一種,最早是用於Unix系統的文件壓縮,憑借著良好的壓縮效率,現在已經成為Web上使用最為普遍的數據壓縮格式。

壓縮是如何工作的

客戶端請求報文中包含Accept-Encoding表示客戶端能識別的壓縮方法,如果客戶端請求報文沒有包含Accept-Encoding首部,服務器就會假設客戶端能夠接受任何編碼格式;服務器響應報文中包含Content-Encoding表示采用的壓縮方法。(然而,一個統計表明,大約有15%的客戶端請求是沒有Accept-Encoding請求的,因為客戶端的一些web代理和PC安全軟件會移除瀏覽器發出的Accept-Encoding,因為監聽未經壓縮的響應會占用更少的CPU資源,但卻無疑增加瞭網絡傳輸的時間。)

應該對什麼資源使用壓縮

基於文本的資源如html,js,css,xml都適用於壓縮。然而對於圖片而言,卻不應該對圖片進行壓縮,因為圖片本身是已經被壓縮過瞭,如果再進行gzip壓縮,有可能得到的結果是和圖片本身大小相差不大或更大,這樣就浪費瞭服務器的CPU資源來做無用功瞭。

壓縮的優缺點

優點:壓縮組件可以減少Http響應時間,提升傳輸效率。

缺點:服務器要通過花費額外的CPU周期來完成壓縮,客戶端要對壓縮文件進行解壓縮。

總體來說,使用壓縮還是利大於弊的,不過需要合理地使用壓縮,通過選擇對一定范圍大小的組件進行壓縮和選擇要壓縮組件的類型,能使得收益最大化。

考慮代理緩存的情況

代理緩存服務器是一個中間層,位於客戶端和服務器之間。使用代理緩存的情況下,瀏覽器將不直接與服務器通信,而是通過代理發送請求。這種情況下,壓縮就要考慮額外的東西瞭。

首先,假設到達代理的是一個來自不支持gzip的瀏覽器的請求,代理會將請求轉發到web服務器,此時web服務器的響應是未經過壓縮的,這個響應會把代理服務器緩存起來並發給瀏覽器。現在,假設到達代理的第二個請求來自一個支持gzip瀏覽器,請求的是與之前相同的URL,代理會直接使用未經壓縮的緩存響應,那麼久失去瞭進行壓縮的機會瞭。考慮更糟糕的情況,第一個請求來自支持gzip的瀏覽器,第二個請求來自不支持gzip的瀏覽器,這樣第二個請求得到的緩存響應將無法被解碼,導致出錯。

解決這一問題的方法就是在Web服務器的響應中添加Vary頭,Vary:Accept-Encoding,表示web服務器告訴緩存服務器分別為每一個Accpet-Encoding請求頭緩存。在前面的例子中,代理通過識別Vary頭,對響應緩存不同的版本,避免出錯。