使用Google Page Speed優化Web前端性能

安裝步驟：http://jingyan.baidu.com/article/597035523c54cd8fc00740ed.html

安裝好之後，打開Firebug，能夠看到新增的標籤頁：Page Speed：

使用Page Speed

其中，Page Speed標籤頁包括兩個功能：Analyze Performance與Show Resources，其中Analyze Performance是Page Speed的核心功能。點擊之後Page Speed開始工做，幾秒鐘之後就會得出一份詳細的性能分析報告：

Page Speed分析報告

其中各項按照重要性進行排序，展開每一部分，能夠獲得詳細的報告。其中，紅色圖標表示未進行優化，黃色表示能夠進行進一步優化，綠色表示已經進行優 化。

其他部分的功能能夠在Google Code的官方主頁上找到，這裏就不贅述了，只重點介紹Analyze Performance這一功能。

性能優化技巧

其實上圖的每一項都是Page Speed提供的優化標準，Page Speed就是按照這一條條標準進行分析的。須要拿出來說的包括：

使用gzip壓縮

這裏放在第一，是性能優化效果最顯著的一步。所謂gzip壓縮是一種開發的壓縮算法，目前的主流瀏覽器(Firefox, Safari, Chrome, IE4及以上)與主流服務器(Apache, Lighttpd, Nginx)均對其有很好的支持。gzip壓縮是經過HTTP 1.1協議中的Content-Encoding : gzip來進行標記說明，其能夠明顯減小文本文件的大小，從而節省帶寬和加載時間。我作過的一個實驗，發現啓用gzip後，jquery 1.2.6 minify版本的大小從54.4k減小到16k，減小了70%。gzip適用的狀況包括：

• HTML\CSS\JavaScript文件，gzip算法對於文本文件的效率比較高，而jpg/gif/png/pdf等二進制文件自己已經進 行了一次壓縮，再使用gzip的成效已經不明顯了。並且gzip壓縮須要消耗服務器的資源，而解壓縮須要消耗瀏覽器的資源，對於比較大的二進制文件具備非 常高的性能消耗；
• 儘可能使用一種大小寫方式，要麼所有大寫，要麼所有小寫。學過數據結構和算法的同窗必定知道壓縮其自己就是對冗餘信息熵進行壓縮，如何數據原素的類 型種類太多，其信息冗餘度會下降，從而壓縮率下降；
• 太小的文件(一般小於150個字節)不宜進行gzip壓縮，由於gzip會在文件頭加入相關信息，對於小文件反而會增長文件的長度；

關於各服務器如何啓用gzip，能夠參加相關文檔說明。

如何檢查gzip是否啓用？使用Firebug，在Net模塊中進行檢查HTTP Header是否有Content-Encoding gzip標記，參見下圖：

gzip壓縮檢查

最小化JS和圖片

對於JavaScript文件自己具備很是大的優化空間。所謂JavaScript壓縮，就是經過一些工具將函數、變量名進行優化(其實就是儘量 縮短變量名長度)，消除多餘字符(好比空格、換行符、註釋等)，最終獲得的代碼能夠在分析和執行上獲得性能提高。壓縮後獲得的代碼對於機器而言是可讀的， 對於人來講就不行了，由於文件內容已經面目全非。因此壓縮通常用於生產期的代碼，不能使用於開發期。

一樣的道理，圖片內容中也有必定的冗餘信息，好比文件頭部的一些內容描述(這些內容在jpg)圖片上尤爲如此。經過必定的工具(好比GIMP)能夠 去除這些信息，從而節省必定的空間。

幸運的是，Page Speed已經內置了這些功能，咱們不須要找第三方的工具。以下圖所示，能夠看到對JS文件進行最小化能夠獲得的預期效果：

JavaScript最小化

好比jquery.form.js，最小化後減小11.9kb，減小54.8%的空間。點擊minified version，在新窗口中能夠看到Page Speed爲你優化好的版本，直接更新到服務器就能夠了。

關於圖片優化，操做方法同上。

啓用瀏覽器緩存

這是常用的方法。當請求的資源在瀏覽器本地獲得緩存後，第二次請求這些內容就能夠從直接緩存中取出，減小了連線的HTTP請求。

HTTP 1.1提供的緩存方法主要有兩種：

• Expires and Cache-Control: max-age. 即內容在緩存中的生命有效期。第一次請求後，在生命有效期以內的後期請求直接從本地緩存中取，不過問服務器；
• Last-Modified and ETag. 其中Last-Modified標記文件最後一次修改的時間，瀏覽器第二次請求是在頭部加入上次請求緩存下來的Last-Modified時間，如何兩次 請求期間服務器的內容沒有進行修改，服務器直接返回304 Not Modified，瀏覽器接到之後直接使用本地緩存。不然，服務器會返回200以及更新後的版本。ETag是服務器對於文件生成的Hash散列，其生成算 法與最後一次修改的時間相關。瀏覽器第二次請求發送上次的ETag信息，服務器經過簡單的比對就知道是否應該返回304仍是200。

關於各緩存頭部的設置能夠參考各服務器的相關文檔。

JavaScript延遲加載

一般瀏覽器在解析HTML時遇到JS文件會先下載，解析執行後纔會下載後面的內容，期間天然會形成必定的延時。爲了提升性能，儘量將JS文件的位 置後移，若是可能，還能夠經過部分代碼進行異步加載。另外，對於JS和CSS在必須放置在一塊兒狀況，須要報JS放置在CSS以後，這樣CSS與JS文件可 以同步下載。

文件拼接

這裏主要包括JS/CSS等文本文件和圖片。對於文本文件，儘量將同一類型放置到一個文件中，減小HTTP請求。對於CSS背景圖片，可使用 Sprit技術將圖片拼接到一塊兒，而後使用background-position屬性選擇對應的圖片。Google首頁上的這個圖片就是一個很好的例 子：

Google Sprite

其它

更多優化規則，能夠參考Page Speed的說明以及Steve Souders我的主頁上的相 關信息。

結論

雖然如今網絡速度愈來愈快，Web前端優化仍然很是重要；永遠不要假設用戶的網絡速度 和你同樣快，畢竟因爲ISP的各方面緣由，各地的速度大不相同。良好的策略能夠在有限的帶寬資源下達到最大的性能發揮。

這個世界須要豐富的Web應用，更加須要高效的Web應用。