概述

在前端開發中，性能一直都是被大家所重視的一點。然而判斷一個網站的性能最直觀的就是看網頁打開的速度，許多大型互聯網公司甚至將頁面響應速度作為考核的一個硬性標準。在性能方面，根據Yahoo的調查，后臺只占5％，而前端高達95％之多，其中有88％的東西是可以優化的。每一個前端工程師都應該思考過前端性能優化方面的問題。

WEB性能優化是一個工程問題，涵蓋很多方面，優化方向可以分為：請求數量、請求帶寬、緩存利用、頁面結構、代碼校驗。

技術人員都了解通過網絡提取內容既速度緩慢又開銷巨大。 較大的響應需要在客戶端與服務器之間進行多次往返通信，這會延遲瀏覽器獲得和處理內容的時間，還會增加訪問者的流量費用。 因此，緩存并重復利用之前獲取的資源的能力成為性能優化的一個關鍵方面。也是一種讓網站變快的極佳途徑。

緩存分為服務端側（server side，比如Nginx、Apache）和客戶端側（client side，比如web browser），今天我們主要了解一下瀏覽器緩存。

在瀏覽器中輸入目標網址時，瀏覽器會從服務器下載顯示頁面所需的資源，例如html、圖片、css、js，甚至包括字體文件等。然而這些文件中有許多文件（例如圖片）都是很少變動的，如果每次都要從服務器重新下載，會延長網頁載入時間，在業務量大的時候也會對服務器造成一定壓力。如大家熟悉的雙11、微博熱搜宕機事件。

瀏覽器緩存控制機制有兩種：HTML Meta標簽 和HTTP頭信息。

使用HTML Meta 標簽：

＜meta http－equiv＝＂Pragma＂ content＝＂no－cache＂＞

這部分代碼是應用在HTML文件中的head頭部分。主要作用就是告訴瀏覽器此HTML頁面不被緩存，每次訪問都去服務器上下載。使用上很簡單，但只有部分瀏覽器可以支持，而且所有緩存代理服務器都不支持，因為代理不解析HTML內容本身。所以常說的瀏覽器緩存還是通過http頭信息來控制緩存。

HTTP頭信息控制緩存

通過瀏覽器開發者工具我們可以看到，瀏覽器請求服務器靜態資源的響應狀態碼主要就是下圖的三種：

頁面的緩存狀態是由HTTP協議中關于緩存的信息頭決定的，主要的控制關鍵字有4種：Last－Modified，Etag，Cache－Control，Expires．

Cache－Control 和 Expires首部用于指定緩存時間；

Last－Modified和ETag 首部提供驗證機制。

Last－Modified／E－Tag

Last－Modified：標示這個響應資源的最后修改時間。web服務器在響應請求時，告訴瀏覽器資源的最后修改時間。當資源過期時（使用Cache－Control標識的max－age），發現資源具有Last－Modified聲明，則再次向web服務器請求時帶上頭 If－Modified－Since，表示請求時間。web服務器收到請求后發現有頭If－Modified－Since 則與被請求資源的最后修改時間進行比對。若最后修改時間較新，說明資源又被改動過，則響應整片資源內容（寫在響應消息包體內），HTTP 200；若最后修改時間較舊，說明資源無新修改，則響應HTTP 304 （無需包體，節省瀏覽），告知瀏覽器繼續使用所保存的cache。

Etag：web服務器響應請求時，告訴瀏覽器當前資源在服務器的唯一標識。Apache中，ETag的值，默認是對文件的索引節（INode），大小（Size）和最后修改時間（MTime）進行Hash后得到的。當資源過期時（使用Cache－Control標識的max－age），發現資源具有Etage聲明，則再次向web服務器請求時帶上頭If－None－Match （Etag的值）。web服務器收到請求后發現有頭If－None－Match 則與被請求資源的相應校驗串進行比對，決定返回200或304。

Etag和Last－Modified非常相似，都是通過一個參數來判斷，從而決定是否啟用緩存。也許大家有疑問那為什么HTTP1．1還有新定義一個Etag，它的出現主要是解決一下Last－Modified無能為力的事情：

1．Last－Modified標注的最后修改只能精確到秒，如果某些文件在1秒鐘以內，被修改多次的話，Last－Modified也就無法判斷。

2．一些資源的最后修改時間改變了，但是內容沒改變，使用ETag就認為資源還是沒有修改的。

3．有可能存在服務器不能準確獲取資源的最后修改時間，或者與代理服務器時間不一致等情形，這樣無法通過修改時間判斷資源是否更新

Cache－Control 和 Expires

從性能優化的角度來說，最佳請求是無需與服務器通信的請求：您可以通過響應的本地副本消除所有網絡延遲，以及避免數據傳送的流量費用。 為實現此目的，HTTP 規范允許服務器返回 Cache－Control 和 Expires指令，這些指令控制瀏覽器和其他中間緩存如何緩存各個響應以及緩存多久。在有效期內，直接訪問瀏覽器緩存，不會跟服務器交互。也就是上圖中的200（from disk cache）。

Expires：

Expires標示資源緩存失效時間，用來指定資源到期的時間，緩存服務器在接收到含有首部字段Expires的響應后，會以緩存來應答請求，在此此字段制定的時間之前，響應資源會一直被保存，在響應http請求時可以直接從瀏覽器緩存取數據，而無需再次請求。這里需要注意的是如果設置了cache－control的話cache－control的優先級更高。

Cache－control：

Cache－Control與Expires的作用一致，都是指明當前資源的有效期，控制瀏覽器是否直接從瀏覽器緩存取數據還是重新發請求到服務器取數據。Cache－Control 標頭是在HTTP／1．1 規范中定義的，取代了之前用來定義響應緩存策略的標頭（例如Expires）。 所有現代瀏覽器都支持Cache－Control，因此，使用它就夠了。

Cache－Control的設置值可以是no－cache、no－ store、public、private、max－age等：

Cache－Control是關于瀏覽器緩存的最重要的設置，因為它覆蓋其他設置，比如Expires 和Last－Modified。另外，由于瀏覽器的行為基本相同，這個屬性是處理跨瀏覽器緩存問題的最有效的方法。

在實際應用中只要可能，就給每種資源都指定一個明確的緩存時間。這樣客戶端就可以直接使用本地副本，而不必每次都請求相同的內容。類似地，指定驗證機制可以讓客戶端檢查過期的資源是否有更新。沒有更新，就沒必要重新發送。

最后，還要注意應同時指定緩存時間和驗證方法！只指定其中之一是最常見的錯誤，于是要么導致每次都在沒有更新的情況下重發相同內容（這是沒有指定驗證），要么導致每次使用資源時都多余地執行驗證檢查（這是沒有指定緩存時間）。當然這不意味著您所有的資源都需要緩存。一些網站的資源90％ 以上都可以緩存，而其他網站可能有許多私密或時效要求高的數據根本無法緩存。這個就需要在實際應用中根據實際情況去設定，確定哪些資源可以緩存，并確保其返回正確的Cache－Control 和ETag 標頭。

性能優化涵蓋太多的方面，以上簡單介紹一下瀏覽器緩存中的一些機制和概念，瀏覽器是否使用緩存、緩存多久，是由服務器控制的。以上規則都需要在對應服務器設置。如：ngnix，Apache 等，此處就不敘述了。

啟迪云－高級開發工程師 楊浩巍