前言

瀏覽器快取是前端效能優化的重要一環，對於前端效率提升的重要性，不言而喻。

之前對於瀏覽器快取也是一知半解，這次藉著H5頁面快取優化的東風整理了一下本地瀏覽器端的快取機制，如強制快取、協商快取等，並且然後結合門戶域各部件（官網、雲社群、雲市場、個人中心、APP）當前的快取機制進一步分解，旨在呈現下當前華為雲官網的快取策略，供大家參考。

1 瀏覽器快取

1.1 瀏覽器快取

快取是一種本地儲存遠端資源的機制，不管是在客戶端、還是在服務端儲存著，用相同的URL進行資料請求，可以直接從快取中請求資源而不再訪問源伺服器。

Web前端快取大致可以分為：資料庫快取、服程式設計客棧務器端快取（代理伺服器快取、CDN快取）、瀏覽器快取。

瀏覽器快取也包含很多內容：HTTP 快取、indexDB、cookie、localstorage 等等。這裡我們只討論 HTTP 快取相關內容。

1.2www.cppcns.com 瀏覽器快取的意義

瀏覽器在本地對使用者對最近請求過的文件進行儲存，當用戶再次訪問同一頁面時，瀏覽器就可以直接從本地磁碟載入檔案。瀏覽器快取的意義主要在：

a. 避免了冗餘的資料傳輸，節省流量；

b. 加快了使用者訪問網頁的速度；

c. 減小了伺服器的壓力。

2 快取型別

2.1 第一次請求資料

瀏覽器第一次請求資料時，瀏覽器快取中沒有對應的快取資料，此時需要請求伺服器，瀏覽器返回資料後，會把請求的資料儲存至快取資料庫中。

當瀏覽器中存在快取資料後，可以根據是否需要向伺服器傳送請求，將快取型別分為：強制快取和協商快取。

2.2 強制快取

使用者請求資料，如果命中強快取，則不向伺服器請求，而直接從本地資源獲取，返回200狀態碼，並提示from disk cache或from memory cache（比從disk快）。

2.3 協商快取

在使用者請求資源時，瀏覽器直接向伺服器傳送請求，協商對比服務端和本地的資源，驗證本地資源是否失效。

2.4 強制快取和協商快取的關係

強制快取和協商快取命中快取資源後，都是從本地讀取資源。如果強制快取生效，則不需要再向伺服器發出請求；而協商快取，不管是否使用快取，必須向伺服器傳送一個請求來協商。

兩類快取規則可以同時存在，強制快取優先順序高於協商快取，也就是說，當執行強制快取的規則時，如果快取生效，直接使用快取，不再執行協商快取規則。如果強制快取規則不生效，則需要進行協商快取判斷。

3 快取相關header

上文介紹了強制快取與協商快取的流程，那麼在瀏覽器中，瀏覽器如何判定快取資料是否失效呢？如何確認是否使用快取資料呢？

3.1 強制快取

強制快取的response header中會有兩個欄位來表明失效規則（Expires/Cache-Control）

1. Expires：Expires的值為服務端返回的到期時間，即下一次請求時，請求時間小於服務端返回的到期時間，直接使用快取資料。不過Expires 是HTTP 1.0的東西，現在預設瀏覽器均預設使用HTTP 1.1，所以它的作用基本忽略。另一個問題是，到期時間是由服務端生成的，但是客戶端時間可能跟服務端時間有誤差，這就會導致快取命中的誤差。 所以HTTP 1.1 的版本，使用Cache-Control替代。

2. Cache-Control：Cache-Control 是最重要的規則。常見的取值有private、public、no-cache、max-age，

Expires和Cache-Control的關係：

a. 相同點：兩者都是強快取。

b. 不同點：

• Expires是http1.0規定的，而Cache-Control是http1.1規定的。
• Expires的過期時間採用的是絕對時間，容易造成差錯； 而Cache-Control的過期時間採用的時相對時間，在快取上不會出現問題。
• 兩者可以同時存在於一次請求中，但是不會同時在一次請求中起作用。 在HTTP1.0的環境下，Cache-Control不起作用，Expires起作用； 在HTTP1.1的環境之下， Expires不起作用，而Cache-Control起作用。當前一般都是http1.1的情況，所以Expires是作為一種向下相容的形式而存在的。
• Cache-Control的選擇更多，功能更為強大，推薦使用。 Expires作為強快取，功UcOoo能單一，不推薦使用。

例如：下圖（華為雲官網首頁）中，檔案global.js的Cache-Control指定的快取失效時間max-age為86400s（1天）：

3.2 協商快取

協商快取一般是使用 if-modified-since/Last-Modified 和 if-none-match/Etag 由伺服器來決定瀏覽器快取的資源是否可以使用。

1. Last-Modified / If-Modified-Since

Last-Modified：伺服器響應請求時，告訴瀏覽器資源最後的修改時間。

If-Modified-Since：瀏覽器再次請求資源時，瀏覽器通知伺服器，上次請求時，返回的資源最後修改時間。

若最後修改時間小於等於If-Modified-Since，則response 程式設計客棧header返回304，告知瀏覽器繼續使用所儲存的cache。若大於If-Modified-Since，則說明資源被改動過，返回狀態碼200；

2. If-none-match / Etag

Etag：伺服器響應請求時，告訴瀏覽器當前資源在瀏覽器的唯一標識（生成規則由伺服器確定）

If-None-Match：再次請求伺服器時，通過此欄位通知伺服器客戶端快取資料的唯一標識。伺服器收到請求後發現有If-None-Match 則與被請求資源的唯一標識進行比對，不同，說明資源又被改動過，則響應整片資源內容，返回狀態碼200；相同，說明資源無新修改，則響應HTTP 304，告知瀏覽器繼續使用所儲存的cache。

Etag與Last-Modified對比：

1.在精確度上，Etag優於Last-Modified。Last-Modified精確到s，如果1s內，資源多次改變，Etag是可以判斷出來並返回最新的資源。

2.在效能上，Last-Modified優於Etag，因為Last-Modified只需要記錄時間，而Etag需要伺服器重新生成hash值，所以效能上略差。

3.在優先順序上，Etag優於Last-Modified，Etag和Last-Modified可同時存在。本地快取時間到期後，瀏覽器向服務端傳送請求報文，其中Request Header中包含If-none-match和Last-Modified-Since（與服務端Etag和Last-Modified對比，Etag優先順序高），用以驗證本地快取資料驗證是否與服務端保持一致。在伺服器端會優先判斷Etag。如果相同，返回304；如果不同，就繼續比較Last-Modified，然後決定是否返回新的資源。若服務端驗證本地快取與服務端一致，返回304，瀏覽器載入本地快取；否則，伺服器返回請求的資源，同時給出新的Etag以及Last-Modified時間。

3.3 快取請求

以下為瀏覽器快取的流程：

4 例項分析

對於客戶端來說，瀏覽器在使用本地快取資料時，需要對齊本地與伺服器的資源；但是，對於服務端，伺服器將資源下發給客戶端，服務端就失去了對齊的控制權。比如，服務端設定快取失效的max-age，在這段時間內，哪怕服務端資源已發生更改，服務端也無法通知客戶端資源更新通知。所以，對於一個網頁來說，需要合理的指定快取的廢棄與更新的響應策略，從而既能提升頁面載入速度，同時確保頁面的準確性。

以下結合華為雲官網各部件，分析快取的廢棄和更新的響應策略：

4.1 官網首頁：

註釋：

• Html：快取有效時間為0s，頁面載入時，強制瀏覽器每次向源伺服器確認資料；
• css：改動頻率較低，允許使用本地快取，且存在強制快取時間（各個css檔案不同，按需設定）；強制快取失效再進行協商快取；
• Js：允許使用本地快取，且存在強制快取時間（各個js檔案不同，按需設定）；強制快取失效再進行協商快取；
• Image：圖片修改頻率更低，允許使用本地快取，且存在強制快取時間（各個image檔案不同，按需設定）；強制快取失效再進行協商快取；
• Gif：官網中gif主要存在於banner輪播，因此確保時效性，使用no-cache，不允許快取，強制每次向源伺服器確認資料。

注意（以下已官網首頁為例，介紹快取與版本號的關係，其餘各部件都存在相同問題，後續不一一解釋。）：

上圖描述的是可快取檔案的快取策略。但是，網頁中還有很多檔案，比如global.js、global.css等，更新頻率較快，如果一直使用本地快取可能會影響頁面的正確性。因此，在引用這部分檔案時，會在檔案後添加個版本號，用以重新整理快取，以此確保本地資源的時效性，新增版本號的目的是為了強制要求檔案每次載入重新向服務端請求。如下，左圖給出了部分檔案的版本號字尾。這部分檔案在瀏覽器重新載入後，請求報文的標頭檔案，Request Header的Cache-control值為no-cache，即無快取，重新請求資料。如下右圖所示：

4.程式設計客棧2 社群

註釋：

• Html：快取許可權為public；本地快取到期時間expires為固定Thu,19 Nov 1981 08:52:00 GMT，也就是本地快取永遠是到期的；因此，每次載入頁面都需要重新向源伺服器獲取資源。
• Css：改動頻率較低，允許使用本地快取，且強制快取時間為1天；強制快取失效再進行協商快取；
• Js：允許使用本地快取，且強制快取時間為1天；強制快取失效再進行協商快取；
• Image：圖片修改頻率更低，png格式檔案允許使用本地快取，且強制快取時間為1周，jpg格式檔案為一月； 本地快取到期後，會繼續通過判定Etag和Last-Modified，驗證本地快取的有效性，（方法見3.2，優先順序）。圖片的快取策略中，強快取和協商快取同時存在，因為頁面中一般圖片資源較大，但是修改頻率較低，所以使用快取可以提升瀏覽器載入速度。

4.3 雲市場

註釋：

• Css：強制快取時間為1天；強制快取失效再進行協商快取；
• Js：強制快取時間為1天；強制快取失效再進行協商快取；
• Image：強制快取時間為1周；強制快取失效再進行協商快取；

4.4 個人中心

註釋：

• Css：強制快取時間為1天；強制快取失效再進行協商快取；
• Js：強制快取時間為1天或1周，不同檔案不同；強制快取失效再進行協商快取；
• Image：強制快取時間為1周；強制快取失效再進行協商快取；

4.5 論壇

註釋：

• Css：強制快取時間為1周；強制快取失效再進行協商快取；
• Js：強制快取時間為1周，不同檔案不同；強制快取失效再進行協商快取；
• Image：強制快取時間為1周；強制快取失效再進行協商快取；

4.6 App

移動端快取策略參考其餘部件快取機制，不另做展示。

總結

在現網頁面中，css、js、image等不同型別檔案的快取策略大致相同。即同時存在強快取和協商快取策略。對於強快取，給定本地快取的有效時間max-age，一般根據不同檔案型別的確定max-age大小；對於協商快取，給定Last-Modified和Etag標識，伺服器端驗證客戶端快取的有效性。本章中給出了，官網各部件瀏覽器端快取策略的簡介。但是，部分檔案會存在特殊的快取設定。比如，頁面中很多的js、css、image等會新增版本號，強制重新整理快取等。

以上就是詳解瀏覽器的快取機制的詳細內容，更多關於瀏覽器的快取機制的資料請關注我們其它相關文章！