網站前端性能優化總結

　1、服務器側優化

　　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會增長服務器端的負載，在實際應用中須要自行平衡。

　　2、Cookie優化

　　1. 減少Cookie體積
　　HTTP coockie能夠用於權限驗證和個性化身份等多種用途。coockie內的有關信息是經過HTTP文件頭來在web服務器和瀏覽器之間進行交流的。所以保持coockie儘量的小以減小用戶的響應時間十分重要。

　　使cookie體積儘可能小；

　　在合適的子域名上設置bookie，以避免影響其餘子域名下的響應；

　　設置合理的過時時間，去掉沒必要要的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帶有一些沒必要要的信息。

　　3、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樣式。

　　4、圖片優化

　　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/ ，強烈推薦使用。

　　5、內容優化

　　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/