oogle Chrome、Internet Explorer、Mozilla Firefox、Safari，這些對于當今大多數使用互聯網的人來說并不陌生。在當今時代，我們都非常熟悉這些網絡瀏覽器，這是世界上使用最廣泛的軟件。在那個頂部寬大的白色框中，您以寫下要導航到的任何網站地址，例如 www.facebook.com、www.google.com、www.medium.com，然后立即顯示該頁面。你有沒有想過該網站是如何出現在你的屏幕上的？

什么是瀏覽器？

瀏覽器是一種軟件程序，用于在萬維網上呈現和探索內容。這些內容（包括圖片、視頻和網頁）使用超鏈接（類似于網頁地址）進行連接，并使用統一資源標識符 （URL） 進行分類。第一個是由萬維網本身的發明者蒂姆·伯納斯-李（Tim Berners-Lee）于1990年創建的。在那之后，現在有許多網絡瀏覽器可供消費者使用，具有多功能功能。

瀏覽器始終需要服務器（旨在處理請求并通過本地網絡或 Internet 將數據傳送到其他（客戶端）計算機的計算機）。當您在瀏覽器的地址欄中輸入任何網頁的任何URL（統一資源定位器）時，它會從服務器獲取包含圖像，PDF，視頻，Flash文件的HTML文件，解釋它們，然后將其顯示在屏幕上。

但是，瀏覽器如何解釋這些HTML文件？現在，瀏覽器如何解釋這些HTML文件？瀏覽器顯示網頁方式的 HTML 和 CSS 規范由 W3C（萬維網聯盟）組織維護，該組織是萬維網的主要國際標準組織。

當在瀏覽器中鍵入任何 URL 時會發生什么？

當在 Web 瀏覽器中鍵入任何 URL 時，為了加載頁面，它首先必須找到 Web 服務器的 IP 地址。它要求操作系統 （OS） 檢查本地緩存中的服務器名稱。如果它存在于緩存中，則渲染引擎將渲染網頁。

1. 檢查瀏覽器緩存：為了加載頁面，瀏覽器首先必須找到 Web 服務器的 IP 地址。瀏覽器在固定的持續時間內維護 DNS 記錄的緩存。因此，這是解析DNS查詢的第一個地方。它檢查本地緩存，如果請求的對象在緩存中并且是新的，請跳到步驟 9
2. 檢查操作系統緩存：如果瀏覽器的緩存中不包含該記錄，它會對底層操作系統進行系統調用以獲取服務器的 IP 地址，因為操作系統還維護最近 DNS 查詢的緩存。
3. 路由器緩存：如果上述步驟無法獲取DNS記錄，則搜索將繼續到具有自己緩存的路由器。
4. ISP 緩存：如果一切都失敗，搜索將轉移到您的 ISP。首先，如果找不到，它會嘗試在緩存中 - ISP的DNS遞歸搜索進入畫面。DNS查找也是一個復雜的過程，它從Google等網站可用的許多選項列表中找到適當的IP地址。
5. 找到 IP 地址后，瀏覽器會啟動與服務器的 TCP 連接（此步驟使用 HTTPS 要復雜得多）。
6. 瀏覽器根據HTTP（超文本傳輸協議）協議的規范，通過TCP連接向服務器發送HTTP GET請求。
7. 瀏覽器收到 HTTP 響應，并可能關閉 TCP 連接，或將其重用于其他請求
8. 獲取請求的文件后，瀏覽器有兩件事要做：解釋和渲染 HTML 頁面，并獲取剩余的對象（圖像、flash 文件、javascript 文件、css 文件、音頻、視頻等）并解釋和顯示它們。
9. 一些瀏覽器會立即開始解釋和呈現 HTML 文件，并并行請求對象，在接收對象時填充對象。其他人將等待接收所有對象，然后渲染并顯示 HTML 文件。
10. html 內容的呈現也是分階段完成的。瀏覽器首先渲染裸骨 html 結構，然后發送多個 GET 請求來獲取其他超鏈接內容，例如，如果 html 響應包含 img 標簽形式的圖像，例如 <img src=“/assets/img/set.png” />，瀏覽器將向服務器發送一個 HTTP GET 請求，以按照我們目前看到的完整步驟集獲取圖像。但這并不像看起來那么糟糕。靜態文件（如圖像、javascript、css 文件）都由瀏覽器緩存，以便將來不必再次獲取它們。
11. 然后，瀏覽器將停止等待用戶請求另一個文件以重新開始一切。

者：kevinylzhao，騰訊音樂前端開發工程師

瀏覽器緩存策略對于前端開發同學來說不陌生，大家都有一定的了解，但如果沒有系統的歸納總結，可能三言兩語很難說明白，甚至說錯，尤其在面試過程中感觸頗深，很多候選人對這類基礎知識竟然都是一知半解，說出幾個概念就沒了，所以重新歸納總結下，溫故而知新。

Web 緩存介紹

• Web 緩存是指一個 Web 資源（如 html 頁面，圖片，js，數據等）存在于 Web 服務器和客戶端（瀏覽器）之間的副本。
• 緩存會根據進來的請求保存輸出內容的副本；當下一個請求來到的時候，如果是相同的 URL，緩存會根據緩存機制決定是直接使用副本響應訪問請求，還是向源服務器再次發送請求。

Web 緩存的好處

• 減少網絡延遲，加快頁面打開速度
• 減少網絡帶寬消耗
• 降低服務器壓力
• ...

HTTP 的緩存機制

簡化的流程如下

根據什么規則緩存

1. 新鮮度（過期機制）：也就是緩存副本有效期。一個緩存副本必須滿足以下條件，瀏覽器會認為它是有效的，足夠新的：

• 含有完整的過期時間控制頭信息（HTTP 協議報頭），并且仍在有效期內；
• 瀏覽器已經使用過這個緩存副本，并且在一個會話中已經檢查過新鮮度；

2. 校驗值（驗證機制）：服務器返回資源的時候有時在控制頭信息帶上這個資源的實體標簽 Etag（Entity Tag），它可以用來作為瀏覽器再次請求過程的校驗標識。如果發現校驗標識不匹配，說明資源已經被修改或過期，瀏覽器需求重新獲取資源內容。

HTTP 緩存的兩個階段

瀏覽器緩存一般分為兩類：強緩存（也稱本地緩存）和協商緩存（也稱弱緩存）。

本地緩存階段

瀏覽器發送請求前，會先去緩存里查看是否命中強緩存，如果命中，則直接從緩存中讀取資源，不會發送請求到服務器。否則，進入下一步。

協商緩存階段

當強緩存沒有命中時，瀏覽器一定會向服務器發起請求。服務器會根據 Request Header 中的一些字段來判斷是否命中協商緩存。如果命中，服務器會返回 304 響應，但是不會攜帶任何響應實體，只是告訴瀏覽器可以直接從瀏覽器緩存中獲取這個資源。如果本地緩存和協商緩存都沒有命中，則從直接從服務器加載資源。

啟用&關閉緩存

按照本地緩存階段和協商緩存階段分類：

1. 使用 HTML Meta 標簽 　　 Web 開發者可以在 HTML 頁面的節點中加入標簽，如下：

上述代碼的作用是告訴瀏覽器當前頁面不被緩存，事實上這種禁用緩存的形式用處很有限：

a. 僅有 IE 才能識別這段 meta 標簽含義，其它主流瀏覽器僅識別“Cache-Control: no-store”的 meta 標簽。

b. 在 IE 中識別到該 meta 標簽含義，并不一定會在請求字段加上 Pragma，但的確會讓當前頁面每次都發新請求（僅限頁面，頁面上的資源則不受影響）。

2. 使用緩存有關的 HTTP 消息報頭 這里需要了解 HTTP 的基礎知識。一個 URI 的完整 HTTP 協議交互過程是由 HTTP 請求和 HTTP 響應組成的。有關 HTTP 詳細內容可參考《Hypertext Transfer Protocol — HTTP/1.1》、《HTTP 權威指南》等。

在 HTTP 請求和響應的消息報頭中，常見的與緩存有關的消息報頭有：

上圖中只是常用的消息報頭，下面來看下不同字段之間的關系和區別：

1. Cache-Control 與 Expires
2. Cache-Control：HTTP1.1 提出的特性，為了彌補 Expires 缺陷加入的，提供了更精確細致的緩存功能。詳細了解詳細看幾個常見的指令：_ max-age：功能和 Expires 類似，但是后面跟一個以“秒”為單位的相對時間，來供瀏覽器計算過期時間。_ no-cache：提供了過期驗證機制。(在 Chrome 的 devtools 中勾選 Disable cache 選項，發送的請求會去掉 If-Modified-Since 這個 Header。同時設置 Cache-Control:no-cache Pragma:no-cache，每次請求均為 200)

• no-store：表示當前請求資源禁用緩存；
• public：表示緩存的版本可以被代理服務器或者其他中間服務器識別；
• private：表示只有用戶自己的瀏覽器能夠進行緩存，公共的代理服務器不允許緩存。
• Expires：HTTP1.0 的特性，標識該資源過期的時間點，它是一個絕對值，格林威治時間（Greenwich Mean Time, GMT），即在這個時間點之后，緩存的資源過期；優先級：Cache-Control 優先級高于 Expires，為了兼容，通常兩個頭部同時設置；瀏覽器默認行為：其實就算 Response Header 中沒有設置 Cache-Control 和 Expires，瀏覽器仍然會緩存某些資源，這是瀏覽器的默認行為，是為了提升性能進行的優化，每個瀏覽器的行為可能不一致，有些瀏覽器甚至沒有這樣的優化。

1. Last-Modified 與 ETag
2. Last-Modified(Response Header)與 If-Modified-Since(Request Header)是一對報文頭，屬于 http 1.0。If-Modified-Since 是一個請求首部字段，并且只能用在 GET 或者 HEAD 請求中。Last-Modified 是一個響應首部字段，包含服務器認定的資源作出修改的日期及時間。當帶著 If-Modified-Since 頭訪問服務器請求資源時，服務器會檢查 Last-Modified，如果 Last-Modified 的時間早于或等于 If-Modified-Since 則會返回一個不帶主體的 304 響應，否則將重新返回資源。(注意：在 Chrome 的 devtools 中勾選 Disable cache 選項后，發送的請求會去掉 If-Modified-Since 這個 Header。)

• ETag 與 If-None-Match 是一對報文頭，屬于 http 1.1。ETag 是一個響應首部字段，它是根據實體內容生成的一段 hash 字符串，標識資源的狀態，由服務端產生。If-None-Match 是一個條件式的請求首部。如果請求資源時在請求首部加上這個字段，值為之前服務器端返回的資源上的 ETag，則當且僅當服務器上沒有任何資源的 ETag 屬性值與這個首部中列出的時候，服務器才會返回帶有所請求資源實體的 200 響應，否則服務器會返回不帶實體的 304 響應。
• ETag 能解決什么問題？

a. Last-Modified 標注的最后修改只能精確到秒級，如果某些文件在 1 秒鐘以內，被修改多次的話，它將不能準確標注文件的新鮮度；

b. 某些文件也許會周期性的更改，但是它的內容并不改變(僅僅改變的修改時間)，但 Last-Modified 卻改變了，導致文件沒法使用緩存；

c. 有可能存在服務器沒有準確獲取文件修改時間，或者與代理服務器時間不一致等情形。

• 優先級：ETag 優先級比 Last-Modified 高，同時存在時會以 ETag 為準。

緩存位置

瀏覽器可以在內存、硬盤中開辟一個空間用于保存請求資源副本。我們經常調試時在 DevTools Network 里看到 Memory Cache（內存緩存）和 Disk Cache（硬盤緩存），指的就是緩存所在的位置。請求一個資源時，會按照優先級（Service Worker -> Memory Cache -> Disk Cache -> Push Cache）依次查找緩存，如果命中則使用緩存，否則發起請求。這里先介紹 Memory Cache 和 Disk Cache。

200 from memory cache

表示不訪問服務器，直接從內存中讀取緩存。因為緩存的資源保存在內存中，所以讀取速度較快，但是關閉進程后，緩存資源也會隨之銷毀，一般來說，系統不會給內存分配較大的容量，因此內存緩存一般用于存儲較小文件。同時內存緩存在有時效性要求的場景下也很有用（比如瀏覽器的隱私模式）。

200 from disk cache

表示不訪問服務器，直接從硬盤中讀取緩存。與內存相比，硬盤的讀取速度相對較慢，但硬盤緩存持續的時間更長，關閉進程之后，緩存的資源仍然存在。由于硬盤的容量較大，因此一般用于存儲大文件。

下圖可清晰看出差別：

200 from prefetch cache

在 preload 或 prefetch 的資源加載時，兩者也是均存儲在 http cache，當資源加載完成后，如果資源是可以被緩存的，那么其被存儲在 http cache 中等待后續使用；如果資源不可被緩存，那么其在被使用前均存儲在 memory cache。

CDN Cache

以騰訊 CDN 為例：X-Cache-Lookup:Hit From MemCache 表示命中 CDN 節點的內存；X-Cache-Lookup:Hit From Disktank 表示命中 CDN 節點的磁盤；X-Cache-Lookup:Hit From Upstream 表示沒有命中 CDN。

整體流程

從上圖能感受到整個流程，比如常見兩種刷新場景：

• 當 F5 刷新網頁時，跳過強緩存，但是會檢查協商緩存；
• 當 Ctrl + F5 強制刷新頁面時，直接從服務器加載，跳過強緩存和協商緩存

其他 Web 緩存策略

IndexDB

IndexedDB 就是瀏覽器提供的本地數據庫，能夠在客戶端存儲可觀數量的結構化數據，并且在這些數據上使用索引進行高性能檢索的 API。

異步 API 方法調用完后會立即返回，而不會阻塞調用線程。要異步訪問數據庫，要調用 window 對象 indexedDB 屬性的 open() 方法。該方法返回一個 IDBRequest 對象 (IDBOpenDBRequest)；異步操作通過在 IDBRequest 對象上觸發事件來和調用程序進行通信。

常用異步 API 如下：

在 16 年曾基于 IndexDB 做過一整套緩存策略，有不錯的優化效果：

Service Worker

SW 從 2014 年提出的草案到現在已經發展很成熟了，基于 SW 做離線緩存，讓用戶能夠進行離線體驗，消息推送體驗，離線緩存能力涉及到 Cache 和 CacheStorage 的概念，篇幅有限，不展開了。

LocalStorage

localStorage 屬性允許你訪問一個 Document 源(origin)的對象 Storage 用于存儲當前源的數據，除非用戶人為清除(調用 localStorage api 或者清除瀏覽器數據)， 否則存儲在 localStorage 的數據將被長期保留。

SessionStorage

sessionStorage 屬性允許你訪問一個 session Storage 對象，用于存儲當前會話的數據，存儲在 sessionStorage 里面的數據在頁面會話結束時會被清除。頁面會話在瀏覽器打開期間一直保持，并且重新加載或恢復頁面仍會保持原來的頁面會話。

定義最優緩存策略

• 使用一致的網址：如果您在不同的網址上提供相同的內容，將會多次獲取和存儲該內容。注意：URL 區分大小寫！
• 確定中繼緩存可以緩存哪些資源：對所有用戶的響應完全相同的資源很適合由 CDN 或其他中繼緩存進行緩存；
• 確定每個資源的最優緩存周期：不同的資源可能有不同的更新要求。審查并確定每個資源適合的 max-age；
• 確定網站的最佳緩存層級：對 HTML 文檔組合使用包含內容特征碼的資源網址以及短時間或 no-cache 的生命周期，可以控制客戶端獲取更新的速度；
• 更新最小化：有些資源的更新比其他資源頻繁。如果資源的特定部分（例如 JS 函數或一組 CSS 樣式）會經常更新，應考慮將其代碼作為單獨的文件提供。這樣，每次獲取更新時，剩余內容（例如不會頻繁更新的庫代碼）可以從緩存中獲取，確保下載的內容量最少；
• 確保服務器配置或移除 ETag：因為 Etag 跟服務器配置有關，每臺服務器的 Etag 都是不同的；
• 善用 HTML5 的緩存機制：合理設計啟用 LocalStorage、SessionStorage、IndexDB、SW 等存儲，會給頁面性能帶來明顯提升；
• 結合 Native 的強大存儲能力：善于利用客戶端能力，定制合適的緩存機制，打造極致體驗。

結語

通過了解瀏覽器各種緩存機制和存儲能力特點，結合業務制定合適的緩存策略，善用緩存是基本功，可以用于時常審查負責的業務，可能就會發現個別業務并沒有運用到位，共勉。