?YSlow是yahoo美國開發(fā)的一個頁面評分插件，非常的棒，從中我們可以看出我們頁面上的很多不足，并且可以知道我們改怎么卻改進(jìn)和優(yōu)化。

仔細(xì)研究了下YSlow跌評分規(guī)則。

主要有12條：

1.?Make fewer HTTP requests?盡可能少的http請求。。我們有141個請求（其中15個JS請求，3個CSS請求，47個CSS background p_w_picpaths請求），多的可怕。思考了下，為什么把這個三種請求過多列為對頁面加載的重要不利因素呢，而過多的IMG請求并沒有列為不利因素呢？

發(fā)現(xiàn)原來這些請求都是可以避免的。

15個JS和3個CSS完全可以通過特殊的辦法進(jìn)行合并（這個技術(shù)部已經(jīng)幫我們解決了，實在是太感謝了，嘿嘿。），這樣合并以后，一般情況下頁面上只會出現(xiàn)一個JS和一個CSS（對JS的封裝得有一定的要求）。

但是47個CSS background p_w_picpaths請求改怎么解決呢？為什么頁面上的純IMG請求時合理的，而CSS background p_w_picpaths請求過多就是不利因素了呢。這個我想了很久，總算明白，原來是這樣的：

一般頁面上的ICON，欄目背景啊，圖片按鈕啊，我們都會用圖片CSS背景來實現(xiàn)，而一般這個圖片CSS背景用到的圖片都是比較小的，所以完全可以把這些圖片合并成一個相對比較大的圖片，這樣頁面上只會出現(xiàn)一個CSS background p_w_picpaths請求，最多也就2-3個。后來仔細(xì)看了下雅虎美國的頁面，他們的確也是這樣做的，雖然這樣做需要花一定的時間來有規(guī)則的合并這些ICON，欄目背景，圖片按鈕，以方便CSS調(diào)用，但是這樣做絕對是合算的，而且是有必要的，YSlow也是極力推薦的。

2.Use a CDN?這項我們的評分是F級，最低。說實在的，我剛開始什么是CDN都不知道。后來查了GOODLE才知道。CDN的全稱是Content Delivery Network，即內(nèi)容分發(fā)網(wǎng)絡(luò)。其目的是通過在現(xiàn)有的Internet中增加一層新的網(wǎng)絡(luò)架構(gòu)，將網(wǎng)站的內(nèi)容發(fā)布到最接近用戶的網(wǎng)絡(luò)”邊緣”，使用戶可以就近取得所需的內(nèi)容，解決Internet網(wǎng)絡(luò)擁擠的狀況，提高用戶訪問網(wǎng)站的響應(yīng)速度。從技術(shù)上全面解決由于網(wǎng)絡(luò)帶寬小、用戶訪問量大、網(wǎng)點分布不均等原因所造成的用戶訪問網(wǎng)站響應(yīng)速度慢的問題。

看來上述的解釋后，基本上明白了CDN是怎么回事，后來咨詢了下中文站點SA，得知我們網(wǎng)站目前的確還沒有做CDN的優(yōu)化，但是據(jù)說我們有更加先進(jìn)的技術(shù)來解決類似的問題（具體什么技術(shù)那就保密了），但是畢竟CDN也是個相當(dāng)不錯的技術(shù)，所以在我們先進(jìn)技術(shù)的基礎(chǔ)上在做CDN優(yōu)化，肯定比現(xiàn)在更好，嘿嘿。據(jù)說SA明年會做幾個點的CND。

3.?Add an Expires header?設(shè)置過期的HTTP Header.設(shè)置Expires Header可以將腳本, 樣式表, 圖片, Flash等緩存在瀏覽器的Cache中.

其實我們網(wǎng)站也做了這個優(yōu)化，至少圖片在這個上做過優(yōu)化，但是沒有做完全。我們的CSS和JS都還沒有做過優(yōu)化，倒是外部引入的一個廣告JS做了，呵呵。其實設(shè)置過期的HTTP Header 更應(yīng)該做在腳本, 樣式表, Flash上.不過據(jù)說這個SA也是沒有做的，但是有一定的風(fēng)險，因為JS和CSS是有一定的邏輯，如果服務(wù)器端和客戶端都存在緩存的話，萬一出了什么問題，對我們以后查找問題的所在和增加難度，不過我想兩者中是可以權(quán)衡和并存的。

4.?Gzip components?對我們的頁面內(nèi)容進(jìn)行Gzip格式的壓縮，Gzip格式是一種很普遍的壓縮技術(shù)，幾乎所有的瀏覽器都有解壓Gzip格式的能力，而且它可以壓縮的比例非常大，一般壓縮率為85%，就是說服務(wù)器端100K的頁面可以壓縮到25K左右的Gzip格式的數(shù)據(jù)發(fā)給客戶端，客戶端收到Gzip格式的數(shù)據(jù)后自動解壓縮后顯示頁面。

這點我們網(wǎng)站基本上是100%做到了，但是我們這項的評分并沒有達(dá)到想象中的A級，原因是出在我們的外部鏈接，比如我們首頁，有外部的廣告投放JS，這個JS說擁有的網(wǎng)站是沒有做過GZIP優(yōu)化，連累了我們網(wǎng)站，所以我們也只有B，或者C級。

5.?Put CSS at the top?把CSS外部鏈接放到頁面的頂部。

其實這個原則我們一般都遵守的，如果把CSS外部鏈接作為邏輯的一部分出現(xiàn)在頁面頭部以下，我個人覺得這個本身就是個錯誤。還好，我們的頁面基本上都做到了，可是有些頁面比如LIST頁面，還是出現(xiàn)了和邏輯掛鉤的CSS鏈接，原因是為了解決一些本來就不合理的產(chǎn)品邏輯。所以，我們WEB前端工程師有義務(wù)杜絕這些不合理的產(chǎn)品邏輯破壞我們的頁面結(jié)果及頁面加載速度，不能為了實現(xiàn)而實現(xiàn)。

6.?Put JS at the bottom?把Javascript腳本盡量放到頁面底部加載。

一開始為以為Javascript腳本盡量放到頁面底部加載，是指所有的JS腳本都要放到底部，后來才發(fā)現(xiàn)，并不完全是這樣，這里所指的腳本是指那些在加載過程中要執(zhí)行的腳本，所以一般的處理辦法還是頁面頭部引入JS鏈接，頁面底部執(zhí)行JS腳本程序。為什么要這么做呢？呵呵，其實很簡單，為了實現(xiàn)最大的下載并行，頁面加載初期做的事，最好只有下載，HTML的下載，CSS的下載,JS的下載，等下載完成后再去實現(xiàn)頁面渲染，JS腳本運行。這個方面我們還需要努力，很多頁面我們在加載過程中運行了一部分腳本，或許是為了實現(xiàn)一些功能，沒有辦法，不過或許有更好的辦法來替代呢。。。

7.?Avoid CSS expressions?避免CSS表達(dá)式

其實在CSS中運行表達(dá)式和頁面加載中運行大量的JS腳本差不多，或許還更慢，而且還不兼容，雖然可以使我們在頁面邏輯簡單不少，但是我們完全可以拋棄之。這個點，我們的頁面基本上都做到了。不過說實話，CSS表達(dá)式，嘿嘿，我以前還不知道有這么回事。慚愧。哈哈。

9.?Reduce DNS lookups?盡可能少的DNS查找。

這項我們做的不是很好。D級，有9個域名，一般不要超過4個。不過這個主要是服務(wù)器架構(gòu)上的問題，我們也無能為力，現(xiàn)在單單首頁的廣告域名就有好幾個，好耶的廣告域名，雅虎的廣告域名，淘寶店廣告域名，打點的域名。如果去掉這些，我們其實還是夠用的，一個主域名，一個圖片的，一個STYLE的，最多加上IFREAM的剛好4個。

10.?Minify JS 對Javascript?代碼進(jìn)行壓縮。

這點我很早以前就對此關(guān)注了，也找到了一個不錯的壓縮工具，yuicompressor，雅虎美國開發(fā)的JAVA壓縮包yuicompressor.jar。壓縮的相當(dāng)完美，不僅把代碼間的空格換行給去除掉了，而且對變量名，北部方法名都進(jìn)行的簡化，無意中實現(xiàn)了混淆腳本的作用。現(xiàn)在我們僅僅做到了JS合并，并沒有對齊進(jìn)行壓縮，如果我用yuicompressor手工的去壓縮，雖然實現(xiàn)了JS壓縮，但是給我們自己的維護(hù)量增加了一倍，因為我們需要維護(hù)2套JS腳本，一套是壓縮前的（調(diào)試用的），一套是壓縮后（發(fā)布到網(wǎng)上的），而且要保證2套代碼一致。所以最完美的做法是在發(fā)布的時候?qū)崿F(xiàn)JS腳本合并，并對其用yuicompressor進(jìn)行壓縮，然后發(fā)布到晚上，把關(guān)鍵點移到發(fā)布的時候，這樣我們只需要關(guān)心一套JS腳本（發(fā)布前的版本）。而且我覺得這個方案完全是行動通的。

11.?Avoid redirects?避免重定向（跳轉(zhuǎn)）

怎么理解這點呢？

我們經(jīng)常遇到的一種做法，注冊成功后，旺旺會有一個頁面提示“你已經(jīng)注冊成功，3秒后將自動跳轉(zhuǎn)到XX頁面”。我就覺得很奇怪，你為什么不直接跳轉(zhuǎn)到該去的頁面？還有一種，我們大家非常熟悉，一般我們頁面的鏈接都寫成：http://china.alibaba.com或者h(yuǎn)ttp://china.alibaba.com/,有人會問，有區(qū)別嗎？我明確的告訴大家，有！服務(wù)器如果接收到的URL是http://china.alibaba.com，它會自動重新定向到http://china.alibaba.com/，雖然最后都打開了阿里巴巴中文站的首頁，但是前者比后者多走了一步,重定向，顯然多多少少浪費了一定的時間。所以以后我們加URL鏈接的時候，別忘了把最后的“/”給加上去。

12.?Remove duplicate scripts? 去除重復(fù)的腳本

這個其實沒有什么好說的，大家都應(yīng)該毫無條件的去遵守，但是越是明顯，越是簡單的事，我們往往會做不好，當(dāng)然，很多理由的，項目時間太緊張了等等，導(dǎo)致代碼很亂，很多重復(fù)的地方。其實誰都知道重負(fù)不好，不過還好，我們的頁面重復(fù)的腳本代碼不多（至少一個頁面里面，呵呵）。不過，我到是希望，我們不僅要做到一個頁面腳本不重復(fù)，而且要做到N個頁面，腳本要重用。

13.Configure ETags? 這個好像是服務(wù)器端配置的問題，我不太懂，也就不亂說了，怕把大家給誤導(dǎo)了。

總共13個，但是看了YAHOO的官方說明，好像還有一個AJAX CACHE(AJAX 緩存)。我倒是覺得這個很重要，隨著我們AJAX應(yīng)用的廣泛，AJAX 緩存這個概念一定要時刻在我們腦子中，AJAX是個好東西，但是重復(fù)的數(shù)據(jù)，無休止的向后臺申請，絕對是個錯誤（不僅是速度上還是對服務(wù)器壓力上來說），所以我們就要對我們已經(jīng)申請到的數(shù)據(jù)進(jìn)行緩存，當(dāng)?shù)?次用到的時候，就直接從緩存中取，不要在去訪問我們寶貴的服務(wù)器資源了。其實這個思想不僅僅適合AJAX，在所有有數(shù)據(jù)復(fù)用的應(yīng)用中都應(yīng)該考慮到。

YSLOW就分析到這里完畢了，或許有些地方分析的不是很正確，或許有人分析的比我更早，更好，但是這些的確是我從工作中去積累，發(fā)現(xiàn)的，并很多都實際應(yīng)用到工作中去了，順便說下，嘿嘿，LIST頁面進(jìn)行優(yōu)化后，在0.92版本的YSLOW評分將達(dá)到76分，甚至80分，相當(dāng)于0.8版本的90分以上。不過評分畢竟是評分，關(guān)鍵還是速度。（轉(zhuǎn)自aliued.cn）

轉(zhuǎn)載于:https://blog.51cto.com/apptree/622720

總結(jié)

以上是生活随笔為你收集整理的用YSlow分析我们页面的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。