Google Page Speed提示優化信息說明

關於項目開發者

項目的開發者基本上是Google的工程師,這裏需要提到的一個人:Steve Souders 。他曾經效力於Yahoo,是YSlow 項目的開發者之一,而且還是Firebug Work Group  成員之一。他一直以來致力於高性能Web 應用領域。更加有趣的是,在Stanford CS系就開了這麼一門課:High Performance Web Sites (CS193H)  。另外,他還寫了兩本書,都在O’reilly出版,分別是High Performance Web Sites 與 Even Faster Web Sites。

Page Speed是什麼

Page Speed是Firefox 的擴展,準確地說是Firebug的擴展。Firebug的強大功能我已經介紹過了 ,Page Speed就是對其進行了進一步擴展,集成的功能包括:

 

  • 頁面性能綜合分析,可以針對頁面提供綜合報告和建議
  • 內置以及圖片優化,包括JS Minify
  • 改進的資源請求顯示,對於Firebug Net模塊的改進顯示
  • 頁面請求活動視圖,以直觀的圖標方式顯示各請求的加載時間順序以及每個請求各部分的時間消耗,開發人員可以根據這些數據找到性能的瓶頸
  • JS性能優化,可以分析出未被調用的以及可以延遲調用的函數

安裝

首先,需要安裝Firebug,然後在這裏 進行安裝。基本要求如下:

  • Mozilla Firefox 3.0.4及以上
  • Firebug 1.3.3及以上

使用

安裝好以後,打開Firebug,可以看到新增的兩個標籤頁:Page Speed與Page Speed Activity,如下圖所示:

使用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\文件,gzip算法對於文本文件的效率比較高,而jpg/gif/png/pdf等二進制文件本身已經進 行了一次壓縮,再使用gzip的成效已經不明顯了。而且gzip壓縮需要消耗服務器的資源,而解壓縮需要消耗瀏覽器的資源,對於比較大的二進制文件具有非 常高的性能消耗;
  • 儘量使用一種大小寫方式,要麼全部大寫,要麼全部小寫。學過數據結構和算法的同學一定知道壓縮其本身就是對冗餘信息熵進行壓縮,如何數據原素的類型種類太多,其信息冗餘度會降低,從而壓縮率降低;
  • 過小的文件(通常小於150個字節)不宜進行gzip壓縮,因爲gzip會在文件頭加入相關信息,對於小文件反而會增加文件的長度;

關於各服務器如何啓用gzip,可以參加相關文檔說明。

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

gzip壓縮檢查

最小化JS和圖片

對於文件本身具有非常大的優化空間。所謂壓縮,就是通過一些工具將函數、變量名進行優化(其實就是儘可能 縮短變量名長度),消除多餘字符(比如空格、換行符、註釋等),最終得到的代碼可以在分析和執行上得到性能提升。壓縮後得到的代碼對於機器而言是可讀的, 對於人來說就不行了,因爲文件內容已經面目全非。所以壓縮一般用於生產期的代碼,不能使用於開發期。

同樣的道理,圖片內容中也有一定的冗餘信息,比如文件頭部的一些內容描述(這些內容在jpg)圖片上尤其如此。通過一定的工具(比如GIMP)可以去除這些信息,從而節省一定的空間。

幸運的是,Page Speed已經內置了這些功能,我們不需要找第三方的工具。如下圖所示,可以看到對JS文件進行最小化可以得到的預期效果:

最小化

比如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。

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

延遲加載

通常瀏覽器在解析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 應用。

發佈了101 篇原創文章 · 獲贊 4 · 訪問量 16萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章