一般來說,快取功能可透過儲存資料來提高效能,讓日後要求相同資料時,能更快速地提供資料。舉例來說,網路快取的資源可避免與伺服器的來回連線。快取的運算結果可省去執行相同運算所需的時間。
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
(資源網址)) 將圖片快取。(請注意,如果資源要求來自頂層 -frame,網路隔離金鑰中的頂層網站和目前的頁框網站會相同)。

https://b.example
, https://b.example
, https://x.example/doge.png
}
同一位使用者造訪另一個要求相同圖片 (https://x.example/doge.png
) 的網頁 (https://b.example
)。雖然先前範例已載入相同圖片,但由於鍵不相符,因此不會命中快取。
系統會從網路要求圖片,並使用由 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/
,然後按下「Stop Logging」。 - 前往
https://netlog-viewer.appspot.com/#import
。 - 按一下「選擇檔案」,然後傳送您儲存的記錄檔案。
您會看到記錄檔案的輸出內容。
在同一頁面中找到 SplitCacheByNetworkIsolationKey
。如果後面接著是 Experiment_[****]
,表示 Chrome 已啟用 HTTP 快取分區。如果後面接著 Control_[****]
或 Default_[****]
,則表示未啟用。
如何在 Chrome 上測試 HTTP 快取分區?
如要在 Chrome 上測試 HTTP 快取分區,您必須使用指令列標記 --enable-features=SplitCacheByNetworkIsolationKey
啟動 Chrome。請按照「使用旗標執行 Chromium」一文的操作說明,瞭解如何在您的平台上使用指令列旗標啟動 Chrome。
身為網頁開發人員,我是否需要針對這項異動採取任何行動?
這並非破壞性變更,但可能會對部分網路服務造成效能影響。
舉例來說,如果您在許多網站上提供大量可快取的資源 (例如字型和熱門指令碼),可能會發現流量有所增加。此外,使用這類服務的使用者可能會更加依賴這些服務。
(我們提出了「網路共用資料庫」(簡報影片) 的提案,以便以保護隱私權的方式啟用共用資料庫,但仍在審查中)。
這項行為變更會帶來哪些影響?
整體快取遺漏率增加約 3.6%,FCP (首次顯示內容所需時間) 的變化幅度不大 (約 0.3%),從網路載入的位元組整體比例則增加約 4%。如要進一步瞭解對效能造成的影響,請參閱 HTTP 快取分區說明。
這是否已標準化?其他瀏覽器的行為是否不同?
雖然「HTTP 快取區隔」已在擷取規格中標準化,但瀏覽器的行為有所不同:
- Chrome:使用頂層配置:eTLD+1 和框架配置:eTLD+1
- Safari:使用頂層 eTLD+1
- Firefox:預計使用頂層配置文件://eTLD+1 實作,並考慮加入 Chrome 等第二個鍵
如何處理從 worker 擷取的資料?
專用工作站會使用與目前影格相同的鍵。服務工作站和共用工作站可能會在多個頂層網站之間共用,因此較為複雜。我們目前正在討論解決方案。