淘汰卸載事件

Demián Renzulli

Barry Pollard

發布日期：2023 年 8 月 10 日，上次更新日期：2025 年 6 月 23 日

unload 事件將逐步淘汰，逐步變更預設值，讓 unload 處理常式停止在網頁上觸發，除非網頁明確選擇重新啟用。

淘汰時程

我們曾在 2019 年 1 月宣布意圖實作返回/前進快取，並指出卸載行為可能會隨之變更。除了實施相關措施，我們也進行了廣泛的宣導活動，導致卸載用量大幅下降。為了補足這項說明，我們也開始提供測試方法，讓開發人員測試淘汰 Chrome 115 後的卸載效果：

• 在實際環境中測試 Chrome 115 版，使用Permission-Policy API 卸載 (2023 年 7 月)
• 在 Chrome 117 中啟用旗標進行本機測試 (2023 年 9 月)

我們在 2024 年解決了幾個阻礙這項功能推出的相關問題。

以下是 unload 事件目前的淘汰時間表：

完成前 50 個網站的推播後，我們會暫停，讓這項功能在整個里程碑或兩個里程碑期間進行測試，然後取得進一步核准，在接下來的 8 個里程碑 (或約 32 週) 內，將這項功能推播至所有來源，這可能會暫時以以下方式進行：

請注意，如果這個淘汰時間表無法提供足夠的時間讓您從卸載遷移，我們也提供停用選項選單。我們的目標是利用這項軟淘汰功能，讓您瞭解最後階段 (卸載功能的硬淘汰) 的時間表，屆時我們將移除或減少這些選擇退出項目。

背景

unload 的設計目的是在文件卸載時觸發。理論上，您可以在使用者離開網頁時執行程式碼，或將其用於工作階段結束的回呼。

這個事件最常見的使用情境包括：

• 儲存使用者資料：離開網頁前儲存資料。
• 執行清理工作：在放棄網頁前關閉已開啟的資源。
• 傳送數據分析：在工作階段結束時傳送與使用者互動相關的資料。

不過，unload 事件非常不可靠。

在 Chrome 和 Firefox 桌面版上，unload 的穩定性相當高，但會禁止使用 bfcache (往返快取)，對網站效能造成負面影響。

在行動瀏覽器上，由於分頁經常會進入背景並遭到終止，因此 unload 通常不會執行。因此，瀏覽器會將 bfcache 優先於 unload，讓 unload 變得更加不可靠。Safari 在電腦上也會採用這項行為。

Chrome 團隊認為，在電腦上使用行動版模式 (優先使用 bfcache 而非 unload) 會造成干擾，因為這會讓 bfcache 的穩定性降低，而這項功能在 Chrome (和 Firefox) 中原本的穩定性相當不錯。相反地，Chrome 的目標是完全移除 unload 事件。在此之前，如果使用者明確選擇不採用淘汰計畫，則在電腦上仍可正常使用這項功能。

為什麼要淘汰 unload 事件？

淘汰 unload 是我們在現今網路環境中，更廣泛實現這項功能的重要一步。unload 事件會讓您誤以為可以控制應用程式生命週期，但這與我們在現代電腦世界中瀏覽網頁的方式越來越不相符。

行動作業系統經常會凍結或卸載網頁，以節省記憶體空間，而電腦版瀏覽器也因同樣原因，越來越常這樣做。即使沒有作業系統介入，使用者也會經常切換分頁並關閉舊分頁，而不會正式「離開」網頁。

移除已淘汰的 unload 事件，是因為我們必須確保網頁開發人員的模式與現實世界一致，而非依賴已淘汰的概念 (如果有)。

unload 事件的替代方案

建議您改用以下方法，而非 unload：

• visibilitychange：用於判斷網頁的瀏覽權限何時變更。當使用者切換分頁、將瀏覽器視窗最小化，或開啟新分頁時，就會發生這項事件。請將 hidden 狀態視為可靠的最後儲存應用程式和使用者資料的時間。
• pagehide：用於判斷使用者何時離開網頁。使用者離開網頁、重新載入網頁或關閉瀏覽器視窗時，就會觸發這項事件。當網頁最小化或切換至其他分頁時，系統不會觸發 pagehide 事件。請注意，由於 pagehide 不會使網頁無法使用往返快取，因此網頁可能會在這個事件觸發後還原。如果您在這個事件中清理任何資源，則可能必須在還原網頁時還原這些資源。

beforeunload 事件的用途與 unload 略有不同，因為它是可取消的事件。這項功能通常會在使用者離開頁面時，提醒他們未儲存的變更。這個事件也不可靠，因為如果背景分頁遭到終止，事件就不會觸發。建議您限制 beforeunload 的使用方式，並僅在特定條件下新增。請改為針對多數 unload 替換作業使用先前提到的事件。

詳情請參閱這篇文章，瞭解為何不應使用 unload 處理常式。

偵測 unload 的使用情形

您可以使用各種工具，找出網頁上出現的 unload 事件。這可讓網站瞭解自己是否使用這個事件 (無論是在自己的程式碼中使用，還是透過程式庫使用)，並可能受到即將淘汰的事件影響。

Chrome 開發人員工具

Chrome 開發人員工具包含 back-forward-cache 稽核，可協助您找出可能導致網頁無法使用往返快取的問題，包括 unload 處理常式。

如要測試返回/前進快取，請按照下列步驟操作：

1. 在頁面上開啟 DevTools，然後依序前往「Application」 >「Background services」 >「Back/forward cache」。

2. 按一下「測試往返快取」，Chrome 會自動前往 chrome://terms/，然後返回網頁。或者，您也可以按一下瀏覽器的「前進」和「返回」按鈕。

如果網頁不符合往返快取的使用資格，系統會在「往返快取」分頁中列出問題清單。在「可採取行動」下方，您可以查看是否使用 unload：

Reporting API

Reporting API 可與唯讀權限政策搭配使用，用於偵測網站使用者是否使用 unload。

詳情請參閱「使用 Reporting API 找出卸載作業」

Bfcache notRestoredReasons API

notRestoredReasons 屬性已新增至 PerformanceNavigationTiming 類別，可回報文件是否在導覽時遭到 bfcache 封鎖，以及封鎖原因。以下是現有 unload 事件監聽器的回應物件警告範例：

{
   children: [],
   id: null,
   name: null,
   reasons: [
     {"reason", "unload-listener"}
   ],
   src: null,
   url: "https://www.example.com/page/"
}

控管 unload 的存取權

Chrome 會逐步淘汰 unload 事件。在此期間，您可以使用其他工具控制這項行為，並為即將淘汰的行為做好準備。請注意，您不應長期依賴這些技術，應盡快改用其他方法。

您可以使用下列選項啟用或停用 unload 處理常式，以便測試網站在沒有這些常式時的運作情形，為即將淘汰的功能做好準備。政策分為以下幾種類型：

• 權限政策：這是一個平台 API，可讓網站管理員使用 HTTP 標頭，在網站或個別網頁層級控制功能存取權。
• 企業政策：IT 管理員可使用這項工具為機構或企業設定 Chrome。您可以使用管理員面板 (例如 Google 管理控制台) 進行設定。
• Chrome 旗標：開發人員可以使用此功能變更 unload 淘汰設定，測試對不同網站的影響。

權限政策

Chrome 115 已新增權限政策，允許網站選擇不使用 unload 處理常式，並立即享有 bfcache 帶來的效益，以提升網站效能。請參閱這些範例，瞭解如何為網站設定這項功能。這樣一來，網站就能提前因應 unload 淘汰。

這項功能將在 Chrome 117 版中擴充，允許網站反向操作，並選擇繼續嘗試觸發 unload 處理常式，因為 Chrome 會將這些項目的預設值變更為日後不觸發。請參閱這些範例，瞭解如何繼續允許網站觸發卸載處理常式。這項選擇加入功能不會永久存在，應用於讓網站有時間從 unload 處理常式遷移。

企業政策

如果企業的軟體需要 unload 事件才能正常運作，可以使用 ForcePermissionPolicyUnloadDefaultEnabled 政策，避免受控裝置逐步淘汰。啟用這項政策後，unload 會繼續預設為為所有來源啟用。但網頁仍可視需要設定更嚴格的政策。與權限政策選擇不採用功能一樣，這項工具可用於減輕可能造成重大變更的風險，但不應無限期使用。

Chrome 標記和指令列切換

除了企業政策之外，您也可以使用 Chrome 標記和指令列切換鈕，為個別使用者停用淘汰功能：

將 chrome://flags/#deprecate-unload 設為 enabled 會提前淘汰預設值，並防止 unload 處理常式觸發。不過，您還是可以使用權限政策，針對個別網站覆寫這些廣告，但預設情況下，系統仍會繼續觸發廣告。

您也可以使用指令列切換鈕控制這些設定。

選項比較

下表總結先前討論的選項不同用途：

結論

unload 處理常式即將淘汰。這些事件已長久以來不穩定，且無法保證在所有文件遭到銷毀的情況下都會觸發。此外，unload 處理程序與 bfcache 不相容。

使用 unload 處理常式的網站應為即將淘汰的處理常式做好準備，方法是測試現有的 unload 處理常式、移除或遷移這些處理常式，或者在需要更多時間時，將淘汰作業延後。

特別銘謝

感謝 Kenji Baheux、Fergal Daly、Adriana Jara 和 Jeremy Wagner 協助審查本文。

主頁橫幅圖片由 Anja Bauermann 提供，取自 Unsplash