序言：

可能很多人跟我們一樣，一直以為性能主要是后端問題。但是這本書中的實例表明，前端問題可能消耗掉整體時間的80%到90%，而只有10%到20%的時間花在了下載HTML文檔上。一般我們認為前端性能無非就是堅持使用外部的CSS和JS，盡量減少CSS和JS引用的數(shù)量，還有對JS的壓縮。但是這本書告訴我們，我們要做的工作遠不止這些。

本書按照優(yōu)先級順序介紹了14個性能規(guī)則。但是并非每個規(guī)則都要應(yīng)用于每個網(wǎng)站，也不是每個網(wǎng)站都應(yīng)該按照同一種方式運用一個規(guī)則，但是每個規(guī)則都值得考慮。

我們自己做了下實驗：

百度：0.013/0.075=17%     0.014/0.040=35%

page speed 評分：99

淘車買車首頁：0.699/7.559=9%       0.667/2.978=22%  

page speed 評分：68

淘車網(wǎng)車源列表頁：0.057/4.734=1.2%     0.055/2.112=2.6%    

page speed 評分：84

二手車之家車源列表頁：0.068/2.164=3%       0.063/1.183=5%   

page speed 評分：82

我們的問題大概在一下這幾個方面：

啟用 Keep-Alive

由同一網(wǎng)址提供資源

將圖片組合為 CSS貼圖定位

優(yōu)化圖片

我們做到了：

暫緩 JavaScript解析

壓縮 JavaScript

壓縮 CSS

壓縮 HTML

指定圖片大小

將查詢字符串從靜態(tài)資源中刪除

優(yōu)化樣式表和腳本的排列順序

使用瀏覽器緩存

使目標(biāo)網(wǎng)頁重定向可緩存

內(nèi)嵌小型 CSS

內(nèi)嵌小型 JavaScript

啟用壓縮

將 CSS放在文檔標(biāo)頭處

將圖片組合為 CSS貼圖定位

盡量減少請求的數(shù)據(jù)量

盡量減少重定向

指定字符集

請指定一個“Vary: Accept-Encoding”標(biāo)頭

請指定緩存驗證工具

避免出現(xiàn)錯誤的請求

避免在 CSS中使用 @import

首選異步資源

下面是對以上提到的14條規(guī)則的具體介紹：

規(guī)則1－減少HTTP請求

既然有80％－90％的時間花在為HTML文檔所引用的所有組建（圖片，腳本，樣式表，F(xiàn)lash等）進行的HTTP請求上，因此改善響應(yīng)時間的最簡單途徑就是減少組件的數(shù)量，并由此減少HTTP請求數(shù)量。這是最重要的原則，如果14條規(guī)則里只能選一條，那就是它了.

圖片地圖：如果用圖片做導(dǎo)航鏈接，我們們可以將多個圖片完成的功能，使用一個圖片，根據(jù)的不同區(qū)域來響應(yīng)不應(yīng)的請求。因為一個圖片只有一次HTTP請求，而多個圖片需要有多次請求。

CSS Sprites

原理同上，但比上面的更靈活

CSS Sprites方式處理例子：

書中的示例：

 

內(nèi)聯(lián)圖片 是將簡單圖片的編碼數(shù)據(jù)直接保存在URL自身之中。（需要內(nèi)聯(lián)編碼技術(shù)）

合并腳本和樣式表：每個文件都會導(dǎo)致一個HTP請求，盡量將css和js合并到一個文件中；

把原有的多個樣式表文件合成一個，可以使用戶在瀏覽網(wǎng)頁時只需下載一個CSS文件。這樣減少了HTTP請求，速度自然就快了些。Javascript文件也一樣。不過這樣做似乎不符合模塊化的開發(fā)原則。

小結(jié)：前三種方法的起到的效果差不多，根據(jù)書中提供的例子，理論上都能節(jié)約將近一半的時間。但是圖片地圖中的圖片必須是連續(xù)的，在定義區(qū)域坐標(biāo)時，如果采取手工的方式則很難而且容易出錯，而且除了舉行之外幾乎無法完成其它形狀，通過DHTML創(chuàng)建的圖片地圖IE不支持。CSS精靈沒有圖片連續(xù)的限制，非常靈活，而且它還有個額外的優(yōu)點，合并后的圖片會比分離的圖片的總和要小。這是因為它降低了圖片自身的開銷（顏色表，格式信息等）。內(nèi)聯(lián)圖片的缺點是IE不支持，而且對圖片的大小也有限制。所以CSS精靈是優(yōu)質(zhì)選擇，我們要求合并腳本和樣式表，要求不超過三個，包括頭部一個，框架一個，頁面里只能用一個了。