Chrome 會進行變更，讓使用 Cache-Control: no-store 的網頁在安全無虞的情況下，使用前進/後退快取 (bfcache)。瞭解這對開發人員的意義。
背景
將 Cache-Control: no-store 設為 HTTP 標頭，即表示網頁不應儲存在 HTTP 快取中。這項指令應用於含有機密資料的頁面，例如使用者登入時的頁面，但 no-store 指令通常用於不含機密資料的頁面。
使用 bfcache 時，我們會延後銷毀作業並暫停 JS 執行作業，而不是在使用者離開時銷毀網頁。如果使用者稍後返回瀏覽，系統會重新顯示該頁面，並取消暫停執行 JS。這樣一來，使用者就能幾乎立即瀏覽網頁。
雖然 HTML 規格並未規定這項做法，但瀏覽器通常會將 Cache-Control: no-store 視為信號，避免將網頁放入 bfcache。這也是不使用 bfcache 的主要原因，約占行動裝置上 17% 的瀏覽記錄導覽和電腦上 7% 的瀏覽記錄導覽。這表示這些網頁無法享有快速還原功能的優勢，必須完全重新載入網頁，包括任何網路呼叫、JavaScript 執行作業和轉譯作業。
通常會設定 Cache-Control: no-store，以便在網站變更時避免快取問題，但在使用 bfcache 時，這項原因就沒那麼重要，因為系統會還原整個網頁，就像一直保持開啟狀態一樣。
Chrome 對這項行為的變更方式
Chrome 已宣布將變更這項行為，但會謹慎處理這項變更。自 Chrome 116 起，我們就一直在進行實驗，直到最近才在 5% 的網頁載入作業中執行這些實驗。
我們已將這項功能的使用率提高至 10%，並打算在 11 月進一步提高至 20%，在明年初提高至 50%，之後不久就會全面推出這項功能，並在後續討論特定的選擇退出選項。
敏感資料
雖然我們的分析結果顯示，大多數的返回或前進導覽都不會包含機密資料，因此應該符合 bfcache 的使用資格，但有些情況下，網頁不應放入 bfcache。舉例來說，在登出時，使用者不應透過前後瀏覽來擷取已登入的頁面。
為避免這種情況，Chrome 會在 Cookie 或其他授權方法發生變更時，從 bfcache 中移除網頁。
此外，如果網頁使用 Cache-Control: no-store，且使用下列 API，則該網頁將繼續無法使用 bfcache：
請注意，這不是完整的 API 清單，這些 API 可防止使用 bfcache，但在 Cache-Control: no-store 頁面上封鎖 bfcache，即使在離開該頁面時未使用這些 API 也一樣。
為進一步降低風險，Cache-Control: no-store 網頁的 bfcache 逾時設定也會縮短為 3 分鐘 (不使用 Cache-Control: no-store 的網頁則為 10 分鐘)。
企業選擇不採用
企業通常很難更新軟體和共用裝置。您可以停用 AllowBackForwardCacheForCacheControlNoStorePageEnabled 政策，繼續禁止 Cache-Control: no-store 網頁使用 bfcache。
測試變更
開發人員可以使用下列旗標測試這項變更：
--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 時，可能也考量了類似的因素。
對效能造成的影響
我們做出這項異動的原因，是為了改善使用者在網路上的網頁體驗。我們發現，當初推出 bfcache 時，Core Web Vitals 有明顯改善，現在我們希望將這些改善項目推廣至更多網站。
隨著 Core Web Vitals 的推出，網站擁有者可能會發現網站體驗有改善，而且還可在 CrUX 中評估 bfcache 用量 (包括 CrUX 資訊主頁)。
影響分析
從 bfcache 還原舊網頁 (包括 JavaScript 堆積)，而不是重新載入網頁。許多熱門的數據分析服務供應商不會將 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');
}
});
處理網頁還原作業的更新
現在，網站如未看到這項資訊，或會以最新資料完整重新載入網頁時，可能會看到 bfcache 使用量。
您可以使用 pageshow 事件和檢查 persisted 屬性，以類似的方式觸發更新，為 Analytics 記錄其他網頁瀏覽次數。
請注意，並非所有內容都需要更新，而且使用者可能會選擇「返回」先前瀏覽的內容。舉例來說，重新整理文章清單可能會導致使用者無法再查看想看的文章。
對廣告的影響
與數據分析的影響類似，如果網站只載入網頁載入，廣告曝光次數可能會減少。您可以透過程式設計在 bfcache 還原時重新整理廣告，以確保與整個網頁載入的一致性，再次使用 pageshow 事件並檢查 persisted 屬性，但這不一定是正確的做法。請參閱廣告供應商的說明文件，瞭解如何觸發廣告重新載入。
進一步瞭解 bfcache
如要進一步瞭解 bfcache，請參閱完整的 bfcache 技術指南。
意見回饋
我們很期待聽到你對這項異動的意見回饋，歡迎前往 Chrome 問題追蹤器，使用 bfcache 元件提供意見。
結論
我們很高興能將 bfcache 的優點運用在更多網頁上，為使用者提供更優質的網頁體驗。我們已仔細考量這項異動，並盡可能以安全的方式推出。我們希望這篇文章的資訊能協助開發人員瞭解這項異動，並在發生異動時採取必要的調整，以免發生問題。