網站前端性能優化總結
BY Chuck
一、服務器側優化
1. 添加 Expires 或 Cache-Control 信息頭
某些經常使用到、並且不會經常做改動的圖片（banner、logo等等）、靜態文件（登錄首頁、說明文檔等）可以設置較長的有效期（expiration date），這些HTTP頭向客戶端表明了文檔的有效性和持久性。如果有緩存，文檔就可以從緩存（除已經過期）而不是從服務器讀取。接着，客戶端考察緩存中的副本，看看是否過期或者失效，以決定是否必須從服務器獲得更新。
各個容器都有針對的方案,，以 Apache 爲例：
ExpiresActive On
ExpiresByType image/gif "access plus 1 weeks"
表示gif文件緩存一週，配置可以根據具體的業務進行調整，具體配置可以參考：
http://lamp.linux.gov.cn/Apache/ApacheMenu/mod/mod_expires.html
2. 壓縮內容
對於絕大多數站點，這都是必要的一步，能有效減輕網絡流量壓力。
<ifmodule mod_deflate.c>
DeflateCompressionLevel 9
AddOutputFilterByType DEFLATE text/html text/plain text/xml application/x-httpd-php
AddOutputFilter DEFLATE html htm xml php css js
</ifmodule>
表示zlib在壓縮時可以最大程度的使用內存，壓縮html、文本、xml和php這幾種類型的文件，指定擴展名爲html、htm、xml、php、css和js的文件啓用壓縮。
具體配置可以參考：
http://lamp.linux.gov.cn/Apache/ApacheMenu/mod/mod_deflate.html
3. 設置 Etags
在使用etags之前，有必要複習一下RFC2068 中規定的返回值 200 和 304 的含義：
200--OK
304--Not Modified
客戶端在請求一份文件的時候，服務端會檢查客戶端是否存在該文件，如果客戶端不存在該文件，則下載該文件並返回200；如果客戶端存在該文件並且該文件在規定期限內沒有被修改（Inode，MTime和Size），則服務端只返回一個304，並不返回資源內容，客戶端將會使用之前的緩存文件。而etags就是判斷該文件是否被修改的記號，與服務器端的資源一一關聯，所以etags對於CGI類型的頁面緩存尤其有用。
下圖是優化前的首頁：（注意，此時沒有壓縮首頁圖片，即使使用了緩存，仍需要5s左右的時間）
化前的某頁面
需要注意的是，使用etags會增加服務器端的負載，在實際應用中需要自行平衡。
二、Cookie優化
1. 減小Cookie體積
HTTP coockie可以用於權限驗證和個性化身份等多種用途。coockie內的有關信息是通過HTTP文件頭來在web服務器和瀏覽器之間進行交流的。因此保持coockie儘可能的小以減少用戶的響應時間十分重要。
l 使cookie體積儘量小；
l 在合適的子域名上設置bookie，以免影響其他子域名下的響應；
l 設置合理的過期時間，去掉不必要的cookie。
下面對比一下各個網站的cookie：
圖中可以看出，6K的cookie顯然是不必要的
2. 對於頁面內容使用無coockie域名
當瀏覽器在請求中同時請求一張靜態的圖片和發送coockie時，服務器對於這些coockie不會做任何地使用。因此他們只是因爲某些負面因素而創建的 網絡傳輸。所有你應該確定對於靜態內容的請求是無coockie的請求。創建一個子域名並用他來存放所有靜態內容。
例如，域名是www.example.org，則可以考慮可以在static.example.org上存在靜態內容。但是，如果不是在www.example.org上而是在頂級域名example.org設置了coockie，那麼所有對於static.example.org的請求 都包含coockie。在這種情況下，可以考慮重新購買一個新的域名來存在靜態內容，並且要保持這個域名是無coockie的。例如，t.qq.com使用的是qpic.cn，weibo.com使用的是sinaimg.cn，xiaonei.com使用的是hdn.xnimg.cn等等。
性能方面的考慮還有使用帶有www的子域名並且在它上面設置coockie，因爲忽略www會把cookie設置到*.example.com上去，使cookie帶有一些不必要的信息。
三、JAVA SCRIPT 和 CSS優化
1. 把 CSS 放到代碼頁上端
這麼做可以避免瀏覽器在解釋一次之後，使用css進行第二次解釋，因爲用戶對css裸奔日效果根本就不感興趣。
css裸奔節效果圖（來源：網絡）
2. 避免 CSS 表達式
凡是隻有IE能用的東西，都不是好東西。
3. 從頁面中剝離 JavaScript 與 CSS
剝離後，能夠有針對性的對其進行單獨的處理策略，比如壓縮或者緩存策略。
（css已經剝離，但js嵌入到html裏面了，並且放在了html的上部，所以這貨是正面+反面教材）
4. 精簡 JavaScript 與 CSS
語法能簡寫話儘量簡寫。
（相同表現的類合併）
5. 使用 <link> 而不是@importChoose <link> over @import
在 IE 中 @import 指令等同於把 link 標記寫在 HTML 的底部，這與第一條相違背。
6. 避免使用CSS Filter
儘量使用png格式的圖片來代替濾鏡效果，因爲開啓濾鏡會加大瀏覽器的開銷。
7. JS儘量放到頁面最下端
當一個腳本在下載的時候，瀏覽器會卡住，無法響應其他請求。所以，可以將功能性的JS放到最後端去處理。
8. 頁面展現儘量交給CSS完成
曾經見過一個JS+CSS寫出來的下拉框，如圖：
實現原理是JS獲取頁面的每一個select元素和其對應的屬性，然後用js重新畫出新的樣式效果：
多出的這部分JS執行過程會降低客戶端的性能,所以最終沒有采用這個select樣式。
四、圖片優化
1. 優化圖片
儘可能的使用 PNG 格式的圖片，因爲和GIF相比，PNG有更多的功能和更小的體積，而且未來PNG會加入動畫效果：
2. 使用 CSS Sprites 對圖片優化
簡單的說就是"利用 CSS background 相關元素進行背景圖絕對定位"，把多次HTTP 調用變爲一次調用：
這些表情在鼠標沒有經過的時候，都是從一張圖片上絕對定位出來的，只有在鼠標放到某一張表情上時，纔會從服務器上下載gif圖片，這樣可以減少(N-1)次HTTP請求。
使用 CSS Sprites 的不足之處是客戶端將消耗更多內存，因爲CSS Sprites 會打開多個圖片的副本，目前的解決辦法是按照使用頻率不同，合併成幾個級別的圖片，分批次下載並在客戶端展示。
3. 不要在 HTML 中縮放圖片
用 ImageMagic 命令（convert ）就能將圖片縮放成合適的尺寸，所以儘量不要交給瀏覽器去執行。
4. 用更小的並且可緩存的 favicon.ico
原因是沒有favicon.ico，服務器會返回一個404，與可以長時間緩存的文件相比，大量的404會增加服務器的響應數量。
（服務器上因爲缺少favicon.ico而產生的404錯誤）
4. 壓縮圖片不一定是有損的
對已有圖片進行壓縮並不對影響用戶體驗，主要基於以下兩點：
1. 用戶未必會感覺到色彩的損失；
2. 壓縮不一定會損壞圖片的質量。
無損壓縮圖片的原理可以參考下面的鏈接，本文不再贅述：
http://en.wikipedia.org/wiki/Image_compression
最初測試平臺首頁使用的是未壓縮過的圖片，下載速度明顯受拖延，有時會達到將近十秒鐘左右的下載時間，在經過無損壓縮首頁圖片之後，提升效果效果很明顯，基本控制在了一秒鐘之內：
下圖是壓縮前後的大小對比：
該工具地址爲：http://www.smushit.com/ ，強烈推薦使用。
五、內容優化
1. 減少 DNS 查找
DNS lookup 是很耗費時間的步驟，網站上如果過多的使用了站外的 Widget ，DNS 查找帶來的問題是不容忽視的。
2. 儘量減少重定向
並且注意一些不必要的重定向，比如對 Web 站點子目錄的後面添加個 "/" ，就能有效避免一次重定向。對於服務器來說，請求http://example.com/fml 與請求 http://example.com/fml/ 是有差異的。如果是 Apache 服務器，可以通過配置mod_rewrite解決這個問題。具體請參考：
http://lamp.linux.gov.cn/Apache/ApacheMenu/mod/mod_rewrite.html
3. 切分組件到多個域
主要的目的是提高頁面組件並行下載能力，但注意，也不要同時使用過多的域名，否則就會出現第一條DNS lookup過多的問題，一般情況下兩個域名就可以了。
4. 杜絕 http 404 錯誤
對頁面鏈接的充分測試加上對 Web 服務器 error 日誌的不斷跟蹤可以有效減少 404 錯誤，並提升用戶體驗。
後記：
這次總結給我帶來的啓發並不在於提升系統性能性能本身，提升性能只是一個很表面上的東西，網上的方法有很多，測試的方法也有很多，照着都做一遍，性能確實會有所提升，但是這種知其然而不知其所以然的性能提升是沒有意義的，這便是本文的目的所在。
參考：
http://developer.yahoo.com/performance/
http://code.google.com/speed/page-speed/docs/rules_intro.html
http://book.douban.com/subject/4719162/
http://book.douban.com/subject/3132277/
本文原創自無線技術運營空間： http://wireless.qzone.qq.com 及 http://blog.csdn.net/wireless_tech （專注無線技術運營——無線技術(操作系統/數據庫/WEB前端/負載均衡/系統容災/系統安全/短信接入/WAP接入/3G等)、無線業務運營、無線開放平臺、統計分析(用戶行爲分析/數據挖掘)、CP合作，聯繫我們：[email protected]）