Yslow

主要有12條：

 

1. Make fewer HTTP requests 儘量少的http請求。。咱們有141個請求（其中15個JS請求，3個CSS請求，47個CSS background images請求），多的可怕。思考了下，爲何把這個三種請求過多列爲對頁面加載的重要不利因素呢，而過多的IMG請求並無列爲不利因素呢？

發現原來這些請求都是能夠避免的。

15個JS和3個CSS徹底能夠經過特殊的辦法進行合併（這個技術部已經幫咱們解決了，實在是太感謝了，嘿嘿。），這樣合併之後，通常狀況下頁面上只會出現一個JS和一個CSS（對JS的封裝得有必定的要求）。

可是47個CSS background images請求改怎麼解決呢？爲何頁面上的純IMG請求時合理的，而CSS background images請求過多就是不利因素了呢。這個我想了好久，總算明白，原來是這樣的：

通常頁面上的ICON，欄目背景啊，圖片按鈕啊，咱們都會用圖片CSS背景來實現，而通常這個圖片CSS背景用到的圖片都是比較小的，因此徹底能夠把這些圖片合併成一個相對比較大的圖片，這樣頁面上只會出現一個CSS background images請求，最多也就2-3個。後來仔細看了下雅虎美國的頁面，他們的確也是這樣作的，雖然這樣作須要花必定的時間來有規則的合併這些ICON，欄目背景，圖片按鈕，以方便CSS調用，可是這樣作絕對是合算的，並且是有必要的，YSlow也是極力推薦的。

 

2. Use a CDN這項咱們的評分是F級，最低。說實在的，我剛開始什麼是CDN都不知道。後來查了GOODLE才知道。CDN的全稱是Content Delivery Network，即內容分發網絡。其目的是經過在現有的Internet中增長一層新的網絡架構，將網站的內容發佈到最接近用戶的網絡」邊緣」，使用戶能夠就近取得所需的內容，解決Internet網絡擁擠的情況，提升用戶訪問網站的響應速度。從技術上全面解決因爲網絡帶寬小、用戶訪問量大、網點分佈不均等緣由所形成的用戶訪問網站響應速度慢的問題。

看來上述的解釋後，基本上明白了CDN是怎麼回事，後來諮詢了下中文站點SA，得知咱們網站目前的確尚未作CDN的優化，可是聽說咱們有更加先進的技術來解決相似的問題（具體什麼技術那就保密了），可是畢竟CDN也是個至關不錯的技術，因此在咱們先進技術的基礎上在作CDN優化，確定比如今更好，嘿嘿。聽說SA明年會作幾個點的CND。

 

3. Add an Expires header設置過時的HTTP Header.設置Expires Header能夠將腳本, 樣式表, 圖片, Flash等緩存在瀏覽器的Cache中.

其實咱們網站也作了這個優化，至少圖片在這個上作過優化，可是沒有作徹底。咱們的CSS和JS都尚未作過優化，卻是外部引入的一個廣告JS作了，呵呵。其實設置過時的HTTP Header 更應該作在腳本, 樣式表, Flash上.不過聽說這個SA也是沒有作的，可是有必定的風險，由於JS和CSS是有必定的邏輯，若是服務器端和客戶端都存在緩存的話，萬一出了什麼問題，對咱們之後查找問題的所在和增長難度，不過我想二者中是能夠權衡和並存的。

 

4. Gzip components 對咱們的頁面內容進行Gzip格式的壓縮，Gzip格式是一種很廣泛的壓縮技術，幾乎全部的瀏覽器都有解壓Gzip格式的能力，並且它能夠壓縮的比例很是大，通常壓縮率爲85%，就是說服務器端100K的頁面能夠壓縮到25K左右的Gzip格式的數據發給客戶端，客戶端收到Gzip格式的數據後自動解壓縮後顯示頁面。

這點咱們網站基本上是100%作到了，可是咱們這項的評分並無達到想象中的A級，緣由是出在咱們的外部連接，好比咱們首頁，有外部的廣告投放JS，這個JS說擁有的網站是沒有作過GZIP優化，連累了咱們網站，因此咱們也只有B，或者C級：（

 

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

其實這個原則咱們通常都遵照的，若是把CSS外部連接做爲邏輯的一部分出如今頁面頭部如下，我我的以爲這個自己就是個錯誤。還好，咱們的頁面基本上都作到了，但是有些頁面好比LIST頁面，仍是出現了和邏輯掛鉤的CSS連接，緣由是爲了解決一些原本就不合理的產品邏輯。因此，咱們WEB前端工程師有義務杜絕這些不合理的產品邏輯破壞咱們的頁面結果及頁面加載速度，不能爲了實現而實現。

 

 6. Put JS at the bottom 把Javascript腳本儘可能放到頁面底部加載。

一開始爲覺得Javascript腳本儘可能放到頁面底部加載，是指全部的JS腳本都要放到底部，後來才發現，並不徹底是這樣，這裏所指的腳本是指那些在加載過程當中要執行的腳本，因此通常的處理辦法仍是頁面頭部引入JS連接，頁面底部執行JS腳本程序。爲何要這麼作呢？呵呵，其實很簡單，爲了實現最大的下載並行，頁面加載初期作的事，最好只有下載，HTML的下載，CSS的下載,JS的下載，等下載完成後再去實現頁面渲染，JS腳本運行。這個方面咱們還須要努力，不少頁面咱們在加載過程當中運行了一部分腳本，或許是爲了實現一些功能，沒有辦法，不過或許有更好的辦法來替代呢。。。

 

7. Avoid CSS expressions 避免CSS表達式

其實在CSS中運行表達式和頁面加載中運行大量的JS腳本差很少，或許還更慢，並且還不兼容，雖然可使咱們在頁面邏輯簡單很多，可是咱們徹底能夠拋棄之。這個點，咱們的頁面基本上都作到了。不過說實話，CSS表達式，嘿嘿，我之前還不知道有這麼回事。慚愧。哈哈。

 

8. Reduce DNS lookups 儘量少的DNS查找。

這項咱們作的不是很好。D級，有9個域名，通常不要超過4個。不過這個主要是服務器架構上的問題，咱們也無能爲力，如今單單首頁的廣告域名就有好幾個，好耶的廣告域名，雅虎的廣告域名，淘寶店廣告域名，打點的域名。若是去掉這些，咱們其實仍是夠用的，一個主域名，一個圖片的，一個STYLE的，最多加上IFREAM的恰好4個。

 

9. Minify JS 對Javascript代碼進行壓縮。

這點我很早之前就對此關注了，也找到了一個不錯的壓縮工具，yuicompressor，雅虎美國開發的JAVA壓縮包yuicompressor.jar。壓縮的至關完美，不只把代碼間的空格換行給去除掉了，並且對變量名，北部方法名都進行的簡化，無心中實現了混淆腳本的做用。如今咱們僅僅作到了JS合併，並無對齊進行壓縮，若是我用yuicompressor手工的去壓縮，雖然實現了JS壓縮，可是給咱們本身的維護量增長了一倍，由於咱們須要維護2套JS腳本，一套是壓縮前的（調試用的），一套是壓縮後（發佈到網上的），並且要保證2套代碼一致。因此最完美的作法是在發佈的時候實現JS腳本合併，並對其用yuicompressor進行壓縮，而後發佈到晚上，把關鍵點移到發佈的時候，這樣咱們只須要關心一套JS腳本（發佈前的版本）。並且我以爲這個方案徹底是行動通的。

 

10. Avoid redirects 避免重定向（跳轉）

怎麼理解這點呢？

咱們常常遇到的一種作法，註冊成功後，旺旺會有一個頁面提示「你已經註冊成功，3秒後將自動跳轉到XX頁面」。我就以爲很奇怪，你爲何不直接跳轉到該去的頁面？還有一種，咱們你們很是熟悉，通常咱們頁面的連接都寫成：http://china.alibaba.com或者http://china.alibaba.com/,有人會問，有區別嗎？我明確的告訴你們，有！服務器若是接收到的URL是http://china.alibaba.com，它會自動從新定向到http://china.alibaba.com/，雖然最後都打開了阿里巴巴中文站的首頁，可是前者比後者多走了一步,重定向，顯然多多少少浪費了必定的時間。因此之後咱們加URL連接的時候，別忘了把最後的「/」給加上去。

 

11. Remove duplicate scripts  去除重複的腳本

這個其實沒有什麼好說的，你們都應該毫無條件的去遵照，可是越是明顯，越是簡單的事，咱們每每會作很差，固然，不少理由的，項目時間太緊張了等等，致使代碼很亂，不少重複的地方。其實誰都知道重負很差，不過還好，咱們的頁面重複的腳本代碼很少（至少一個頁面裏面，呵呵）。不過，我到是但願，咱們不只要作到一個頁面腳本不重複，並且要作到N個頁面，腳本要重用。

 

12. Configure ETags  

這個相似last modified，客戶端總會返回etag到服務端作驗證，看看資源是否發生了變化，若是沒有就返回304。

但他完成了一些last modified不能的，以下：

a、一些文件也許會週期性的更改，可是他的內容並不改變(僅僅改變的修改時間)，這個時候咱們並不但願客戶端認爲這個文件被修改了，而從新GET;

b、某些文件修改很是頻繁，好比在秒如下的時間內進行修改，(比方說1s內修改了N次)，If-Modified-Since能檢查到的粒度是s級的，這種修改沒法判斷(或者說UNIX記錄MTIME只能精確到秒)

c、某些服務器不能精確的獲得文件的最後修改時間；

 

Etag由服務器端生成，客戶端經過If-Match或者說If-None-Match這個條件判斷請求來驗證資源是否修改。常見的是使用If-None-Match.請求一個文件的流程可能以下：

====第一次請求===

1.客戶端發起 HTTP GET 請求一個文件；

2.服務器處理請求，返回文件內容和一堆Header，固然包括Etag(例如"2e681a-6-5d044840")(假設服務器支持Etag生成和已經開啓了Etag).狀態碼200

====第二次請求===

1.客戶端發起 HTTP GET 請求一個文件，注意這個時候客戶端同時發送一個If-None-Match頭，這個頭的內容就是第一次請求時服務器返回的Etag：2e681a-6-5d044840

2.服務器判斷髮送過來的Etag和計算出來的Etag匹配，所以If-None-Match爲False，不返回200，返回304，客戶端繼續使用本地緩存；

流程很簡單，問題是，若是服務器又設置了Cache-Control:max-age和Expires呢，怎麼辦？

答案是同時使用，也就是說在徹底匹配If-Modified-Since和If-None-Match即檢查完修改時間和Etag以後，服務器才能返回304.(不要陷入到底使用誰的問題怪圈)

 

1三、Make AJAX cacheable

雖然ajax是異步的，但不能保證不會等待異步的這段時間，不過爲避免重複的ajax請求，加上緩存也是件好事吧

 

1四、Use GET for AJAX requests

用GET方式進行AJAX請求。Get方法和服務器只有一次交互（發送數據），而Post要兩次（發送頭部再發送數據）。

 

1五、Reduce the number of DOM elements

減小DOM元素數量。複雜的頁面結構意味着更長的下載及響應時間，更合理更高效的使用標籤來架構頁面，是好的前端的必備條件。

 

1六、Avoid HTTP 404 (Not Found) error

避免404錯誤頁（非搜索結果）。

 

1七、Reduce cookie size

減少cooki體積，博客通常不須要考慮。

 

1八、Use cookie-free domains

使用無Cookie的域名。對靜態組件的Cookie讀取是一種浪費，使用另外一個無Cookie的域名來存放你的靜態組件式一個好方法，或者也能夠在Cookie中只存放帶www的域名。

這裏是有關靜態服務器的問題，主要是指一些靜態文件好比說圖片、CSS等等，若是沒用二級域名，那麼在請求這些的時候會發送cookie下的域名，但Server又不會理他，因此會浪費帶寬和時間。

若是設置了泛域名，那隻能從新申請一個域名來作靜態的了。

好比說YAHOO，他的靜態文件都在 yimg.com 上，客戶端請求靜態文件的時候，減小了 Cookie 的反覆傳輸對主域名的影響

 

 

1九、Avoid AlphaImageLoader filter

避免過濾器的使用。若是須要Alpha透明，不要使用Alpha Image Loader，它效率低下並且只對IE6及如下的版本適用，用PNG8圖片。若是你非要使用，加上_filter以避免影響IE7以上的用戶。

 

20、Do not scale images in HTML

不要在HTML中縮放圖片。圖片要用多大的就用多大的，1000x1000的圖片被width=」100″height=」100″之後，自己的體積是不會減小的。

 

2一、Make favicon small and cacheable

壓縮favicon. ico的體積並緩存。通常來講favicon. ico的大小都是16x16，體積1至2k。

 

2二、Make JS and CSS external–將CSS和JS使用外部的獨立文件。

看起來跟第1條有點矛盾，不過這應該看具體狀況了。javascript和css都有緩存，獨立成外部文件的話，有利於提升用戶再次訪問時的效率。而某些 大站好比yahoo，會把CSS及JS都寫在頁面裏，那是由於訪問量太大，儘量的減小請求數。若是你的網站訪問量還不是那麼地驚人的話，仍是獨立出來比 較好。