Chrome 在 10 月 16 日宣布：從 Chrome 155 起，unload 事件預設不再觸發，歷時一年半的分階段淘汰正式完成。使用 unload 的導覽從 18% 降到不到 4%，額外約 5% 的導覽因此能用上 bfcache 瞬間返回。給品牌官網、電商與行銷團隊：還靠 unload 送追蹤、存資料的程式碼，現在該搬家了。
每個網站都有一位「下班前最後一個關燈的同事」。他負責在大家離開時存檔、收拾桌面、順手寄出今天的報表。
在網頁世界裡，這位同事叫做 unload。
問題是，這位同事其實很常翹班。手機把背景分頁直接關掉時，他不在；瀏覽器把頁面塞進記憶體準備秒回時，他也不知道該不該出現。大家以為他每天都有寄報表，事實上很多天根本沒寄。
10 月 16 日，Chrome 的 Barry Pollard 與 Fergal Daly 在 Chrome for Developers 部落格宣布：這位同事正式退休了。從 Chrome 155 起，unload 事件預設不再觸發。
發生了什麼事？
unload 誕生在一個很單純的年代：網頁打開、看完、關掉。頁面關閉時，unload 讓程式有機會完成最後的工作，例如儲存使用者資料、清理資源、或發送分析數據。
但現在的頁面生命週期沒那麼好預測。很多頁面一開就是好幾天；更多頁面是在完全沒機會執行 unload 的情況下被關掉，尤其在手機上，作業系統為了節省資源，常常默默關掉背景頁面。
再加上 bfcache（往返快取）。bfcache 會把整個頁面暫存在記憶體裡，使用者按「上一頁」時直接瞬間還原，不用重新載入。可是 unload 的前提是「頁面要結束了、不會再回來」，兩者放在一起很容易出問題。各家瀏覽器的處理方式也不一樣：有的優先 bfcache、有的優先 unload，而且在沒用到 bfcache 時，大家又都會觸發 unload。結果就是：看起來有時候能用，但非常不一致。
Chrome 團隊的結論是：與其維持這種混亂，不如一次做個了斷。
淘汰是怎麼完成的？
因為這是會影響既有網站的破壞性變更，Chrome 採取了相當謹慎的分階段推出：從 2025 年 3 月到 2026 年 9 月，一邊推出一邊監測網站是否壞掉、聽取開發者回饋。現在這項工作已經完成，unload 在 Chrome 上一致地不再觸發。
幾個重要的例外與後續：
- iOS 上的 Chrome 仍可能觸發
unload，因為它使用的是 Safari 的 WebKit 引擎，而不是完整的 Chrome。 - 網站可以選擇退出：透過 Permissions Policy API 或 Chrome Enterprise 設定，少數網站仍會收到
unload事件，但一樣不可靠。Chrome 表示沒有計畫移除這些退出機制，但鼓勵網站主改掉。 - 其他 Chromium 瀏覽器也會跟進：這項淘汰很快會在 Chromium 原始碼中預設開啟，除非其他 Chromium 瀏覽器自己改掉預設值。
數字會說話
Chrome 公布的影響數據：
- 使用
unload的導覽比例，從 18% 降到不到 4%。 unload作為 bfcache 唯一阻擋原因的導覽，從 6% 降到約 1%，也就是說，額外約 5% 的導覽現在能享受瞬間前進／返回。unload作為多個阻擋原因之一的比例，從 22% 降到約 3%，代表如果把其他阻擋原因也解決，還有更多空間。
為什麼這很重要？web.dev 的 bfcache 文章引用 Chrome 使用數據：桌機上每 10 次導覽就有 1 次、手機上每 5 次就有 1 次是「上一頁」或「下一頁」。這些導覽如果能從記憶體瞬間還原，對使用者來說就是「快到感覺不到載入」。
對你的網站代表什麼？
第一，靠 unload 做的事，可能早就沒在做了。 如果你的網站、外掛或第三方腳本還在 unload 裡送追蹤事件、儲存表單草稿、或通知後端「使用者離開了」，那這些動作在 Chrome 上已經不會發生。請盤點一下：結帳流程的放棄追蹤、文章閱讀時間統計、即時客服的離線通知，這些都是常見的 unload 用途。
第二，你的分析數據可能會「變少」，但其實是體驗變好。 web.dev 提到，很多分析工具不會把 bfcache 還原算成新的瀏覽量。當更多導覽改用 bfcache，報表上的瀏覽量可能下降，但使用者實際體驗是變快的。
第三，效能指標可能看起來「變慢」，同樣是錯覺。 被 bfcache 取代的通常是最快的那批重複載入，資料集裡少了這些快速樣本，整體分布會往慢的方向偏。對 TTFB 這類指標，建議依導覽類型分開看；Core Web Vitals 的工具（例如 Chrome 使用者體驗報告）則會把 bfcache 還原當成獨立造訪計算。
實戰改寫指南
- 用
pagehide取代unload。 web.dev 說得很直接：「永遠不要用unload事件。」pagehide在所有unload會觸發的情況下都會觸發，頁面進入 bfcache 時也會觸發。
window.addEventListener('pagehide', (event) => {
// 在這裡收尾，例如關閉連線、儲存狀態
});
- 用
pageshow偵測 bfcache 還原。event.persisted為true時代表頁面是從 bfcache 回來的，可以在這時更新購物車數量、重新檢查登入狀態，或補送一次瀏覽量。
window.addEventListener('pageshow', (event) => {
if (event.persisted) {
// 從 bfcache 還原：更新過期資料、補送 page_view
}
});
-
beforeunload只在需要時加。 例如表單有未儲存的變更時才加上提醒，存檔後立刻移除。 -
少用
Cache-Control: no-store。 頁面本身設了no-store，瀏覽器通常不會把它放進 bfcache。只有真的含敏感資料的頁面才用；一般需要最新內容的頁面，可以改用no-cache或max-age=0。 -
離開前關掉連線。 開著的 IndexedDB 連線、進行中的 fetch 等，可能讓某些瀏覽器不把頁面放進 bfcache。在
pagehide關閉，在pageshow重新連上。 -
用 DevTools 測試。 在 Chrome DevTools 的 Application → Back-forward Cache 面板按 Run Test，它會告訴你頁面能不能被還原，以及原因是否「可以處理」。Lighthouse 也有對應的稽核。
-
想完全杜絕，可以加上標頭。
Permissions-Policy: unload=()能防止第三方腳本或擴充功能偷偷加上unload（目前僅 Chromium 系瀏覽器支援）。
情境演練：一家電商的「上一頁」
假設一家服飾電商，使用者常見的動線是：分類頁 → 點進商品 → 看完按「上一頁」回分類頁 → 再點下一件。這種來回跳動，正是 bfcache 最能發揮的地方。
如果分類頁因為某個舊追蹤腳本掛了 unload，或整頁設了 no-store，每次按「上一頁」都要重新載入、重新捲到剛才的位置，使用者很容易失去耐心。改成 pagehide 收尾、移除不必要的 no-store 之後，同一個動作就能瞬間回到原本的列表與捲動位置。
要注意的是，從 bfcache 回來的頁面是記憶體裡的舊快照。購物車數量、庫存提示、登入狀態這類資訊，記得在 pageshow 且 persisted 為 true 時重新整理，避免顯示過期資料。
怎麼量測成果？
改完之後，可以在分析工具裡把 bfcache 還原獨立標記成一種導覽類型，再和一般的「上一頁」導覽次數比較，算出 bfcache 命中率。Chrome 也提供 NotRestoredReasons API，告訴你頁面為什麼沒被還原；Chrome 使用者體驗報告（CrUX）也加入了導覽類型，不用自己埋點也能看到 bfcache 導覽的數量。
你可能會問
Q：我們的網站沒有自己寫 unload，需要處理嗎？
A：不一定是你寫的。第三方腳本、舊版外掛也可能加上 unload。用 DevTools 或 Lighthouse 跑一次最準。
Q：iPhone 使用者呢？
A：iOS 上的 Chrome 使用 WebKit，unload 仍可能觸發，但也同樣不可靠。改用 pagehide 才是跨瀏覽器的穩妥做法。
Q：這跟 SEO 有關係嗎？ A：bfcache 主要改善的是使用者的往返導覽體驗，而 Core Web Vitals 工具會把 bfcache 還原當成獨立造訪計算。網站越快、越順，對使用者與搜尋表現都是加分，但不要期待「改掉 unload 就排名大躍進」。
Q：bfcache 命中率能做到 100% 嗎？ A：不行。使用者重開瀏覽器、複製分頁，或頁面在記憶體裡待太久被丟棄，都不會用到 bfcache。重點是找出「頁面自己擋住 bfcache」的情況。
結語：讓翹班的同事好好退休
unload 的退休，是網頁平台少見的「真的把 API 拿掉」。Chrome 團隊自己也說，他們不常這麼做，但這次值得。
對網站經營者來說，這是一個難得的雙贏機會：把收尾工作交給更可靠的 pagehide，順便讓更多使用者按「上一頁」時瞬間回到原處。花一個下午盤點程式碼，換來的是更快、更穩、數據也更可信的網站。
來源：Unload event deprecated in Chrome（Barry Pollard、Fergal Daly，Chrome for Developers，2026/10/16）。
延伸參考：Back/forward cache（Philip Walton、Barry Pollard，web.dev，2026/10/16 更新）。