前端性能優化的14個規則

做爲一個半前端工程師，並且只會寫點HTML5和CSS3的「假」前端工程師，爲了能更好地理解一下前端的花花世界，最近拜讀了《高性能網站建設指南》一書，對做者提出的前端性能優化的14個規則獲益匪淺，爲了讓本身印象更深入點，決定做此文，當作學習筆記也好，知識總結也罷，總歸看過的東西要讓本身很好地掌握很好地運用起來纔是王道。在解讀這些規則的同時，我會用我一年半多的移動網站開發經歷提出一些針對移動網站的優化建議。

 

規則01：儘可能減小HTTP請求

前端優化的黃金準則指導着前端頁面的優化策略：只有10%-20%的最終用戶響應時間花在接受請求的HTML文檔上，剩下的80%-90%時間花在爲HTML文檔所引用的全部組件（圖片、腳本、樣式表等）進行的HTTP請求上。所以，改善響應時間的最簡單途徑就是減小組件的數量，並由此減小HTTP請求的數量。固然不少人就會說，既然這樣，那咱們就減小頁面組件的數量不就OK了嗎？那你試試，你會掀起一場性能優化和產品設計之間的大PK。因此，咱們要減小HTTP請求是要平衡性能和設計的。若是找到這個平衡點呢？書中從如下幾個方面作了介紹，我逐一說明：

①   圖片地圖

 

初看「圖片地圖」四個字，對非專業的前端人員來講一頭霧水，個人第一印象就是這樣的，我們以京東的移動站點爲例，右側用戶和購物車的圖標，正常實現我會選擇以下方式：

<a href=」用戶跳轉頁面URL」>

           <div class=」定義用戶icon顯示的樣式表」></div>

</a>

<a href=」購物車跳轉頁面URL」>

           <div class=」 定義用戶icon顯示的樣式表」></div>

</a>

這種方式無可厚非的，可是兩張圖片就有兩個HTTP請求，這明顯是增長了頁面中的HTTP請求。

那麼咱們能夠把這兩個HTTP請求變成一個嗎？答案固然是能夠的，這就是圖片地圖：容許在一張圖片上關聯多個URL，而目標URL的選擇取決於用戶單擊了圖片上的哪一個位置。這樣上面京東兩個圖標合併成一張圖片，這樣圖片的HTTP請求就減小了一個。

示例代碼以下：

<img src=」合併後的圖片」>

<map name=」map1」>

           <area shape=」rect」 coords=」0,0,40,40」 href=」用戶跳轉頁面URL」>

           <area shape=」rect」 coords=」50,0,90,40」 href=」購物車跳轉頁面URL」>

</map>

不過圖片地圖只支持矩形形狀，其餘形狀不支持。

 

②   請CSS喝「雪碧」（CSS Sprites）

CSS Sprites一句話：將多個圖片合併到一張單獨的圖片，這樣就大大減小了頁面中圖片的HTTP請求。

 

③   內聯圖片和腳本

使用data:URL（Base64編碼）模式直接將圖片包含在Web頁面中而無需進行HTTP請求。

可是此種方法存在明顯缺陷：

- 不受IE的歡迎；

- 圖片太大不宜採用這種方式，由於Base64編碼以後會增長圖片大小，這樣頁面總體的下載量會變大；

- 內聯圖片在頁面跳轉的時候不會被緩存。（大圖片可使用瀏覽器的本地緩存，在首次訪問的時候保存到瀏覽器緩存中，典型的是HTML5的manifest緩存機制以及LocalStorage等）。

 

④   樣式表的合併

將頁面樣式定義、腳本、頁面自己代碼嚴格區分開，可是樣式表、腳本也不是分割越細越好，由於沒多引用一個樣式表就增長一次HTPP請求，能合併的樣式表儘可能合併。一個網站有一個公用樣式表定義，每一個頁面只要有一個樣式表就OK啦。

 

經過以上四個努力以後，你會發現你的網頁響應時間最多能減小一半，這不是做者說大話，也不是我狂吹，我親手用個人移動網站首頁作了一個嘗試，本地測試以後響應時間能減小40%左右。因此減小頁面HTTP請求數量，是一個很重要的原則。遵循此原則能夠同時改善首次訪問和後續訪問的響應時間，而每個網站的首次響應時間會決定用戶以後還來不來的重要緣由。

 

規則02：使用內容發佈網絡（CDN的使用）

什麼叫內容發佈網絡（CDN）？它是一組分佈在多個不一樣地理位置的Web服務器，用於更加有效地向用戶發佈內容。主要用於發佈頁面靜態資源：圖片、css文件、js文件等。如此，能輕易地提升響應速度。

關於CDN的具體詳細原理以及優缺點，各位能夠自行詢問度娘或者google。

 

規則03：添加Expires頭

瀏覽器使用緩存來減小HTTP請求的數據，並減少HTTP響應的大小，使頁面加載更快。Web服務器使用Expires頭來告訴瀏覽器它可使用一個組件的當前副本，直到指定的deadline爲止。HTTP規範中稱此頭爲：在這一時間以後響應被認爲失效。

我的對這塊表示不想使用，其實就是一句話，把一些css、js、圖片在首次訪問的時候所有緩存到瀏覽器本地，從我作移動網站的過程當中發現，其實沒有這麼複雜，徹底可使用HTML5提供的本地緩存機制就OK了。關於HTML5本地緩存機制，各位能夠查閱相關資料。後續我也會對HTML5的緩存機制進行介紹的。

 

規則04：壓縮組件（使用Gzip方式）

書中關於壓縮從gzip壓縮方式到如何壓縮講了不少，我想直接跳過，對於作PC網站或者移動網站來講，急須要壓縮的是css文件和js文件，至於如何壓縮，網上有不少在線工具，去挑選一個本身用的順手看的順眼的就好，固然也有人選擇對HTML進行壓縮，這樣也能夠。可是實際工做中我沒有這麼作。之所謂沒有這麼作，是由於我以爲很麻煩。不要鄙視我，畢竟我不是一個真正意義上的前端工程師，哈哈！

 

規則05：將CSS樣式表放在頂部

若是將css樣式定義放在頁面中或者頁面底部，會出現短暫白屏或者某一區域短暫白板的狀況，這和瀏覽器的運營機制有關的，無論頁面如何加載，頁面都是逐步呈現的。因此在每作一個頁面的時候，用Link標籤把每個樣式表定義放在head中。

 

規則06：將javascript腳本放在底部

瀏覽器在加載css文件時，頁面逐步呈現會被阻止，直到全部css文件加載完畢，因此要把css文件的引用放到head中去，這樣在加載css文件時不會組織頁面的呈現。可是對於js文件，在使用的時候，它下面全部也頁面內容的呈現都會被阻塞，將腳本放在頁面越靠下的地方，就意味着越多的內容可以逐步呈現。

 

規則07：避免使用CSS表達式

CSS表達式是動態玩CSS的一種很強大的方式，可是強大的同時也存在很高的危險性。由於css表達式的頻繁求值會致使css表達式性能低下。若是真想玩css表達式，能夠選用只求值一次的表達式或者使用事件處理來改變css的值。

 

規則08：使用外部javascript和CSS

內聯js和css其實比外部文件有更快的響應速度，那爲何還要用外部呢？由於使用外部的js和css可讓瀏覽器緩存他們，這樣不只HTML文檔大小減小，並且不會增長HTTP請求數量。

另外，使用外部js和css能夠提升組件的可複用性。

 

規則09：減小DNS查詢

DNS查詢有時間開銷，一般一個瀏覽器查找一個給定主機名的IP地址須要20-120ms。

緩存DNS：緩存DNS查詢能夠很好地提升網頁性能，一旦緩存了DNS查詢，以後對於相同主機名的請求就無需進行再次的DNS查找，至少短期內不須要。

因此在使用頁面中URL、圖片、js文件、css文件等時，不要使用過多不一樣的主機名。

 

規則10：精簡javascript

如何精簡？最初始的精簡方式就是移除沒必要要的字符減少js文件大小，改善加載時間。包括全部的註釋、沒必要要的空白字符。

高級一點的精簡方式就是：混淆。它不但會移除沒必要要的字符，還會改寫代碼，好比函數和變量的名字會被改爲很短的字符串，這樣使js代碼更簡練更難閱讀。

可是我通常不多使用混淆，一個如今互聯網時代，代碼沒有必要整的那麼神祕，大能夠你們一塊兒share，天下代碼一塊兒抄，只要抄出本身的特點就ok了。並且一旦使用混淆，對於js代碼的維護和調試都很複雜，由於有時候混淆以後的js代碼徹底看不懂。

其實實際開發過程當中，從文件大小和代碼可複用性來講，不只僅是js代碼須要精簡，css代碼同樣也很須要精簡。

 

規則11：避免重定向

重定向的英文是Redirect，用於將用戶從一個URL從新跳轉到另外一個URL。最多見的Redirect就是301和302兩種。

關於重定向的性能影響這裏就不說了，自行查閱相關資料吧。

在咱們實際開發中避免重定向最簡單也最容易被忽視的一個問題就是，設置URL的時候，最後的「/」，有些人有時候會忽略，其實你少了「/」，這時候的URL就被重定向了，因此在給頁面連接加URL的時候切記最後的「/」不可丟。

 

規則12：刪除重複腳本

重複的js代碼除了有沒必要要的HTTP請求以外，還會浪費執行js的時間。

將你使用的js代碼模塊化，能夠很好地避免這個問題，至於js模塊化如何實現，如今有不少可使用的開源框架，我用的比較多的是咱們公司玉伯的Sea.js。

 

規則13：配置ETag

Etag（Entity Tag），實體標籤，是Web服務器和瀏覽器用戶確認緩存組件的有效性的一種機制。

寫的很複雜，對我這種非專業的前端開發人員來講，有點過了，關於這個原則有興趣的本身看吧。

 

規則14：使Ajax可緩存

針對頁面中主動的Ajax請求返回的數據要緩存到本地，固然這個是針對短時間內不會變化的數據。若是不肯定數據變化週期的話，能夠增長一個修改標識的判斷，我正常處理過程當中會給一些Ajax請求返回的數據增長一個MD5值的判斷，每次請求會判斷當前MD5是否變化，若是變化了取最新的數據，若是不變化，則不變。

 

噼裏啪啦說了一堆，14個規則啊，那咱們開發過程當中要針對這每個規則對本身的前端代碼作check嗎？我反正不這麼幹，作前端頁面，尤爲是移動網站的頁面，我所記住的準則就是：儘可能減小頁面大小，儘可能下降頁面響應時間。在頁面性能和交互設計之中找平衡點。