unload 事件將逐步淘汰，逐步變更預設值，讓 unload 處理常式停止在網頁上觸發，除非網頁明確選擇重新啟用。
淘汰時間表
我們曾在 2019 年 1 月宣布意圖實作返回/前進快取，當時就指出卸載行為可能會有所變更。除了實施相關措施，我們也進行了廣泛的宣導活動，導致卸載用量大幅下降。為了補足這項說明，我們也開始提供測試方法，讓開發人員測試淘汰 Chrome 115 後的卸載效果：
- 在 Chrome 115 中，透過 Permission-Policy API for unload 進行外部測試 (2023 年 7 月)
- 在 Chrome 117 中啟用旗標進行本機測試 (2023 年 9 月)
在完成這些接觸和試用階段後，我們預計會推出軟性淘汰功能：
- 在這種範圍階段，前 50 大熱門網站將逐漸停止卸載 (在本文撰寫時即已參考資料)。
- 自 2023 年 11 月底起，就從 Chrome 120 開始，佔 1% 的使用者。
- 在 2024 年第 3 季結束前為所有使用者終止服務
- 此外，我們預計從 2024 年第 3 季開始，在任何網站上逐步停用 unload 功能，並從 1% 的使用者開始，在 2025 年第 1 季結束前擴大到 100% 的使用者。
請注意，如果這項軟性淘汰的時間表無法提供足夠的時間，讓您從卸載作業中移除，我們也提供停用選項選單。我們的目標是利用這項軟淘汰功能，讓您瞭解最後階段 (卸載功能的硬淘汰) 的時間表，屆時我們將移除或減少這些選擇退出項目。
背景
unload 的設計目的是在解除載入文件時觸發。理論上，您可以在使用者離開網頁時執行程式碼，或將其做為工作階段結束的回呼。
最常見的情況包括：
- 儲存使用者資料：先儲存資料再離開網頁。
- 執行清理工作：在放棄網頁前關閉已開啟的資源。
- 傳送數據分析：在工作階段結束時傳送與使用者互動相關的資料。
不過，unload 事件非常不可靠。
在 Chrome 和 Firefox 桌面版上，unload 的運作相當可靠，但會禁止使用 bfcache (往返快取)，對網站效能造成負面影響。
在行動瀏覽器上，由於分頁經常會進入背景並遭到終止，unload 通常不會執行。因此，瀏覽器會將 bfcache 優先於 unload，讓 unload 變得更加不可靠。Safari 在電腦上也會採用這項行為。
Chrome 團隊相信，在電腦上採用優先處理 bfcache 的行動模型unload，會幹擾使用，因為過去 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 處理常式。
如要測試往返快取，請按照下列步驟操作：
在頁面上開啟「DevTools」，然後依序前往「Application」>「Background services」>「Back/forward cache」。
按一下「測試往返快取」，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-handler"}
],
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 處理常式觸發。不過，您還是可以透過權限政策針對個別網站覆寫這些事件，但這些事件預設會繼續觸發。
您也可以使用指令列切換鈕來控管這些設定。
選項比較
下表摘要說明上述選項的不同用途：
| 提前淘汰 | 提前淘汰 (含例外狀況) | 避免淘汰，確保遷移作業有充裕的時間 | |
|---|---|---|---|
| 權限政策 (適用於網頁/網站) |
是 | 是 | 是 |
| 企業政策 (適用於裝置) |
否 | 否 | 是 |
| Chrome 旗標 (適用於個別使用者) |
是 | 否 | 否 |
| Chrome 指令列切換器 (適用於個別使用者) |
是 | 否 | 是 |
結論
unload 處理常式即將淘汰。這些事件已長久以來不穩定，且無法保證在所有文件遭到銷毀的情況下都會觸發。此外，unload 處理程序與 bfcache 不相容。
網站如果目前使用 unload 處理常式，就必須針對即將淘汰的 SDK 做好準備，包括測試所有現有的 unload 處理常式、移除或遷移處理常式，或者，如果最後一種方法需要更多時間，請延後淘汰。
特別銘謝
感謝 Kenji Baheux、Fergal Daly、Adriana Jara 和 Jeremy Wagner 協助審查這篇文章。
主頁橫幅圖片由 Anja Bauermann 提供，取自 Unsplash