yslow提高網頁的技巧

網站最基本的東西是什麼？

網站最基本的東西是什麼？

——内容？SEO（搜尋引擎優化）？UE（使用者體驗）？都不對！是速度！

内容再豐富的網站，如果慢到無法通路也是毫無意義的； SEO做的再好的網站，如果搜尋蜘蛛抓不到也是白搭； UE設計的再人性化的網站，如果使用者連看都看不到也是空談。

是以網頁的效率絕對是最值得關注的方面。如何才能提高一個網頁的效率呢？Steve Souders(Steve Souders的資料http://www.oreillynet.com/pub/au/2951)提出的提高網頁效率的14條準則，而這些準則也将是我們下篇中介紹到的YSlow工具的理論基礎：

• Make Fewer HTTP Requests
• Use a Content Delivery Network
• Add an Expires Header
• Gzip Components
• Put CSS at the Top
• Move Scripts to the Bottom
• Avoid CSS Expressions
• Make JavaScript and CSS External
• Reduce DNS Lookups
• Minify JavaScript
• Avoid Redirects
• Remove Duplicate Scripts
• Configure ETags
• Make Ajax Cacheable

這裡我們将逐一的講解這些準則,對其中開發者密切相關的準則我将詳細講解。小弟個人技術實在有限，錯誤和無知在所難免，還請高人指點。

第一條：Make Fewer HTTP Requests 盡可能的減少HTTP的Request請求數。

80%的使用者響應時間都是浪費在前端。而這些時間主要又是因為下載下傳圖檔、樣式表、JavaScript腳本、flash等檔案造成的。減少這些資源檔案的Request請求數将是提高網頁顯示效率的重點。

這裡好像有個沖突，就是如果我減少了很多的圖檔，樣式，腳本或者flash，那麼網頁豈不是光秃秃的，那多難看呢？其實這是一個誤解。我們隻是說盡量的減少，并沒有說完全不能使用。減少這些檔案的Request請求數，當然也有一些技巧和建議的：

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

這的确有點颠覆傳統的思維了。以前我們一直以為多個小圖檔的下載下傳速度之和會小于一個大圖檔的下載下傳速度。但是現在利用httpwatch工具的對多個頁面進行分析後的結果表明事實并不是這樣。

第一張圖是一個大小為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……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的時候也要考慮上面的那些準則。

後記：

當然，上面的這些也隻是供你參考的理論上的準則。具體的情況還是要具體的去對待。理論和準則隻是用來指導現實工作的，卻是萬萬不可死記硬套。