高效能網站建設指南-前端效能優化（一）

阿新 • • 發佈：2019-01-19

年前，讀完了《高效能網站建設指南》，但是一直沒有整理。年後回來和同事一起出了份前端面試題，涉及到了關於效能優化的問題，在此特梳理一下。

大量的公司在開發功能業務時，只關注功能點的實現，對於效能方面要求很低甚至不作為考慮範圍。在遇到一些效能瓶頸時，也往往通過加機器的暴力方式去減緩，但那並不是解決問題的根本。作為前端工程師，大部分人為了迎合需求一直在學習JavaScript、CSS、HTML5及Node，很少去關注效能方面的東西。然而，有些效能的優化點只需要花費很少的時間和精力就能換來巨大的改善使用者體驗。在陳述前端效能優化的問題之前，我們先思考如下問題：

一個頁面從輸入 URL 到頁面載入顯示完成，這個過程中都發生了什麼？

在瀏覽器輸入地址；
瀏覽器查詢域名的 IP 地址，包括 DNS 具體的查詢過程，包括：瀏覽器快取、系統快取、路由器快取等；
瀏覽器向 web 伺服器傳送一個 HTTP 請求；
伺服器的永久重定向響應（從 http://example.com 到 http://www.example.com）；
瀏覽器跟蹤重定向地址；
伺服器處理請求；
伺服器返回一個 HTTP 響應；
瀏覽器渲染顯示 HTML ；
瀏覽器傳送請求獲取嵌入在 HTML 中的資源（如圖片、音訊、視訊、CSS、JS等等）；
瀏覽器傳送非同步請求。

效能黃金法則：只有10%-20%的終端使用者響應時間花在了下載HTML文件上。其餘的80%-90%時間花在了下載頁面中的所有元件上。

寫在前面

在闡述優化點之前，有必要的先說明一下HTTP，其作為瀏覽器和伺服器之間的一種傳輸協議，在整個過程中的作用至關重要！對HTTP更多的瞭解，推薦閱讀《HTTP權威指南》。

壓縮

壓縮響應是最卓有成效的優化方式，瀏覽器可以使用Accept-Encoding頭來宣告支援壓；伺服器使用Content-Encoding頭確認響應已被壓縮。

==Request Headers==
Accept-Encoding:gzip

==Response Headers==
Content-Encoding:gzip

條件GET請求

如果瀏覽器在其快取中保留了元件的一個副本，但並不確定它是否仍然有效，就會生成一個條件Get請求。如果確認快取在副本仍然有效，瀏覽器就可以使用快取中的副本。

典型情況下，快取副本的有效性源自其最後修改時間。基於響應中的Last-Modified頭，瀏覽器可以知道元件最後的修改時間。它會使用If-Modified-Since頭將最後修改時間傳送給伺服器。如果元件沒有被修改過，伺服器會返回一個“304 Not Modified”狀態碼並不再發送響應體，從而得到一個更小且更快的相應。在HTTP1.1中可以使用ETag和If-None-Match進行條件GET請求（下面講述）。

==Request Headers==
If-Modified-Since:Thu, 07 Apr 2016 08:30:15 GMT

==Response Headers==
Last-Modified:Thu, 07 Apr 2016 08:30:15 GMT

Expires

條件GET請求和304響應有助於讓頁面載入得更快，但仍需要在客戶端和伺服器之間進行一次往返確認，以執行有效性檢查。Expires頭明確指出瀏覽器是否可以使用元件的快取副本。如果元件沒有過期，瀏覽器就會使用快取版本而不會進行任何HTTP請求。

==Response Headers==
Expires:Thu, 07 Apr 2019 08:30:15 GMT

Keep-Alive

HTTP構建在傳輸控制協議TCP(Transmission Control Protocol)之上。HTTP早期實現中，每個HTTP請求都要開啟一個socket連線。持久連線可以確保在單獨的連線上進行多個請求。瀏覽器和伺服器使用Connection頭來指明對Keep-Alive的支援。在HTTP1.1中並不是必須的，HTTP1.1中定義的管道可以在一個單獨的socket上傳送多個請求，管道效能優於持久連線。但IE7不支援，所以很多瀏覽器和伺服器仍然包含Keep-Alive。

==Request Headers==
Connection:keep-alive

==Response Headers==
Connection:keep-alive

規則1：減少HTTP請求

效能黃金法則中提到80%~90%時間花在HTML文件中元件下載。因此，減少元件的數量，並由此減少HTTP請求的數量。是改善響應時間的最簡單途徑。

圖片地圖

對於“圖片超連結”的情況，可以使用圖片地圖減少頁面圖片個數，從而減少HTTP請求。其分為伺服器端圖片地圖和客戶端圖片地圖，詳見：HTML5-嵌入內容

CSS Sprites

同圖片地圖，CSS Sprites也可合併圖片，將多個圖片合併到一個單獨的圖片中，使用CSS的background-position屬性將HTML元素放到背景圖片中期望的位置上。

<div style="background-image: url('sprites.git'); 
            background-position: -260px -90px; 
            width: 26px; height: 26px;">
</div>

注意：圖片地圖中的圖片必須是連續的，而CSS Sprites則沒有這個限制。

內斂圖片

通過使用data: [<mediatype>][;base64],<data>模式可以在Web頁面中包含圖片，而無需額外的HTTP請求（IE不支援）。要注意，在跨頁面時不會被快取。不要去內聯公司的logo，因為編碼過的logo會導致頁面變大。聰明的做法是：使用CSS將內聯圖片作為背景，將其放在外部樣式表中，資料可以快取在樣式表內部。雖然將內聯圖片放置在外部樣式表中增加了一個額外的HTTP請求（請求樣式表），但被快取後可以得到額外的收穫。當然，對於只使用一次（如，驗證碼）直接可以寫在頁面上。

示例：存放到樣式表

.cart {background-img: url(data:image/png;base64,/9j/4AAQSkZJRgABAgAAAQABAAD/2wBDA...)}

示例：直接頁面嵌入

<img src="data:image/png;base64,/9j/4AAQSkZJRgABAgAAAQABAAD/2wBDA..." />

合併指令碼和樣式表

合併指令碼和樣式表，是最普通不過的效能優化方式，可以使用Grunt、Webpack、Gulp等工具，這裡不再贅述。需要思考的是：一個多頁面的網站會有大量的模組，而模組的組合情況複雜，如何合併模組值得花時間去分析一下自己的頁面，確保組合的數量是可管理的。

規則2：使用內容釋出網路

內容釋出網路（CDN）是一組分佈在多個不同地理位置的Web伺服器，用於更加有效地向用戶釋出內容，其目的是使使用者可就近取得所需內容，解決 Internet網路擁擠的狀況，提高使用者訪問網站的響應速度。使用CDN，需要注意：更新內容後，CDN的生效時間！

規則3：新增Expires頭

Expires頭在前面已經闡述過，其目的主要是最大化利用瀏覽器的快取來改善頁面的效能。

Expires頭

瀏覽器（和代理）使用快取來減少HTTP請求的數量，並減少HTTP響應的大小。

==Response Headers==
Expires:Thu, 07 Apr 2019 08:30:15 GMT

其告訴瀏覽器可以使用該元件的快取，直到2019年4月7日上午8時30分15秒。

Max-Age和mod_expires

HTTP1.1中引入了Cache-Control來克服Expires頭的限制。Expires頭使用一個特定的時間，它要求伺服器和客戶端的時間嚴格同步（當然，可以通過Apache mode_expires模組中的ExpiresDefault以相對方式設定日期）；另外，過期日期需要經常檢查，一旦到達過去日期還需要在伺服器端配置中提供一個新的日期。

Cache-Control: max-age=秒數指定元件快取多久（下述，快取1年）。

==Response Headers==
Cache-Control: max-age=31536000

max-age可以消除Expires的限制，但對於不支援HTTP1.1的瀏覽器，可以同時設定二者。二者同時存在時，HTTP規定max-age指令將重寫Expires頭。

修訂檔名

如果我們將元件配置可以在瀏覽器端進行快取，當這些元件改變時使用者如何獲得更新呢？設定了Expires頭時，過期前會一直使用快取版本（從硬碟上讀取元件），瀏覽器不會更新。為了確保使用者能夠獲取元件的最新版本，需要在所有HTML頁面修改元件的檔名。常用方式是增加MD5戳。

規則4：配置ETag

實體標籤（Entity Tag，ETag）是Web伺服器和瀏覽器用於確認快取元件有效性的一種機制。

瀏覽器下載元件後，會進行快取，再次使用該元件時，會根據Expires頭的值，判斷是否發起請求。如果過期了，瀏覽器在重用之前必須檢查他是否仍然有效，傳送條件GET請求（前面已經提及）。如果是有效的，伺服器會返回“304 Not Modified”，不會返回整個元件；這比簡單地下載所有過期的元件效率要高。

伺服器在檢測快取元件是否和原始伺服器上的元件匹配時有兩種方式：

比較最新修改日期（If-Modified-Since ==> Last-Modified）
比較實體標籤（）

比較實體標籤

ETag在HTTP1.1中引入，ETag是唯一標識了一個元件的一個特定版本的字串。

==Request Headers==
GET /1/4/A/1_ligang2585116.jpg
Host: avatar.csdn.net

==Response Headers==
HTTP 1.1 200 OK
Last-Modified: Wed, 11 Nov 2015 20:24:15 GMT
ETag: "8224274EB79860E83F60346E0EEBE99A"
Content-Length: 19613

ETag的加入為驗證實體提供了比較新修改日期更靈活的機制。例如，如果實體依據User-Agent或Accept-Language頭而改變，實體的狀態可以反映在ETag中。瀏覽器會使用If-None-Match頭將ETag傳回原始伺服器以進行比較。如果伺服器上元件的ETag值與瀏覽器傳回的值匹配，返回304，不會傳送19613位元組的資料。

==Request Headers==
GET /1/4/A/1_ligang2585116.jpg
Host: avatar.csdn.net
If-Modified-Since: Wed, 11 Nov 2015 20:24:15 GMT
If-None-Match: "8224274EB79860E83F60346E0EEBE99A"

==Response Headers==
HTTP 1.1 304 Not Modified

ETag帶來的問題

ETag通常使用元件的某些屬性構造而成，這些屬性對應特定的、寄宿了網站伺服器來說是唯一的。當瀏覽器從一臺伺服器上獲取了原始元件，之後，又向另外一臺不同的伺服器傳送提交GET請求，ETag是不會匹配的–這對於伺服器叢集來處理請求的網站很常見，大大降低有效驗證的成功率。

If-None-Match比If-Modified-Since具有更高的優先順序。你可能希望如果ETag不匹配但最新修改時間相同，也能傳送一個“304 Not Modified”響應，但實際並不是這樣的。HTTP1.1規範https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.3.4，如果請求中同時出現了這兩個頭，則原始伺服器“禁止（MUST NOT）”返回304，除非請求中的條件頭欄位全部一致。

ETag—用還是不用

上面描述了ETag對於叢集式網站的嚴重問題。但你可能會說，利用長久Expires頭，使元件更長時間快取到客戶端，但是一旦使用者點選了Reload或Refresh按鈕，依然會產生條件GET請求。所以，你可以定義ETag只保留大小和時間戳作為內容，或者直接移除ETag。