一般而言，快取可透過儲存資料來提升效能，進而加快相同資料的日後要求速度。舉例來說，來自網路的快取資源可避免對伺服器進行往返作業。快取的運算結果可能會省略執行相同計算作業的時間。
在 Chrome 中，快取機制有多種用途，而 HTTP 快取就是其中之一。
Chrome 的 HTTP 快取目前的運作方式
自第 85 版起，Chrome 會快取從網路擷取的資源，將相關資源網址當做快取金鑰。(快取金鑰可用於識別快取資源)。
以下範例說明如何在三種不同的情境中快取及處理單一圖片：
https://x.example/doge.png }
使用者造訪要求圖片 (https://x.example/doge.png) 的頁面 (https://a.example)。系統會向網路要求圖片，並以 https://x.example/doge.png 做為金鑰進行快取。
https://x.example/doge.png }
同一名使用者造訪另一個頁面 (https://b.example)，該頁面要求相同的圖片 (https://x.example/doge.png)。瀏覽器會使用圖片網址做為金鑰，檢查其 HTTP 快取，確認這項資源是否已快取。瀏覽器會在其快取中尋找相符項目，因此會使用資源的快取版本。
https://x.example/doge.png }
即使圖片是從 iframe 載入也一樣。如果使用者透過 iframe (https://d.example) 造訪其他網站 (https://c.example)，且 iframe 要求相同的圖片 (https://x.example/doge.png)，瀏覽器仍可從快取載入圖片，因為所有網頁的快取金鑰都相同。
從效能的角度來看，這項機制一直在成效方面都很出色。但是，當網站回應 HTTP 要求時，可能會發現瀏覽器過去曾存取相同的資源，導致瀏覽器更容易遭受安全性和隱私權攻擊，如下所示：
- 偵測使用者是否造訪過特定網站：不肖人士可以檢查快取是否含有特定網站或網站同類群組專用的資源，藉此偵測使用者的瀏覽記錄。
- 跨網站搜尋攻擊：攻擊者可以檢查特定網站使用的「沒有搜尋結果」圖片是否在瀏覽器的快取中，藉此偵測使用者的搜尋結果中是否有任意字串。
- 跨網站追蹤：快取可用來儲存類似 Cookie 的 ID，做為跨網站追蹤機制。
為降低這類風險，Chrome 將從 Chrome 第 86 版開始分割 HTTP 快取。
快取分區對 Chrome 的 HTTP 快取有何影響？
如果使用快取分區，則系統在將快取資源加密時，除了資源網址之外，還會使用新的「網路隔離金鑰」。網路隔離金鑰由頂層網站和目前的頁框網站組成。
請再次查看先前的範例，瞭解快取分區在不同情況下的運作方式：
https://a.example, https://a.example, https://x.example/doge.png }
使用者造訪會要求圖片 (https://x.example/doge.png) 的網頁 (https://a.example)。在本例中，網路要求圖片，並使用包含 https://a.example (頂層網站)、https://a.example (目前頁框網站) 和 https://x.example/doge.png (資源網址) 的元組快取。(請注意，如果資源要求來自頂層頁框，網路隔離金鑰中的頂層網站和目前頁框網站相同)。
https://b.example, https://b.example, https://x.example/doge.png }
同一名使用者造訪另一個網頁 (https://b.example) 並要求相同的圖片 (https://x.example/doge.png)。雖然相同的圖片是在上一個範例中載入，但鍵不相符，因此不會發生快取命中。
系統會從網路要求圖片，並使用包含 https://b.example、https://b.example 和 https://x.example/doge.png 的元組進行快取。
https://a.example, https://a.example, https://x.example/doge.png }
現在使用者返回 https://a.example，但這次圖片 (https://x.example/doge.png) 嵌入 iframe 中。在這個範例中，鍵是包含 https://a.example、https://a.example 和 https://x.example/doge.png 的元組，且發生快取命中。(請注意，如果頂層網站和 iframe 是同一個網站，則可以使用頂層頁框快取的資源)。
https://a.example, https://c.example, https://x.example/doge.png }
使用者返回了 https://a.example，但這次圖片是由 https://c.example 的 iframe 代管。
在此情況下，系統會從網路下載圖片，因為快取中沒有任何資源與 https://a.example、https://c.example 和 https://x.example/doge.png 的金鑰相符。
https://a.example, https://c.example, https://x.example/doge.png }
如果網域含有子網域或通訊埠號碼，會怎麼樣？使用者造訪 https://subdomain.a.example，其中嵌入 iframe (https://c.example:8080) 會要求圖片。
金鑰是根據「scheme://eTLD+1」建立，因此會忽略子網域和通訊埠編號。因此在快取中找到了所需資料。
https://a.example, https://c.example, https://x.example/doge.png }
如果 iframe 是多次巢狀結構，該怎麼辦？使用者造訪了 https://a.example，其中嵌入了 iframe (https://b.example)，而 iframe 嵌入了另一個 iframe (https://c.example)，後者最後會要求圖片。
因為鍵是從頂層頁框 (https://a.example) 和載入資源的立即影格 (https://c.example) 取得，所以會在快取中找到所需資料。
常見問題
我的 Chrome 是否已啟用此功能？該如何確認？
這項功能將於 2020 年底推出。如要檢查您的 Chrome 執行個體是否支援該執行個體，請按照以下步驟操作：
- 開啟
chrome://net-export/，然後按下「Start Logging to Disk」(開始記錄至磁碟)。 - 指定記錄檔儲存在電腦上的位置。
- 使用 Chrome 快速瀏覽網路。
- 返回
chrome://net-export/，然後按下「停止 Logging」。 - 前往
https://netlog-viewer.appspot.com/#import。 - 按下「Choose File」，然後傳遞您儲存的記錄檔。
畫面會顯示記錄檔的輸出內容。
在同一頁面中找出 SplitCacheByNetworkIsolationKey。如果後面接著 Experiment_[****]，表示 Chrome 已啟用 HTTP 快取分區。如果後面接著 Control_[****] 或 Default_[****]，則代表未啟用。
如何在 Chrome 上測試 HTTP 快取分區？
如要在 Chrome 中測試 HTTP 快取分區，您需要使用指令列標記啟動 Chrome：--enable-features=SplitCacheByNetworkIsolationKey。按照使用旗標執行 Chromium 中的操作說明，瞭解如何在平台上使用指令列旗標啟動 Chrome。
身為網頁程式開發人員，我應該根據這項異動採取哪些行動？
這並非破壞性變更，但可能會為部分網路服務造成效能考量。
舉例來說，在多個網站提供大量高快取的資源 (例如字型和熱門指令碼)，流量可能會增加。此外，使用這類服務的人員可能會更仰賴這些服務。
(我們提議在網站共用資料庫 (呈現影片) 中以保護隱私權的方式啟用共用程式庫，但目前仍在規劃階段。
這項行為異動有何影響？
整體快取失敗率大約增加 3.6%，變更 FCP (首次顯示內容所需時間) 相當簡單 (約 0.3%)，而從網路載入的位元組總數則增加約 4%。如要進一步瞭解對效能的影響，請參閱 HTTP 快取分區說明。
這是標準化的嗎？其他瀏覽器的運作方式是否不同？
雖然瀏覽器的行為不同，但「HTTP 快取分區」會在擷取規格中標準化：
- Chrome：使用頂層 scheme://eTLD+1 和 frame scheme://eTLD+1
- Safari：使用頂層 eTLD+1
- Firefox：規劃使用頂層 scheme://eTLD+1 並考慮加入第二個金鑰，例如 Chrome
如何處理 worker 中的擷取作業？
專用工作站會使用與目前影格的相同金鑰。由於 Service Worker 和共用工作站可能會由多個頂層網站共用，因此更為複雜。並正在討論這項解決方案。