Yslow---一款很實用的web性能測試插件

YSlow能夠對網站的頁面進行分析，並告訴你爲了提升網站性能，如何基於某些規則而進行優化。 YSlow能夠分析任何網站，併爲每個規則產生一個總體報告，若是頁面能夠進行優化，則YSlow會列出具體的修改意見。

YSlow的安裝：

1、安裝 firebug插件。針對不一樣的瀏覽器插件也是不一樣的，例如 針對chrome.插件名稱爲：Firebug Lite for Google Chrome。官網下載地址爲：https://chrome.google.com/webstore/search/firebug%20%20for%20chrome

點擊添加至chrome ，安裝後，Firebug Lite按鈕將會出如今谷歌瀏覽器地址欄右側，一個小蟲子圖標在哪裏顯示着。點擊便可啓用。

二、安裝YSLOW插件，官網下載地址爲：http://developer.yahoo.com/yslow/

點擊安裝便可。安裝後，YSlow按鈕會在 chrome的右上角顯示。

YSlow的使用

點擊YSlow按鈕，啓動插件，點擊Run Test 測試當前頁面。在新彈出的界面中按照重要性顯示了影響此頁面效率的元素，其中A類評分爲最高，F爲最低。

通常來講提升網頁效率依照下面14條準則。

第一條：Make Fewer HTTP Requests 儘量的減小HTTP的Request請求數。

80%的用戶響應時間都是浪費在前端。而這些時間主要又是由於下載圖片、樣式表、JavaScript腳本、flash等文件形成的。減小這些資源文件的Request請求數將是提升網頁顯示效率的重點。
這裏好像有個矛盾，就是若是我減小了不少的圖片，樣式，腳本或者flash，那麼網頁豈不是光禿禿的，那多難看呢？其實這是一個誤解。咱們只是說盡可能的減小，並無說徹底不能使用。減小這些文件的Request請求數，固然也有一些技巧和建議的：

1：用一個大圖片代替多個小圖片。

這的確有點顛覆傳統的思惟了。之前咱們一直覺得多個小圖片的下載速度之和會小於一個大圖片的下載速度。可是如今利用httpwatch工具的對多個頁面進行分析後的結果代表事實並非這樣。
第一張圖是一個大小爲40528bytes的337*191px的大圖片的分析結果。
第二張圖是一個大小爲13883bytes的280*90px的小圖片的分析結果。

一個大小爲40528bytes的337*191px的大圖片的分析結果（點擊圖片能夠查看完整大圖片）

 

一個大小爲13883bytes的280*90px的小圖片的分析結果（點擊圖片能夠查看完整大圖片）

 

 

 

第一張大圖片花費時間爲：
Blocked：13.034s
Send：0.001s
Wait：0.163s
Receive：4.596s
TTFB：0.164s
NetWork：4.760s
功耗時：17.795s
真正用於傳輸大文件花費的時間爲Reveive時間，即4.596s，多數的時間是用來檢索緩存和肯定連接是否有效的Blocked時間，供花費13.034s，佔總時間的73.2%。

第二張小圖片花費時間爲：
Blocked：16.274s
Send：小於0.001s
Wait：0.117s
Receive：0.397s
TTFB：0.118s
NetWork：0.516s
功耗時：16.790s
真正用於傳輸文件的花費時間是Reveive時間，即0.397s，這的確要比剛纔大文件的4.596s小不少。可是他的Blocked時間爲16.274s，佔總時間的97%。

若是這些數據還不夠說服你的話，讓咱們看看下面這張圖。這裏列出了某個網頁中全部圖片中的花費時間示意圖。固然，裏面的圖片有大有小，規格不一。

大約80%以上的時間是用來檢索緩存和肯定連接是否有效的Blocked時間。

其中藏青色的爲傳輸文件花費的Reveive時間，而前面白色的爲檢索緩存和確認連接是否有效的Blocked時間。鐵同樣的事實告訴咱們：

§ 大文件和小文件下載所需時間的確是不一樣的，差別的絕對值不大。並且下載所需時間佔總耗費時間比例很小。

§ 大約80%以上的時間是用來檢索緩存和肯定連接是否有效的Blocked時間。不管文件大小，這個時間的花費大體是相同的。並且所佔總耗費時間的比例是極大的。

§ 一個100k的大圖片總耗費時間絕對大於4個25k的小圖片的總耗費時間。並且主要差異就是4個小圖片的Blocked時間絕對大於1個大圖片的Blocked時間。

因此若是可能仍是使用大圖片來替代過多的瑣碎的小圖片吧。這也是爲何翻轉門的效率要高於圖片替換實現的滑動門的緣由。
可是，請注意：也不能用太大的單張圖片，由於那樣會影響到用戶體驗。例如個幾兆的背景圖片的使用絕對不是一個好主意。

2：合併你的css文件。

我之前犯了一個錯誤，你在看我《樣式表的組織與規劃》的系列文章中會知道。當時，我爲了方便組織和規劃樣式表，將用於不一樣用途的樣式表文件分離開來，造成不一樣的css文件。而後在頁面中根據須要引用多個css文件。根據「儘量的減小HTTP的Request請求數」準則咱們知道，那樣的確是不合理的，由於那樣會產生更多的HTTP的Request請求數。從而下降網頁的效率。因此，從提升網頁效率的角度上而言，咱們仍是應該將全部的css寫在同一個css文件中。可是問題又來了。那麼怎麼來很好的組織和規劃樣式表呢？這的確是個矛盾。我如今的作法是採用兩套版本。編輯版和發佈版。編輯版仍然使用多個css文件以便於規劃和組織。而等到發佈的時候，再將多個css文件合併到一個文件中去，從而達到減小HTTPRequest請求數的目的。

3：合併你的javascript文件。

緣由和處理方法同上，再也不贅言。

第二條：Use a Content Delivery Network 使用CDN

這個看上去好像很深奧的樣子，可是隻要結合中國的網絡特點，這個便不難理解了。「北方服務器」、「南方服務器」、「電信服務器」、「網通服務器」……這些詞聽起來是那麼熟悉和壓抑。若是，一個北京的電信用戶試圖從廣東的網通服務器上打開一個相似《壁紙合集》帖子的網頁時，你就能很深入的理解。
鑑於這個不是咱們開發人員力所能及的準則，因此這裏也就很少言了。

圖:這個圖也算有點中國特點了

第三條：Add an Expires Header 添加週期頭

這個也並不是開發人員來控制，而是網站服務器管理員的職責。因此，若是做爲開發人員的你不瞭解和明白也沒有關係。仍是把這個準則告訴公司的網站服務器管理員。

第四條：Gzip Components 啓用Gzip壓縮

這個你們應該比較熟悉。Gzip的思想就是把文件先在服務器端進行壓縮，而後再傳輸。這對於體積較大的純文字型的文件有特效。鑑於這也並不是開發人員，而是網站服務器管理員的工做範疇，這裏就不詳細講解了。若是你對此感興趣，能夠資訊貴公司的網站服務器管理人員。

第五條：Put CSS at the Top 把CSS樣式放在頁面的上方。

不管是HTML仍是XHTML仍是CSS都是解釋型的語言，而非編譯型的。因此CSS到上方的話，那麼瀏覽器解析結構的時候，就已經能夠對頁面進行渲染。這樣就不會出現，頁面結構光禿禿的先出來，而後CSS渲染，頁面又忽然華麗起來，這樣太具備「戲劇性」的頁面瀏覽體驗了。

第六條：Move Scripts to the Bottom 將腳本放在底部

緣由同第五條同樣。只是腳本通常是用來於用戶交互的。因此若是頁面尚未出來，用戶連頁面都不知道什麼樣子，那談交互簡直就是扯談。因此，腳本和CSS正好相反，腳本應該放在頁面的底部。

第七條：Avoid CSS Expressions 避免使用CSS中的Expressions

圖:CSS中的Expressions其實也是一種if判斷

首先有必要先說明一下CSS Expressions是什麼一個東西。其實它就像其它語言中的if……else……語句。這樣在CSS中就能夠進行簡單的邏輯判斷了。舉個簡單的例子——

<style>
input{background-color:expression((this.readOnly && this.readOnly==true)?"#0000ff":"#ff0000")}
</style>
<INPUT TYPE="text" NAME="">
<INPUT TYPE="text" NAME="" readonly="true">

這樣css就能夠根結一些狀況分別使用不一樣的樣式了。若是你對這個感興趣能夠到個人博客上閱讀相關的文章—— 《CSS中的expression系列文章》。可是CSS中Expressions 的代價倒是極高的。當你的頁面須要根據判斷來渲染效果的元素不少的時候，那麼你的瀏覽器將長期處於假死狀態，從而給用戶帶來極差的用戶體驗。

第八條：Make JavaScript and CSS External 將javascript和css獨立成外部文件

這一條好像和第一條有點矛盾。的確，若是從HTTP的request請求數來說的話，這樣作的確是下降了效率。可是之因此這麼作，是由於另一個重要的考慮因素——緩存。由於外部的引用文件會被瀏覽器緩存，因此若是javascript和css體積較大的時候，咱們將它們獨立成外部文件。這樣當用戶只要瀏覽一次之後，這些體積較大的js和css文件就能被緩存起來，從而極高地提升用戶再次訪問時的效率。

第九條：Reduce DNS Lookups 減小DNS查詢

DNS域名解析系統。你們都知道咱們之因此能記住那麼多的網址，是由於咱們記住的都是單詞，而非http://202.153.125.45這樣的東西，而幫咱們把那些單詞和202.153.125.45這樣的ip地址聯繫起來的就是DNS。那這一條對咱們到底有什麼真正意義上的指導意義呢？其實有兩條：
1：若是不是必須，請不要把網站放到兩臺服務器上。
2：網頁中的圖片、css文件、js文件、flash文件等等，不要太多的分散在不一樣的網絡空間中。這就是爲何那種只發一個網站中的壁紙圖片的帖子，要比壁紙圖片來源於不一樣網站的帖子顯示要快得多的緣由。

第十條：Minify JavaScript and CSS 減小JavaScript和CSS文件的體積

這點很好理解。在你的最終發佈版本中把沒有必要的空行、空格和註釋所有去掉。顯然手工去處理效率過低，好在網上處處都是用於壓縮這些東西的工具。壓縮JavaScript代碼體積的工具隨處可見，我便再也不列舉了，這裏我只提供一個用於壓縮css代碼體積的在線工具網站——http://www.cssdrive.com/index.php/main/csscompressor
它提供了多種壓縮方式，能夠適應多種要求。

第十一條：Avoid Redirects 避免跳轉

我只從網頁開發人員的角度來解讀此條。那麼咱們能夠解讀到什麼東西呢？2點——
1：「此域名已過時，5秒鐘之後，頁面將跳轉到http://www.xxxxxx.com/index.html頁面」，這句話看起來的確很熟悉。可是，我就奇怪了，爲何不直接連接到那個頁面呢？
2：一些連接地址請更明確的寫出來。例如:將http://justinyoung.cnblogs.com/ 寫成http://justinyoung.cnblogs.com （注意最後面一個「/」符號）。的確，這兩個網址都能訪問到個人博客，可是，事實上，它們是有區別的。http://justinyoung.cnblogs.com 的結果是個301響應，它會被從新指向http://justinyoung.cnblogs.com/ 。可是顯然，中間多浪費了一些時間。

第十二條 Remove Duplicate Scripts 移除重複的腳本

這個準則的道理很淺顯，可是真正在工做中，不少人卻由於「項目時間緊」、「太累了」、「初期沒有規劃好」……這樣的理由搪塞過去了。你，的確能夠找不少的理由不去處理這些多餘重複的腳本代碼，若是你的網站不須要更高的效率和後期維護的話。
也正是這點，我提醒你們一些，一些javascript框架、javascript包必定要慎用。至少要問一下：用了這個js kit 到底給咱們多少方便，提升了多少工做效率。而後，再與它由於多餘的、重複的代碼帶來的負面效果比較一下。

第十三條：Configure ETags 配置你的實體標籤

首先來說講什麼是Etag吧。Etag（Entity tags ）實體標籤。這個tag和你在網上常常看到的標籤雲那種tag有點區別。這個Etag不是給用戶用的，而是給瀏覽器緩存用的。Etag是服務器告訴瀏覽器緩存，緩存中的內容是否已經發生變化的一種機制。經過Etag，瀏覽器就能夠知道如今的緩存中的內容是否是最新的，需不須要從新從服務器上從新下載。這和「Last-Modified」的概念有點相似。很遺憾做爲網頁開發人員對此無能爲力。他依然是網站服務器人員的工做範疇。若是，你對此有興趣，能夠諮詢貴公司的網站服務器管理員。

第十四條：Make Ajax Cacheable 上面的準則也適用Ajax

如今的Ajax好像有點被神話了，好像網頁只要Ajax了，那麼就不存在效率問題了。其實這是一種誤解。拙劣的使用Ajax不會讓你的網頁效率更高，反而會下降你的網頁效率。Ajax的確是個好東西，可是請不要過度的神話它。使用Ajax的時候也要考慮上面的那些準則。

 

點擊【Components】菜單

這個視圖是一個頁面全部部件的信息列表。從中咱們能夠得知每一個部件的各類詳細信息。如：類型、URL、Expires數據、狀態、大小、讀取時間、ETag信息等等。經過對這個列表的分析，咱們就能夠知道究竟是什麼東西最耗費咱們的資源，從而有針對性的進行優化。

點擊【Statistics】菜單

這個視圖會告訴你頁面的整體統計信息。包括頁面大小、css樣式表大小、腳本文件大小、整體圖片大小、flash文件大小和css中用到的圖片文件大小。還會告訴你，哪些東西被緩存了，緩存了多少等等。