一、服務(wù)器側(cè)優(yōu)化

　　1. 添加 Expires 或 Cache-Control 信息頭 

　　某些經(jīng)常使用到、并且不會經(jīng)常做改動的圖片（banner、logo等等）、靜態(tài)文件（登錄首頁、說明文檔等）可以設(shè)置較長的有效期（expiration date），這些HTTP頭向客戶端表明了文檔的有效性和持久性。如果有緩存，文檔就可以從緩存（除已經(jīng)過期）而不是從服務(wù)器讀取。接著，客戶端考察緩存中的副本，看看是否過期或者失效，以決定是否必須從服務(wù)器獲得更新。

　　各個(gè)容器都有針對的方案,，以 Apache 為例：

　　表示gif文件緩存一周，配置可以根據(jù)具體的業(yè)務(wù)進(jìn)行調(diào)整，具體配置可以參考：http://lamp.linux.gov.cn/Apache/ApacheMenu/mod/mod_expires.html

　　2. 壓縮內(nèi)容 

　　對于絕大多數(shù)站點(diǎn)，這都是必要的一步，能有效減輕網(wǎng)絡(luò)流量壓力。

　　表示zlib在壓縮時(shí)可以最大程度的使用內(nèi)存，壓縮html、文本、xml和php這幾種類型的文件，指定擴(kuò)展名為html、htm、xml、php、css和js的文件啟用壓縮。

　　具體配置可以參考：http://lamp.linux.gov.cn/Apache/ApacheMenu/mod/mod_deflate.html

　　3. 設(shè)置 Etags 

　　在使用etags之前，有必要復(fù)習(xí)一下 RFC2068 中規(guī)定的返回值 200 和 304 的含義：

　　客戶端在請求一份文件的時(shí)候，服務(wù)端會檢查客戶端是否存在該文件，如果客戶端不存在該文件，則下載該文件并返回200；如果客戶端存在該文件并且該文件在規(guī)定期限內(nèi)沒有被修改（Inode，MTime和Size），則服務(wù)端只返回一個(gè)304，并不返回資源內(nèi)容，客戶端將會使用之前的緩存文件。而etags就是判斷該文件是否被修改的記號，與服務(wù)器端的資源一一關(guān)聯(lián)，所以etags對于CGI類型的頁面緩存尤其有用。

　　下圖是優(yōu)化前的首頁：（注意，此時(shí)沒有壓縮首頁圖片，即使使用了緩存，仍需要5s左右的時(shí)間）

化前的某頁面

　　需要注意的是，使用etags會增加服務(wù)器端的負(fù)載，在實(shí)際應(yīng)用中需要自行平衡。

　　二、Cookie優(yōu)化

　　1. 減小Cookie體積
　　HTTP coockie可以用于權(quán)限驗(yàn)證和個(gè)性化身份等多種用途。coockie內(nèi)的有關(guān)信息是通過HTTP文件頭來在web服務(wù)器和瀏覽器之間進(jìn)行交流的。因此保持coockie盡可能的小以減少用戶的響應(yīng)時(shí)間十分重要。

　　使cookie體積盡量小；

　　在合適的子域名上設(shè)置bookie，以免影響其他子域名下的響應(yīng)；

　　設(shè)置合理的過期時(shí)間，去掉不必要的cookie。

　　下面對比一下各個(gè)網(wǎng)站的cookie：

圖中可以看出，6K的cookie顯然是不必要的。

　　2. 對于頁面內(nèi)容使用無coockie域名

　　當(dāng)瀏覽器在請求中同時(shí)請求一張靜態(tài)的圖片和發(fā)送coockie時(shí)，服務(wù)器對于這些coockie不會做任何地使用。因此它們只是因?yàn)槟承┴?fù)面因素而創(chuàng)建的網(wǎng)絡(luò)傳輸。所以你應(yīng)該確定對于靜態(tài)內(nèi)容的請求是無coockie的請求。創(chuàng)建一個(gè)子域名并用他來存放所有靜態(tài)內(nèi)容。

　　例如，域名是www.example.org，則可以考慮可以在static.example.org上存在靜態(tài)內(nèi)容。但是，如果不是在www.example.org上而是在頂級域名example.org設(shè)置了coockie，那么所有對于static.example.org的請求都包含coockie。在這種情況下，可以考慮重新購買一個(gè)新的域名來存在靜態(tài)內(nèi)容，并且要保持這個(gè)域名是無coockie的。例如，t.qq.com使用的是qpic.cn，weibo.com使用的是sinaimg.cn，xiaonei.com使用的是hdn.xnimg.cn等等。

　　性能方面的考慮還有使用帶有www的子域名并且在它上面設(shè)置coockie，因?yàn)楹雎詗ww會把cookie設(shè)置到*.example.com上去，使cookie帶有一些不必要的信息。

　　三、JAVA SCRIPT 和 CSS 優(yōu)化

　　1. 把 CSS 放到代碼頁上端 

　　這么做可以避免瀏覽器在解釋一次之后，使用css進(jìn)行第二次解釋，因?yàn)橛脩魧ss裸奔日效果根本就不感興趣。

css裸奔節(jié)效果圖（來源：網(wǎng)絡(luò)） 

　　2. 避免 CSS 表達(dá)式 

　　凡是只有IE能用的東西，都不是好東西。

　　3. 從頁面中剝離 JavaScript 與 CSS

　　剝離后，能夠有針對性的對其進(jìn)行單獨(dú)的處理策略，比如壓縮或者緩存策略。

（css已經(jīng)剝離，但js嵌入到html里面了，并且放在了html的上部，所以這貨是正面+反面教材）

　　4. 精簡 JavaScript 與 CSS

　　語法能簡寫話盡量簡寫。

（相同表現(xiàn)的類合并）

　　5. 使用 <link> 而不是 @importChoose <link> over @import

　　在 IE 中 @import 指令等同于把 link 標(biāo)記寫在 HTML 的底部，這與第一條相違背。

　　6. 避免使用CSS Filter

　　盡量使用png格式的圖片來代替濾鏡效果，因?yàn)殚_啟濾鏡會加大瀏覽器的開銷。  

　　7. JS盡量放到頁面最下端

　　當(dāng)一個(gè)腳本在下載的時(shí)候，瀏覽器會卡住，無法響應(yīng)其他請求。所以，可以將功能性的JS放到最后端去處理。

　　8. 頁面展現(xiàn)盡量交給CSS完成

　　曾經(jīng)見過一個(gè)JS+CSS寫出來的下拉框，如圖：

　　實(shí)現(xiàn)原理是JS獲取頁面的每一個(gè)select元素和其對應(yīng)的屬性，然后用js重新畫出新的樣式效果：

　　多出的這部分JS執(zhí)行過程會降低客戶端的性能,所以最終沒有采用這個(gè)select樣式。

　　四、圖片優(yōu)化

　　1. 優(yōu)化圖片 

　　盡可能的使用 PNG 格式的圖片，因?yàn)楹虶IF相比，PNG有更多的功能和更小的體積，而且未來PNG會加入動畫效果：

　　2. 使用 CSS Sprites 對圖片優(yōu)化 

　　簡單的說就是"利用 CSS background 相關(guān)元素進(jìn)行背景圖絕對定位"，把多次HTTP 調(diào)用變?yōu)橐淮握{(diào)用：

　　這些表情在鼠標(biāo)沒有經(jīng)過的時(shí)候，都是從一張圖片上絕對定位出來的，只有在鼠標(biāo)放到某一張表情上時(shí)，才會從服務(wù)器上下載gif圖片，這樣可以減少(N-1)次HTTP請求。

　　使用 CSS Sprites 的不足之處是客戶端將消耗更多內(nèi)存，因?yàn)镃SS Sprites 會打開多個(gè)圖片的副本，目前的解決辦法是按照使用頻率不同，合并成幾個(gè)級別的圖片，分批次下載并在客戶端展示。

　　3. 不要在 HTML 中縮放圖片 

　　用 ImageMagic 命令（convert ）就能將圖片縮放成合適的尺寸，所以盡量不要交給瀏覽器去執(zhí)行。

　　4. 用更小的并且可緩存的 favicon.ico

　　原因是沒有favicon.ico，服務(wù)器會返回一個(gè)404，與可以長時(shí)間緩存的文件相比，大量的404會增加服務(wù)器的響應(yīng)數(shù)量。

（服務(wù)器上因?yàn)槿鄙賔avicon.ico而產(chǎn)生的404錯(cuò)誤）

　　4. 壓縮圖片不一定是有損的 

　　對已有圖片進(jìn)行壓縮并不對影響用戶體驗(yàn)，主要基于以下兩點(diǎn)：

　　1. 用戶未必會感覺到色彩的損失；

　　2. 壓縮不一定會損壞圖片的質(zhì)量。

　　無損壓縮圖片的原理可以參考下面的鏈接，本文不再贅述：http://en.wikipedia.org/wiki/Image_compression

　　最初測試平臺首頁使用的是未壓縮過的圖片，下載速度明顯受拖延，有時(shí)會達(dá)到將近十秒鐘左右的下載時(shí)間，在經(jīng)過無損壓縮首頁圖片之后，提升效果效果很明顯，基本控制在了一秒鐘之內(nèi)：

　　下圖是壓縮前后的大小對比：

　　該工具地址為：http://www.smushit.com/ ，強(qiáng)烈推薦使用。

　　五、內(nèi)容優(yōu)化

　　1. 減少 DNS 查找

　　DNS lookup 是很耗費(fèi)時(shí)間的步驟，網(wǎng)站上如果過多的使用了站外的 Widget ，DNS 查找?guī)淼膯栴}是不容忽視的。

　　2. 盡量減少重定向

　　并且注意一些不必要的重定向，比如對 Web 站點(diǎn)子目錄的后面添加個(gè) "/" ，就能有效避免一次重定向。對于服務(wù)器來說，請求http://example.com/fml 與請求 http://example.com/fml/  是有差異的。如果是 Apache 服務(wù)器，可以通過配置mod_rewrite解決這個(gè)問題。具體請參考：http://lamp.linux.gov.cn/Apache/ApacheMenu/mod/mod_rewrite.html 

　　3. 切分組件到多個(gè)域

　　主要的目的是提高頁面組件并行下載能力，但注意，也不要同時(shí)使用過多的域名，否則就會出現(xiàn)第一條DNS lookup過多的問題，一般情況下兩個(gè)域名就可以了。 

　　4. 杜絕 http 404 錯(cuò)誤

　　對頁面鏈接的充分測試加上對 Web 服務(wù)器 error 日志的不斷跟蹤可以有效減少 404 錯(cuò)誤，并提升用戶體驗(yàn)。

　　后記：

　　這次總結(jié)給我?guī)淼膯l(fā)并不在于提升系統(tǒng)性能性能本身，提升性能只是一個(gè)很表面上的東西，網(wǎng)上的方法有很多，測試的方法也有很多，照著都做一遍，性能確實(shí)會有所提升，但是這種知其然而不知其所以然的性能提升是沒有意義的，這便是本文的目的所在。

　　參考：

　　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/