謹記：80%-90%的終端響應時間是花費在下載頁面中的圖片，樣式表，腳本，flash等；
詳細的解釋來這里查：
英文版：http://developer.yahoo.com/performance/rules.html
中文版：http://www.survivalescaperooms.com/article/4877
也可以直接firebug上一項項比對，如下圖：
1、盡量減少HTTP請求個數——須權衡
合并圖片（如css sprites，內置圖片使用數據）、合并CSS、JS，這一點很重要，但是要考慮合并后的文件體積。
2、使用CDN（內容分發網絡）
這里可以關注CDN的三類實現：鏡像、高速緩存、專線，以及智能路由器和負載均衡；
3、為文件頭指定Expires或Cache-Control，使內容具有緩存性。
區分靜態內容和動態內容，避免以后頁面訪問中不必要的HTTP請求。
4、避免空的src和href
留意具有這兩個屬性的標簽如link，script，img，iframe等；
5、使用gzip壓縮內容
Gzip壓縮所有可能的文件類型以來減少文件體積
6、把CSS放到頂部
實現頁面有秩序地加載，這對于擁有較多內容的頁面和網速較慢的用戶來說更為重要，同時，HTML規范清楚指出樣式表要放包含在頁面的<head />區域內；
7、把JS放到底部
HTTP/1.1 規范建議，瀏覽器每個主機名的并行下載內容不超過兩個，而問題在于腳本阻止了頁面的平行下載，即便是主機名不相同
8、避免使用CSS表達式
頁面顯示和縮放，滾動、乃至移動鼠標時，CSS表達式的計算頻率是我們要關注的。可以考慮一次性的表達式或者使用事件句柄來代替CSS表達式。
9、將CSS和JS放到外部文件中
我們需要權衡內置代碼帶來的HTTP請求減少與通過使用外部文件進行緩存帶來的好處的折中點。
10、減少DNS查找次數
我們需要權衡減少 DNS查找次數和保持較高程度并行下載兩者之間的關系。
11、精簡CSS和JS
目的就是減少下載的文件體積，可考慮壓縮工具JSMin和YUI Compressor。
12、避免跳轉
為了確保“后退”按鈕可以正確地使用，使用標準的 3XXHTTP狀態代碼；同域中注意避免反斜杠 “/” 的跳轉；
跨域使用 Alias或者 mod_rewirte建立 CNAME（保存一個域名和另外一個域名之間關系的DNS記錄）
13、剔除重復的JS和CSS
重復調用腳本，除了增加額外的HTTP請求外，多次運算也會浪費時間。在IE和Firefox中不管腳本是否可緩存，它們都存在重復運算JavaScript的問題。
14、配置ETags
Entity tags（ETags）（實體標簽）是web服務器和瀏覽器用于判斷瀏覽器緩存中的內容和服務器中的原始內容是否匹配的一種機制（“實體”就是所說的“內 容”，包括圖片、腳本、樣式表等），是比last-modified date更更加靈活的機制，單位時間內文件被修過多次，Etag可以綜合Inode(文件的索引節點(inode)數)，MTime(修改時間)和Size來精準的進行判斷，避開UNIX記錄MTime只能精確到秒的問題。 服務器集群使用，可取后兩個參數。使用ETags減少Web應用帶寬和負載。
15、使AJAX可緩存
利用時間戳，更精巧的實現響應可緩存與服務器數據同步更新。
16、盡早刷新輸出緩沖
尤其對于css，js文件的并行下載更有意義
17、使用GET來完成AJAX請求
當使用XMLHttpRequest時，瀏覽器中的POST方法是一個“兩步走”的過程：首先發送文件頭，然后才發送數據。在url小于2K時使用GET獲取數據時更加有意義。
18、延遲加載
確定頁面運行正常后，再加載腳本來實現如拖放和動畫，或者是隱藏部分的內容以及折疊內容等。
19、預加載
關注下無條件加載，有條件加載和有預期的加載。
20、減少DOM元素個數
使用更適合或者在語意是更貼切的標簽，要考慮大量DOM元素中循環的性能開銷。
21、根據域名劃分頁面內容
很顯然， 是最大限度地實現平行下載
22、盡量減少iframe的個數
考慮即使內容為空，加載也需要時間，會阻止頁面加載，沒有語意，注意iframe相對于其他DOM元素高出1-2個數量級的開銷，它會在典型方式下阻塞onload事件，IE和Firefox中主頁面樣式表會阻塞它的下載。
23、避免404
HTTP請求時間消耗是很大的，有些站點把404錯誤響應頁面改為“你是不是要找***”，這雖然改進了用戶體驗但是同樣也會浪費服務器資源（如數據庫等）。最糟糕的情況是指向外部 JavaScript的鏈接出現問題并返回404代碼。首先，這種加載會破壞并行加載；其次瀏覽器會把試圖在返回的404響應內容中找到可能有用的部分當作JavaScript代碼來執行。
24、減少Cookie的大小
去除不必要的coockie
使coockie體積盡量小以減少對用戶響應的影響
注意在適應級別的域名上設置coockie以便使子域名不受影響
設置合理的過期時間。較早地Expire時間和不要過早去清除coockie，都會改善用戶的響應時間。
25、使用無cookie的域
確定對于靜態內容的請求是無coockie的請求。創建一個子域名并用他來存放所有靜態內容。
26、減少DOM訪問
緩存已經訪問過的有關元素
線下更新完節點之后再將它們添加到文檔樹中
避免使用JavaScript來修改頁面布局
27、開發智能事件處理程序
有時候我們會感覺到頁面反應遲鈍，這是因為DOM樹元素中附加了過多的事件句柄并且些事件句病被頻繁地觸發。這就是為什么說使用event delegation（事件代理）是一種好方法了。如果你在一個div中有10個按鈕，你只需要在div上附加一次事件句柄就可以了，而不用去為每一個按 鈕增加一個句柄。事件冒泡時你可以捕捉到事件并判斷出是哪個事件發出的。
你同樣也不用為了操作DOM樹而等待onload事件的發生。你需要做的就是等待樹結構中你要訪問的元素出現。你也不用等待所有圖像都加載完畢。
你可能會希望用DOMContentLoaded事件來代替 事件應用程序中的onAvailable方法。
28、用<link>代替@import
在IE中，頁面底部@import和使用<link>作用是一樣的，因此最好不要使用它。
29、避免使用濾鏡
完全避免使用AlphaImageLoader的最好方法就是使用PNG8格式來代替，這種格式能在IE中很好地工作。如果你確實需要使用 AlphaImageLoader，請使用下劃線_filter又使之對IE7以上版本的用戶無效。
30、優化圖像
嘗試把GIF格式轉換成PNG格式，看看是否節省空間。在所有的PNG圖片上運行pngcrush（或者其它PNG優化工具）
31、優化CSS Spirite
在Spirite中水平排列你的圖片，垂直排列會稍稍增加文件大小；
Spirite中把顏色較近的組合在一起可以降低顏色數，理想狀況是低于256色以便適用PNG8格式；
便于移動，不要在Spirite的圖像中間留有較大空隙。這雖然不大會增加文件大小但對于用戶代理來說它需要更少的內存來把圖片解壓為像素地圖。 100×100的圖片為1萬像素，而1000×1000就是100萬像素。
32、不要在HTML中縮放圖像——須權衡
不要為了在HTML中設置長寬而使用比實際需要大的圖片。如果你需要：
<img width=”100″ height=”100″ src=”mycat.jpg” alt=”My Cat” />
那么你的圖片（mycat.jpg）就應該是100×100像素而不是把一個500×500像素的圖片縮小使用。這里在下文有更有趣的分析。
33、favicon.ico要小而且可緩存
favicon.ico是位于服務器根目錄下的一個圖片文件。它是必定存在的，因為即使你不關心它是否有用，瀏覽器也會對它發出請求，因此最好不要返回一 個404 Not Found的響應。由于是在同一臺服務器上，它每被請求一次coockie就會被發送一次。這個圖片文件還會影響下載順序，例如在IE中當你在 onload中請求額外的文件時，favicon會在這些額外內容被加載前下載。
因此，為了減少favicon.ico帶來的弊端，要做到：
文件盡量地小，最好小于1K
在適當的時候（也就是你不要打算再換favicon.ico的時候，因為更換新文件時不能對它進行重命名）為它設置Expires文件頭。你可以很安全地 把Expires文件頭設置為未來的幾個月。你可以通過核對當前favicon.ico的上次編輯時間來作出判斷。
Imagemagick可以幫你創建小巧的favicon。
34、保持單個內容小于25K
因為iPhone不能緩存大于25K的文件。注意這里指的是解壓縮后的大小。由于單純gizp壓縮可能達不要求，因此精簡文件就顯得十分重 要。
35、打包組件成復合文本
頁面內容打包成復合文本就如同帶有多附件的Email，它能夠使你在一個HTTP請求中取得多個組件（切記：HTTP請求是很奢侈的）。當你使用這條規 則時，首先要確定用戶代理是否支持（iPhone就不支持）。
1、 使用json作為數據的交換格式
Json在瀏覽器解析的效率至少高于XML一個數量級，高級瀏覽器中內置的有生成和解析json的方法，IE6中要用額外的方法（http://json.org）,不要用eval，容易引發性能和安全問題。
2、 盡可能對images和table設定寬高值
針對Yslow的不要在HTML中縮放圖像——第33條，有人會誤解為不要對圖片加寬高值，其實這條建議本身的意思是不要為了獲取一個特定大小的圖片，而去強行通過設置寬高值拉伸或者壓縮一個既有的圖片。建議是另存一張符合尺寸的圖片替代。
對圖片和table是設定寬高，是考慮到如果瀏覽器能立刻知道圖片或者tables的寬高，它就能夠直接呈現頁面而不需要通過計算元素大小后重繪，而且即便是圖片損毀而沒有展現，也不會進而破壞了頁面本來的布局。
有一些應用場景需要注意：
3、 拆離內容塊
盡量用div取代tables，或者將tables打破成嵌套層次深的結構；
避免用這樣的嵌套
<table> <table> <table> ... </table> </table></table>
采用下面的或者div重構：
<table></table><table></table><table></table>
4、 高效的CSS書寫規則
眾所周知，CSS選擇符是從右向左進行匹配的。
通常一個圖片列表的的小模塊
<div id="box"> <div class="hd"> <h3>我的旅途</h3> </div> <div class="bd"> <h4>旅途1</h4> <ul id="pics"> <li><a href="#pic" title=""><img src="" alt="" /></a><p>這是在<strong>圖片1</strong></p></li> </ul> </div></div>
為了代碼上縮進后內層的整潔性，我們html有可能這樣寫之外，更喜歡看這樣的css寫法：
.box{border:1px solid #ccc }.box .hd{border-bottom:1px solid #ccc }.box .hd h3{color:#515151}.box .bd{color:#404040 }.box .bd ul{margin-left:10px}.box .bd ul li{border-bottom:1px dashed #f1f1f1}.box .bd ul li a{text-decoration:none}.box .bd ul li a:hover{text-decoration:underline}.box .bd ul li a img{border:1px solid #ccc}.box .bd ul li p{text-align:left;}.box .bd ul li p strong{color:#ff6600} 其實寫到這里，問題已經顯而易見了。深達五層抑或六層的嵌套，同時右邊的選擇符都是采用標簽，在滿足我們視覺平整與代碼結構系統化的時候，付出的是性能的代價。
不做進一步的代碼書寫方式的探討，受個人習慣與應用場景影響。這里對css選擇符按照開銷從小到大的順序梳理一下：
<img width=”100″ height=”120″ src=”" alt=”" />
參考《高性能網站建設-進階指南》，有如下建議：
還要注意到，即便是頁面加載后，當頁面被觸發引起回流（reflow）的時候，低效的選擇符依然會引發更高的開銷，顯然這對于用戶是不佳的體驗。
在網站性能優化的路上，是不會有終點的，這也是前端工程師永不會妥協的地方。
想看到更牛P的優化建議么，請移步這里來關注李牧童鞋的分享：
新聞熱點
疑難解答
