發布日期：2024 年 10 月 21 日，上次更新日期：2025 年 9 月 9 日
Chrome 即將進行變更，允許網頁在安全無虞的情況下使用 返回/快轉快取 (bfcache)。瞭解這項變更對開發人員的影響。Cache-Control: no-store
背景
將 Cache-Control: no-store 設為 HTTP 標頭，表示網頁不應儲存在 HTTP 快取中。這項指令應適用於含有私密資料的網頁 (例如使用者登入時的網頁)，但 no-store 指令通常也用於不含私密資料的網頁。
使用 bfcache 時，我們不會在使用者離開網頁時銷毀網頁，而是延後銷毀並暫停執行 JS。如果使用者很快就返回，我們會再次顯示網頁，並繼續執行 JavaScript。使用者幾乎可以立即瀏覽網頁。
雖然 HTML 規格並未規定，但瀏覽器通常會將 Cache-Control: no-store 視為信號，避免將網頁放入 bfcache。這是未使用 bfcache 的最大原因，在行動裝置上約有 17% 的歷來導覽，在電腦上則有 7% 的歷來導覽。也就是說，這些網頁無法快速還原，必須完整重新載入網頁，包括所有網路呼叫、JavaScript 執行和轉譯。
通常會設定 Cache-Control: no-store，避免網站變更時發生快取問題，但使用 bfcache 時，這個原因就比較不重要，因為系統會還原整個網頁，幾乎就像網頁一直處於開啟狀態。
Chrome 如何變更這項行為
Chrome 已宣布有意變更這項行為，但會謹慎處理這項異動。自 Chrome 116 版起，我們就開始進行實驗，逐步提高網頁載入的百分比，預計在 2025 年 3 月和 4 月達到 100%。
敏感資料
分析結果顯示，大多數返回或前進導覽都不包含敏感資料，因此應符合 bfcache 的資格，但有些網頁不應放入 bfcache。舉例來說，使用者登出後，不應能透過返回或前進操作擷取登入頁面。
為避免發生這種情況，Chrome 會在 Cookie 或其他授權方法變更時，將網頁從 bfcache 中逐出。
此外，如果網頁使用 Cache-Control: no-store，且使用下列 API，這些網頁仍不適用往返快取：
請注意，這並非會阻礙 bfcache 使用的完整 API 清單，而是即使在離開網頁時未使用，也會在 Cache-Control: no-store 頁面封鎖 bfcache 的 API。
Cache-Control: no-store 網頁的往返快取逾時時間也縮短為 3 分鐘 (未使用 Cache-Control: no-store 的網頁為 10 分鐘)，進一步降低風險。
企業退出選項
企業通常難以更新軟體和共用裝置。您可以停用 AllowBackForwardCacheForCacheControlNoStorePageEnabled 政策，繼續禁止 Cache-Control: no-store 網頁使用往返快取。
測試變更
開發人員可以使用下列旗標測試這項變更：
--enable-features=CacheControlNoStoreEnterBackForwardCache:level/restore-unless-cookie-change
如果適用任何先前的例外狀況 (例如 Cookie 變更)，網頁就無法使用 bfcache，Chrome 開發人員工具 bfcache 測試人員會顯示「Pages whose main resource has Cache-Control: no-store cannot enter back/forward cache.」(主要資源含有 Cache-Control: no-store 的網頁無法進入往返快取)。
您可以使用這個 bfcache 測試頁面，測試是否啟用這個標記。
開發人員須知
雖然開發人員不必進行任何變更，使用者就能享有 bfcache 使用率提升的好處，但開發人員可能需要考量以下事項。其他網站在 2021 年 12 月首次推出 bfcache 時，可能也遇到類似情況。
開發人員是否仍應盡量減少使用 Cache-Control: no-store？
在上述有限情況下，系統會為 Cache-Control: no-store 啟用 bfcache，且僅限 Chrome。使用 Cache-Control: no-store 時，其他瀏覽器可能仍會封鎖 bfcache 用法。
最佳做法仍是盡量減少使用 Cache-Control: no-store，而非依賴這些啟發式方法。
對成效的影響
我們進行這項變更，是為了改善網路上使用者的網頁體驗。我們在首次推出 bfcache 時，發現網站體驗核心指標有顯著改善，現在希望將這些改善帶給更多網站。
這項功能推出後，網站擁有者可能會發現網站體驗核心指標有所改善，並可在 CrUX 中評估 bfcache 使用情況，包括 CrUX Vis。
影響分析
從 bfcache 還原網頁時，系統會「還原」舊網頁 (包括 JavaScript 堆積)，而不是重新載入網頁。許多熱門的 Analytics 供應商不會將 bfcache 還原視為新的網頁瀏覽，因為這些供應商只會在網頁首次載入時觸發網頁瀏覽。
因此，網站首次使用 bfcache 時，分析資料中的網頁載入次數可能會減少。建議您將這些事件視為網頁瀏覽，方法是為 pageshow 事件設定監聽器，並檢查 persisted 屬性：
// Send a pageview when the page is first loaded.
gtag('event', 'page_view');
// Send another pageview if the page is restored from bfcache.
window.addEventListener('pageshow', (event) => {
if (event.persisted) {
// Page was restored from bfcache, sent another page view.
gtag('event', 'page_view');
}
});
處理網頁還原時的更新
網站現在可能會看到往返快取的使用情形，但先前並非如此，且網頁會改為重新載入最新資料，因此開發人員不妨考慮在還原往返快取時重新整理資料。
觸發更新的方式與使用 pageshow 事件記錄其他網頁瀏覽次數以供 Analytics 分析時類似，並檢查 persisted 屬性。
請注意，並非所有內容都需要更新，使用者可能偏好「返回」先前看過的內容。舉例來說，如果使用者重新整理文章清單，可能就無法再看到原本要返回查看的文章。
對廣告的影響
與對 Analytics 的影響類似，如果廣告只在網頁載入時載入，網站的廣告曝光次數可能會減少。在 bfcache 還原時，廣告可以透過程式輔助方式重新整理，確保與完整網頁載入作業一致，同樣是使用 pageshow 事件並檢查 persisted 屬性，但不一定適合這麼做。請參閱廣告供應商的文件，瞭解如何觸發廣告重新載入。
進一步瞭解 bfcache
如要進一步瞭解 bfcache，請參閱這份完整的 bfcache 技術指南。
意見回饋
我們很期待收到您對這項異動的意見回饋，歡迎使用 Chrome 的問題追蹤器，並透過 bfcache 元件提供意見。
結論
我們很高興能將 bfcache 的優點帶給更多網頁，進一步提升使用者體驗。我們已仔細考量這項異動，並盡可能以安全的方式推出。希望本文提供的資訊有助於開發人員瞭解這項異動，並進行必要變更，以免發生問題。