アンロード イベントの非推奨

Demián Renzulli

Barry Pollard

公開日: 2023 年 8 月 10 日、最終更新日: 2026 年 6 月 29 日

unload イベントは、デフォルトを段階的に変更することで段階的に非推奨になります。これにより、ページで明示的にオプトインして再度有効にしない限り、unload ハンドラはページで発生しなくなります。

サポート終了のタイムライン

バックフォワード キャッシュの実装の意向を発表した 2019 年 1 月の時点で、アンロードの動作は早ければ 2019 年 1 月にも変更される可能性があることをお知らせしました。実装作業と並行して大規模なアウトリーチを実施した結果、アンロードの使用率が大幅に低下しました。このアウトリーチを補完するために、Chrome 115 からアンロードを非推奨にする影響をテストする方法も提供し始めました。

• Chrome 115（2023 年 7 月）で unload の Permission-Policy API を使用した実環境でのテスト
• Chrome 117（2023 年 9 月）でフラグを有効にしてローカルテストを実施

2024 年を通して、ロールアウトの開始を妨げるいくつかの問題に対処し、2025 年を通して、上位 50 サイトに非推奨化をロールアウトしました。

2026 年に、次の表に示すように、8 つのマイルストーン（約 32 週間）にわたって、すべてのオリジンへのロールアウトを開始しました。

完全なロールアウトは、個々のユーザーやサイトではなく、ページ読み込み（時間の経過に伴う一貫性）に基づいて行われます。これは、非推奨の意図で詳しく説明されているように、他のユーザーやサイトよりも影響を受けるユーザーやサイトを避けるためです。

なお、この非推奨のスケジュールでは unload から移行するのに十分な時間がない場合は、オプトアウト オプションのメニューも用意しています。

背景

unload は、ドキュメントがアンロードされるときに発火するように設計されています。理論的には、ユーザーがページから移動するたびにコードを実行したり、セッション終了時のコールバックとして使用したりできます。

このイベントが最もよく使用されたシナリオは次のとおりです。

• ユーザーデータの保存: ページを離れる前にデータを保存します。
• クリーンアップ タスクの実行: ページを離れる前に開いているリソースを閉じます。
• アナリティクスの送信: セッションの終了時にユーザー インタラクションに関連するデータを送信します。

ただし、unload イベントは信頼性が非常に低いです。

デスクトップ版の Chrome と Firefox では、unload はある程度信頼できますが、bfcache（バックフォワード キャッシュ）の使用を妨げるため、サイトのパフォーマンスに悪影響を及ぼします。

モバイル ブラウザでは、タブがバックグラウンドに移動して終了することが多いため、unload が実行されないことがよくあります。そのため、ブラウザはモバイルで unload よりも bfcache を優先することを選択し、信頼性がさらに低下しています。Safari はパソコンでもこの動作を使用します。

Chrome チームは、デスクトップで unload よりも bfcache を優先するモバイルモデルを使用すると、以前は Chrome（および Firefox）で比較的信頼性が高かったデスクトップでも信頼性が低下し、混乱が生じると考えています。Chrome の目的は、unload イベントを完全に削除することです。それまでは、非推奨を明示的にオプトアウトしたユーザーに対して、Chrome のデスクトップ版で引き続き信頼性の高いサービスを提供します。

unload イベントを非推奨にする理由

unload の非推奨化は、私たちが今生きているウェブをより大きく認識するための重要なステップです。unload イベントは、アプリのライフサイクルを制御できるという誤った認識を与えますが、これは現代のコンピューティングの世界でウェブを閲覧する方法とはますますかけ離れたものになっています。

モバイル オペレーティング システムでは、メモリを節約するためにウェブページが頻繁にフリーズしたりアンロードされたりします。パソコン用ブラウザでも、同じ理由でこのような処理が行われることが増えています。オペレーティング システムの介入がなくても、ユーザーは頻繁にタブを切り替え、正式に「ページを離れる」ことなく古いタブを閉じます。

unload イベントを廃止することは、ウェブ デベロッパーとして、パラダイムが現実世界と一致するようにし、もはや当てはまらない古いコンセプトに依存しないようにする必要があることを認識していることを意味します。

unload イベントの代替手段

unload の代わりに、次の使用をおすすめします。

• visibilitychange: ページの可視性が変化するタイミングを判断します。このイベントは、ユーザーがタブを切り替えたり、ブラウザ ウィンドウを最小化したり、新しいページを開いたりしたときに発生します。アプリとユーザーデータを保存する最後の信頼できるタイミングとして、hidden 状態を検討してください。
• pagehide: ユーザーがページから移動したタイミングを判断します。このイベントは、ユーザーがページから移動したとき、ページを再読み込みしたとき、またはブラウザ ウィンドウを閉じたときに発生します。ページが最小化されたり、別のタブに切り替えられたりした場合は、pagehide イベントは発生しません。pagehide はページをバックフォワード キャッシュの対象外にしないため、このイベントの発生後にページが復元される可能性があります。このイベントでリソースをクリーンアップする場合は、ページ復元時にリソースを復元する必要がある場合があります。

beforeunload イベントは、キャンセル可能なイベントであるという点で、unload とは若干異なるユースケースがあります。多くの場合、移動時に保存されていない変更があることをユーザーに警告するために使用されます。バックグラウンド タブが強制終了された場合、このイベントは発生しないため、信頼性も低くなります。beforeunload の使用を制限し、条件付きでのみ追加することをおすすめします。代わりに、前述のイベントをほとんどの unload の代替に使用してください。

詳しくは、unload ハンドラを絶対に使用しないことに関するアドバイスをご覧ください。

unload の使用状況を検出する

ページ上の unload イベントの出現箇所を特定するのに役立つさまざまなツールがあります。これにより、サイトは、独自のコードまたはライブラリでこのイベントを使用しているかどうかを検出できるため、今後の非推奨化の影響を受ける可能性があります。

Chrome DevTools

Chrome DevTools には、unload ハンドラの使用など、ページがバックフォワード キャッシュに保存されない原因となる問題を特定するのに役立つ back-forward-cache 監査が含まれています。

バックフォワード キャッシュをテストする手順は次のとおりです。

1. ページで DevTools を開き、[Application] > [Background services] > [バックフォワード キャッシュ] に移動します。

2. [バックフォワード キャッシュをテスト] をクリックします。Chrome によって自動的に chrome://terms/ に移動し、ページに戻ります。または、ブラウザの [戻る] ボタンと [進む] ボタンをクリックします。

ページがバックフォワード キャッシュの対象でない場合、[バックフォワード キャッシュ] タブに問題のリストが表示されます。[実用的] で、unload を使用しているかどうかを確認できます。

Reporting API

Reporting API は、読み取り専用の Permission Policy と組み合わせて使用することで、ウェブサイト ユーザーによる 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 ハンドラを有効または無効にして、ハンドラなしでサイトがどのように動作するかをテストし、今後のサポート終了に備えることができます。ポリシーにはさまざまな種類があります。

• Permissions Policy: サイト所有者が HTTP ヘッダーを使用して、サイトまたは個々のページレベルで機能へのアクセスを制御するためのプラットフォーム API です。
• Enterprise ポリシー: IT 管理者が組織や企業の Chrome を設定するためのツール。これらは、Google 管理コンソールなどの管理者パネルを使用して構成できます。
• Chrome フラグ: 個々のデベロッパーが unload の非推奨設定を変更して、さまざまなサイトへの影響をテストできます。

権限に関するポリシー

Chrome 115 から追加された権限ポリシーにより、サイトは unload ハンドラの使用をオプトアウトして、bfcache のメリットをすぐに享受し、サイト パフォーマンスを改善できます。サイトでこの設定を行う方法の例をご覧ください。これにより、サイトは unload の非推奨化に先手を打つことができます。

この機能は Chrome 117 で拡張され、サイトが逆の処理を行えるようになりました。また、Chrome でこれらのデフォルトが将来的に発火しないように変更されるため、サイトは現在と同様に unload ハンドラの起動を試み続けることを選択できるようになりました。サイトでアンロード ハンドラを引き続き実行できるようにする方法の例をご覧ください。unload ハンドラの信頼性の低さを考慮すると、サイト所有者には unload ハンドラの使用を避けることをおすすめしますが、使用する必要があるサイトについては、当面の間このオプトアウトをサポートする予定です。再度有効にしても、モバイルでの unload ハンドラの信頼性が向上するわけではありません。現在の状況が復元されるだけです。

エンタープライズ ポリシー

unload イベントに依存するソフトウェアを正しく機能させる必要がある企業は、ForcePermissionPolicyUnloadDefaultEnabled ポリシーを使用して、管理下のデバイスでの段階的な非推奨化を防止できます。このポリシーを有効にすると、すべてのオリジンで unload が引き続きデフォルトで有効になります。ページは必要に応じて、より厳格なポリシーを設定できます。Permissions Policy のオプトアウトと同様に、これは潜在的な破壊的変更を軽減するためのツールです。サイト所有者には unload ハンドラへの依存を止めることをおすすめしますが、Chrome では、このハンドラを使用する必要があるサイト向けに、このエンタープライズ オプトアウトを当面の間サポートする予定です。

Chrome のフラグとコマンドライン スイッチ

企業ポリシーに加えて、Chrome フラグとコマンドライン スイッチを使用して、個々のユーザーの非推奨を無効にすることもできます。

chrome://flags/#deprecate-unload を enabled に設定すると、非推奨のデフォルトが適用され、unload ハンドラが起動しなくなります。Permissions Policy を使用してサイトごとにオーバーライドすることはできますが、デフォルトでは引き続き発火します。

これらの設定は、コマンドライン スイッチで制御することもできます。

オプションの比較

次の表に、前述のオプションのさまざまな用途をまとめます。

まとめ

unload ハンドラは非推奨になりました。長い間信頼性が低く、ドキュメントが破棄されるすべてのケースで発火するとは限りません。また、unload ハンドラは bfcache と互換性がありません。

unload ハンドラを使用しているサイトは、既存の unload ハンドラをテストして、削除または移行するか、最後の手段として、さらに時間が必要な場合はサポート終了を延期することで、このサポート終了に備える必要があります。

謝辞

有益なレビュー フィードバックを寄せてくれた Kenji Baheux、Fergal Daly、Adriana Jara、Jeremy Wagner に感謝します。

ヒーロー画像: Anja Bauermann（Unsplash）