YSlow可以對網(wǎng)站的頁面進行分析择克，并告訴你為了提高網(wǎng)站性能小压，如何基于某些規(guī)則而進行優(yōu)化泥从。 YSlow可以分析任何網(wǎng)站，并為每一個規(guī)則產(chǎn)生一個整體報告萌抵，如果頁面可以進行優(yōu)化缰儿，則YSlow會列出具體的修改意見。
YSlow的安裝：
1露泊、安裝 firebug插件喉镰。針對不同的瀏覽器插件也是不同的，例如 針對chrome.插件名稱為：Firebug Lite for Google Chrome惭笑。官網(wǎng)下載地址為：https://chrome.google.com/webstore/search/firebug%20%20for%20chrome
2侣姆、安裝YSLOW插件，官網(wǎng)下載地址為：http://developer.yahoo.com/yslow/
點擊安裝即可沉噩。安裝后捺宗，YSlow按鈕會在 chrome的右上角顯示。
YSlow的使用
點擊YSlow按鈕川蒙，啟動插件蚜厉，點擊Run Test 測試當前頁面。在新彈出的界面中按照重要性顯示了影響此頁面效率的元素畜眨，其中A類評分為最高昼牛，F(xiàn)為最低。
一般來說提高網(wǎng)頁效率依照下面14條準則胶果。
第一條：Make Fewer HTTP Requests 盡可能的減少HTTP的Request請求數(shù)匾嘱。
80%的用戶響應時間都是浪費在前端。而這些時間主要又是因為下載圖片早抠、樣式表霎烙、JavaScript腳本、flash等文件造成的蕊连。減少這些資源文件的Request請求數(shù)將是提高網(wǎng)頁顯示效率的重點悬垃。
這里好像有個矛盾，就是如果我減少了很多的圖片甘苍，樣式尝蠕，腳本或者flash，那么網(wǎng)頁豈不是光禿禿的载庭，那多難看呢看彼？其實這是一個誤解。我們只是說盡量的減少囚聚，并沒有說完全不能使用靖榕。減少這些文件的Request請求數(shù)，當然也有一些技巧和建議的：
1：用一個大圖片代替多個小圖片顽铸。
這的確有點顛覆傳統(tǒng)的思維了茁计。以前我們一直以為多個小圖片的下載速度之和會小于一個大圖片的下載速度。但是現(xiàn)在利用httpwatch工具的對多個頁面進行分析后的結果表明事實并不是這樣谓松。
第一張圖是一個大小為40528bytes的337191px的大圖片的分析結果星压。
第二張圖是一個大小為13883bytes的28090px的小圖片的分析結果践剂。
一個大小為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娜膘，多數(shù)的時間是用來檢索緩存和確定鏈接是否有效的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%。
如果這些數(shù)據(jù)還不夠說服你的話颤枪，讓我們看看下面這張圖汗捡。這里列出了某個網(wǎng)頁中所有圖片中的花費時間示意圖。當然畏纲，里面的圖片有大有小扇住，規(guī)格不一。
大約80%以上的時間是用來檢索緩存和確定鏈接是否有效的Blocked時間盗胀。
其中藏青色的為傳輸文件花費的Reveive時間艘蹋，而前面白色的為檢索緩存和確認鏈接是否有效的Blocked時間。鐵一樣的事實告訴我們：
§ 大文件和小文件下載所需時間的確是不同的票灰，差異的絕對值不大女阀。而且下載所需時間占總耗費時間比例很小。
§ 大約80%以上的時間是用來檢索緩存和確定鏈接是否有效的Blocked時間屑迂。無論文件大小浸策，這個時間的花費大致是相同的。而且所占總耗費時間的比例是極大的惹盼。
§ 一個100k的大圖片總耗費時間絕對大于4個25k的小圖片的總耗費時間庸汗。而且主要差別就是4個小圖片的Blocked時間絕對大于1個大圖片的Blocked時間。
所以如果可能還是使用大圖片來替代過多的瑣碎的小圖片吧手报。這也是為什么翻轉(zhuǎn)門的效率要高于圖片替換實現(xiàn)的滑動門的原因蚯舱。
但是，請注意：也不能用太大的單張圖片掩蛤，因為那樣會影響到用戶體驗晓淀。例如個幾兆的背景圖片的使用絕對不是一個好主意。
2：合并你的css文件盏档。
我以前犯了一個錯誤，你在看我《樣式表的組織與規(guī)劃》的系列文章中會知道燥爷。當時蜈亩，我為了方便組織和規(guī)劃樣式表懦窘，將用于不同用途的樣式表文件分離開來，形成不同的css文件稚配。然后在頁面中根據(jù)需要引用多個css文件畅涂。根據(jù)“盡可能的減少HTTP的Request請求數(shù)”準則我們知道，那樣的確是不合理的道川，因為那樣會產(chǎn)生更多的HTTP的Request請求數(shù)午衰。從而降低網(wǎng)頁的效率。所以冒萄，從提高網(wǎng)頁效率的角度上而言臊岸，我們還是應該將所有的css寫在同一個css文件中。但是問題又來了尊流。那么怎么來很好的組織和規(guī)劃樣式表呢帅戒？這的確是個矛盾。我現(xiàn)在的做法是采用兩套版本崖技。編輯版和發(fā)布版逻住。編輯版仍然使用多個css文件以便于規(guī)劃和組織。而等到發(fā)布的時候迎献，再將多個css文件合并到一個文件中去瞎访，從而達到減少HTTPRequest請求數(shù)的目的。
3：合并你的javascript文件吁恍。
原因和處理方法同上扒秸，不再贅言。
第二條：Use a Content Delivery Network 使用CDN
這個看上去好像很深奧的樣子践盼，但是只要結合中國的網(wǎng)絡特色鸦采，這個便不難理解了」净茫“北方服務器”渔伯、“南方服務器”、“電信服務器”肄程、“網(wǎng)通服務器”……這些詞聽起來是那么熟悉和壓抑锣吼。如果，一個北京的電信用戶試圖從廣東的網(wǎng)通服務器上打開一個類似《壁紙合集》帖子的網(wǎng)頁時蓝厌，你就能很深刻的理解玄叠。
鑒于這個不是我們開發(fā)人員力所能及的準則，所以這里也就不多言了拓提。
第三條：Add an Expires Header 添加周期頭
這個也并非開發(fā)人員來控制读恃，而是網(wǎng)站服務器管理員的職責。所以，如果作為開發(fā)人員的你不了解和明白也沒有關系寺惫。還是把這個準則告訴公司的網(wǎng)站服務器管理員疹吃。
第四條：Gzip Components 啟用Gzip壓縮
這個大家應該比較熟悉。Gzip的思想就是把文件先在服務器端進行壓縮西雀，然后再傳輸萨驶。這對于體積較大的純文字型的文件有特效。鑒于這也并非開發(fā)人員艇肴，而是網(wǎng)站服務器管理員的工作范疇腔呜，這里就不詳細講解了。如果你對此感興趣再悼，可以資訊貴公司的網(wǎng)站服務器管理人員核畴。
第五條：Put CSS at the Top 把CSS樣式放在頁面的上方。
無論是HTML還是XHTML還是CSS都是解釋型的語言帮哈，而非編譯型的膛檀。所以CSS到上方的話，那么瀏覽器解析結構的時候娘侍，就已經(jīng)可以對頁面進行渲染咖刃。這樣就不會出現(xiàn)，頁面結構光禿禿的先出來憾筏，然后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 的代價卻是極高的。當你的頁面需要根據(jù)判斷來渲染效果的元素很多的時候遭铺，那么你的瀏覽器將長期處于假死狀態(tài)丽柿，從而給用戶帶來極差的用戶體驗恢准。
第八條：Make JavaScript and CSS External 將javascript和css獨立成外部文件
這一條好像和第一條有點矛盾。的確甫题，如果從HTTP的request請求數(shù)來講的話顷歌，這樣做的確是降低了效率。但是之所以這么做幔睬，是因為另外一個重要的考慮因素——緩存。因為外部的引用文件會被瀏覽器緩存芹扭，所以如果javascript和css體積較大的時候麻顶，我們將它們獨立成外部文件。這樣當用戶只要瀏覽一次以后舱卡，這些體積較大的js和css文件就能被緩存起來辅肾，從而極高地提高用戶再次訪問時的效率。
第九條：Reduce DNS Lookups 減少DNS查詢
DNS域名解析系統(tǒng)轮锥。大家都知道我們之所以能記住那么多的網(wǎng)址矫钓，是因為我們記住的都是單詞，而非http://202.153.125.45這樣的東西舍杜，而幫我們把那些單詞和202.153.125.45這樣的ip地址聯(lián)系起來的就是DNS新娜。那這一條對我們到底有什么真正意義上的指導意義呢？其實有兩條：
1：如果不是必須既绩，請不要把網(wǎng)站放到兩臺服務器上概龄。
2：網(wǎng)頁中的圖片、css文件饲握、js文件私杜、flash文件等等，不要太多的分散在不同的網(wǎng)絡空間中救欧。這就是為什么那種只發(fā)一個網(wǎng)站中的壁紙圖片的帖子衰粹，要比壁紙圖片來源于不同網(wǎng)站的帖子顯示要快得多的原因。
第十條：Minify JavaScript and CSS 減少JavaScript和CSS文件的體積
這點很好理解笆怠。在你的最終發(fā)布版本中把沒有必要的空行铝耻、空格和注釋全部去掉。顯然手工去處理效率太低骑疆，好在網(wǎng)上到處都是用于壓縮這些東西的工具田篇。壓縮JavaScript代碼體積的工具隨處可見，我便不再列舉了箍铭，這里我只提供一個用于壓縮css代碼體積的在線工具網(wǎng)站——http://www.cssdrive.com/index.php/main/csscompressor
它提供了多種壓縮方式泊柬，可以適應多種要求。
第十一條：Avoid Redirects 避免跳轉(zhuǎn)
我只從網(wǎng)頁開發(fā)人員的角度來解讀此條诈火。那么我們可以解讀到什么東西呢兽赁？2點——
1：“此域名已過期状答，5秒鐘以后，頁面將跳轉(zhuǎn)到http://www.xxxxxx.com/index.html頁面”刀崖，這句話看起來的確很熟悉惊科。但是，我就奇怪了亮钦，為什么不直接鏈接到那個頁面呢馆截？
2：一些鏈接地址請更明確的寫出來。例如:將http://justinyoung.cnblogs.com/ 寫成http://justinyoung.cnblogs.com （注意最后面一個“/”符號）蜂莉。的確蜡娶，這兩個網(wǎng)址都能訪問到我的博客，但是映穗，事實上窖张，它們是有區(qū)別的。http://justinyoung.cnblogs.com 的結果是個301響應蚁滋，它會被重新指向http://justinyoung.cnblogs.com/ 宿接。但是顯然，中間多浪費了一些時間辕录。
第十二條 Remove Duplicate Scripts 移除重復的腳本
這個準則的道理很淺顯睦霎，但是真正在工作中，很多人卻因為“項目時間緊”踏拜、“太累了”碎赢、“初期沒有規(guī)劃好”……這樣的理由搪塞過去了。你速梗，的確可以找很多的理由不去處理這些多余重復的腳本代碼肮塞，如果你的網(wǎng)站不需要更高的效率和后期維護的話。
也正是這點姻锁，我提醒大家一些枕赵，一些javascript框架、javascript包一定要慎用位隶。至少要問一下：用了這個js kit 到底給我們多少方便拷窜，提高了多少工作效率。然后涧黄，再與它因為多余的篮昧、重復的代碼帶來的負面效果比較一下。
第十三條：Configure ETags 配置你的實體標簽
首先來講講什么是Etag吧笋妥。Etag（Entity tags ）實體標簽懊昨。這個tag和你在網(wǎng)上經(jīng)常看到的標簽云那種tag有點區(qū)別春宣。這個Etag不是給用戶用的酵颁，而是給瀏覽器緩存用的嫉你。Etag是服務器告訴瀏覽器緩存，緩存中的內(nèi)容是否已經(jīng)發(fā)生變化的一種機制躏惋。通過Etag幽污，瀏覽器就可以知道現(xiàn)在的緩存中的內(nèi)容是不是最新的，需不需要重新從服務器上重新下載簿姨。這和“Last-Modified”的概念有點類似距误。很遺憾作為網(wǎng)頁開發(fā)人員對此無能為力。他依然是網(wǎng)站服務器人員的工作范疇扁位。如果深寥，你對此有興趣，可以咨詢貴公司的網(wǎng)站服務器管理員贤牛。
第十四條：Make Ajax Cacheable 上面的準則也適用Ajax
現(xiàn)在的Ajax好像有點被神話了，好像網(wǎng)頁只要Ajax了则酝，那么就不存在效率問題了殉簸。其實這是一種誤解。拙劣的使用Ajax不會讓你的網(wǎng)頁效率更高沽讹，反而會降低你的網(wǎng)頁效率般卑。Ajax的確是個好東西，但是請不要過分的神話它爽雄。使用Ajax的時候也要考慮上面的那些準則蝠检。
點擊【Components】菜單
這個視圖是一個頁面所有部件的信息列表。從中我們可以得知每個部件的各種詳細信息挚瘟。如：類型叹谁、URL、Expires數(shù)據(jù)乘盖、狀態(tài)焰檩、大小、讀取時間订框、ETag信息等等析苫。通過對這個列表的分析，我們就可以知道到底是什么東西最耗費我們的資源穿扳，從而有針對性的進行優(yōu)化衩侥。
點擊【Statistics】菜單
這個視圖會告訴你頁面的總體統(tǒng)計信息。包括頁面大小矛物、css樣式表大小茫死、腳本文件大小、總體圖片大小泽谨、flash文件大小和css中用到的圖片文件大小璧榄。還會告訴你特漩，哪些東西被緩存了，緩存了多少等等骨杂。
