unload イベントは、ページで明示的に再度有効にしない限り、unload ハンドラによるページでの unload ハンドラの呼び出しが停止するように、デフォルト値を段階的に変更することで、段階的にサポートが終了します。
サポート終了のタイムライン
Google は、バックフォワード キャッシュの導入計画を発表した 2019 年 1 月には、アンロード動作が変更される可能性があります。実装作業と並行して大規模なアウトリーチを行った結果、アンロードの使用量が大幅に減少しました。この取り組みを補完するため、Chrome 115 からのアンロードのサポート終了による影響をテストする方法の提供も開始しました。
- Chrome 115（2023 年 7 月）での Permission-Policy API for unload によるワイルドテスト
- フラグの有効化によるローカルテスト（2023 年 9 月）
アウトリーチとトライアルの段階を経て、ソフトサポート終了の展開の流れは次のとおりです。
- 上位 50 の人気サイトのアンロードが徐々に機能しなくなる、対象範囲を絞ったフェーズです（本稿執筆時点で参照）。
- Chrome 120（2023 年 11 月末）から、ユーザーの 1% から開始できます。
- 2024 年第 3 四半期末までに 100% のユーザーで終了
- さらに、2024 年第 3 四半期から、どのサイトでもアンロード機能が徐々に停止する一般的なフェーズを開始する予定です。2025 年第 1 四半期末までに、ユーザーの 1% で開始し、100% のユーザーで終了します。
なお、このソフトサポート終了のタイムラインでアンロードから移行するのに十分な時間がない場合は、オプトアウトのオプション メニューも用意されています。Google では、このソフト非推奨を使用して、これらのオプトアウトが削除または削減される最終フェーズ（アンロードの強制非推奨）のタイムラインを知らせることを目標としています。
背景
unload は、ドキュメントがアンロードされるときに起動するように設計されています。理論的には、ユーザーがページから離れるたびに、またはセッション終了コールバックとして、コードを実行するために使用できます。
このイベントが最もよく使用されているシナリオは次のとおりです。
- ユーザーデータを保存する: ページを離れる前にデータを保存します。
- クリーンアップ タスクの実行: ページを放棄する前に、開いているリソースを閉じます。
- 分析データの送信: セッションの終了時に、ユーザー インタラクションに関連するデータを送信します。
ただし、unload イベントは非常に信頼性が低くなります。
パソコンの Chrome と Firefox では、unload はある程度信頼性がありますが、bfcache（バックフォワード キャッシュ）の使用を防ぐことでサイトのパフォーマンスに悪影響を及ぼします。
モバイル ブラウザでは、タブが頻繁にバックグラウンドになってから強制終了されるため、unload が実行されないことが多くあります。このため、ブラウザではモバイルの bfcache が unload よりも優先され、信頼性がいっそう低下しています。デスクトップの Safari でもこの動作が使用されます。
Chrome チームは、モバイルモデルを使用して unload よりも bfcache を優先すると、以前 Chrome（および Firefox）では妥当な信頼性であったため、bfcache の信頼性が低下するため、混乱を招くと考えています。Chrome の目的は unload イベントを完全に削除することです。サポートの終了を明示的にオプトアウトしたユーザーについては、当面はパソコンでの信頼性を維持します。
unload イベントのサポートを終了する理由
unload のサポート終了は、私たちが暮らしているウェブをより大きく認識するための重要なステップです。unload イベントが発生すると、アプリのライフサイクルが管理されているという誤解を与えることになります。これは現代のコンピューティングの世界におけるウェブ ブラウジングのあり方とは、ますます現実的ではありません。
メモリを節約するために、モバイル オペレーティング システムはウェブページを頻繁にフリーズ / アンロードします。デスクトップ ブラウザも同じ理由で、このような動作がますます増えています。オペレーティング システムの介入がなくても、ユーザーは正式に「ページを離れる」ことなく、頻繁にタブを切り替えて古いタブを強制終了します。
unload イベントを不明瞭なイベントとして削除することは、ウェブ デベロッパーとして、Google のパラダイムが現実世界のパラダイムと一致するようにし、もはや当てはまらない古いコンセプトに依存しないようにする必要があることを認識しています。
unload イベントに代わる方法
unload の代わりに、次を使用することをおすすめします。
visibilitychange: ページの公開設定を変更するタイミングを判断するため。このイベントは、ユーザーがタブを切り替えたとき、ブラウザ ウィンドウを最小化したとき、または新しいページを開いたときに発生します。hidden状態は、アプリとユーザーデータを保存するための信頼できる最終日時です。pagehide: ユーザーがページから移動したタイミングを判断します。このイベントは、ユーザーがページから離れたとき、ページを再読み込みしたとき、またはブラウザ ウィンドウを閉じたときに発生します。単にページを最小化した場合や別のタブに切り替えた場合は、pagehideイベントは発生しません。pagehideによってページがバックフォワード キャッシュの対象にならないため、このイベントが発生した後にページを復元できる可能性があります。このイベントでリソースをクリーンアップする場合は、ページの復元時にリソースの復元が必要になることがあります。
beforeunload イベントは、キャンセル可能なイベントであるという点で unload とはユースケースが若干異なります。多くの場合、ページから移動するときに保存されていない変更をユーザーに警告するために使用されます。また、このイベントは、バックグラウンドのタブが強制終了されると発生しないため、実現できません。beforeunload の使用を制限し、条件付きでのみ追加することをおすすめします。ほとんどの unload の置換には、上記のイベントを使用します。
詳しくは、unload ハンドラを使用しないことに関するこちらのアドバイスをご覧ください。
unload の使用を検出する
ページ上の unload イベントの外観は、さまざまなツールで確認できます。これにより、サイトはこのイベントを使用しているかどうかを（独自のコードまたはライブラリ経由で）確認できます。また、今後のサポート終了による影響を受ける可能性があります。
灯台
Lighthouse では、no-unload-listeners 監査により、ページ内の JavaScript（サードパーティ ライブラリのものを含む）に unload イベント リスナーが追加された場合に警告が表示されます。
Chrome DevTools
Chrome DevTools では、back-foward-cache 監査を使用して、ページのバックフォワード キャッシュの対象を妨げている可能性のある問題（unload ハンドラの使用など）を特定できます。
バックフォワード キャッシュをテストする手順は次のとおりです。
ページで DevTools を開き、[アプリケーション] > [バックグラウンド サービス] > [バックフォワード キャッシュ] に移動します。
[バックフォワード キャッシュのテスト] をクリックすると、自動的に
chrome://terms/に移動し、元のページに戻ります。または、ブラウザの [戻る] ボタンと [進む] ボタンをクリックします。
ページがバックフォワード キャッシュの対象でない場合は、[バックフォワード キャッシュ] タブに問題のリストが表示されます。[Actionable] で、unload を使用しているかどうかを確認できます。
Reporting API
Reporting API を読み取り専用の権限ポリシーと組み合わせて使用すると、ウェブサイトのユーザーによる unload の使用を検出できます。
詳しくは、usUsing Reporting API を使用してアンロードを見つけるをご覧ください。
Bfcache notRestoredReasons API
PerformanceNavigationTiming クラスに追加された notRestoredReasons プロパティは、ナビゲーション時の bfcache の使用がドキュメントでブロックされたかどうかと、その理由に関する情報を報告します。使用方法については、こちらをご覧ください。次の例は、既存の unload リスナーのレスポンス オブジェクトに関する警告です。
{
blocked: true,
children: [],
id: "",
name: "",
reasons: [ "Internal Error", "Unload handler" ],
src: "",
url: "a.com"
}
unload へのアクセスを制御する
Chrome では、unload イベントを段階的に廃止する予定です。それまでの間、別のツールを使用してこの動作を制御し、今後のサポート終了に備えることができます。なお、これらの手法を長期的に使用すべきではありません。できるだけ早く代替手法に移行することを計画してください。
以下のオプションを使用すると、unload ハンドラを有効または無効にしてサイトの動作をテストし、今後のサポート終了に備えることができます。ポリシーにはさまざまな種類があります。
- 権限ポリシー: サイト所有者が HTTP ヘッダーを使用してサイトまたは個々のページレベルで機能へのアクセスを制御するためのプラットフォーム API です。
- エンタープライズ ポリシー: IT 管理者が組織やビジネス用に Chrome を設定するためのツール。Google 管理コンソールなどの管理パネルから設定できます。
- Chrome フラグ: 個々のデベロッパーが
unloadのサポート終了設定を変更して、さまざまなサイトへの影響をテストできます。
権限ポリシー
Chrome 115 から追加された権限ポリシーにより、サイトは unload ハンドラの使用をオプトアウトしてすぐに bfcache の恩恵を受け、サイトのパフォーマンスを向上させることができます。サイトに設定する方法の例をご覧ください。これにより、サイトは unload のサポート終了に先立って対応できます。
この機能は Chrome 117 で拡張され、サイトがこの逆を行うのを許可し、今後ハンドラが呼び出されないようにデフォルトを変更することで、unloadハンドラを今後も呼び出すことをオプトインできるようにします。サイトのアンロード ハンドラを引き続き起動できるようにする方法については、こちらの例をご覧ください。このオプトインは永久に維持されるわけではなく、サイトが unload ハンドラから移行する時間を確保するために使用する必要があります。
エンタープライズ ポリシー
正しく機能するために unload イベントに依存するソフトウェアを使用している企業は、ForcePermissionPolicyUnloadDefaultEnabled ポリシーを使用して、管理下にあるデバイスが段階的にサポート終了になるのを防ぐことができます。このポリシーを有効にすると、引き続き unload はすべてのオリジンで引き続きデフォルトで有効になります。必要に応じて、ページでより厳格なポリシーを設定できます。権限ポリシーのオプトアウトと同様に、これは互換性を破る変更の可能性を軽減するためのツールですが、無期限に使用するべきではありません。
Chrome フラグとコマンドライン スイッチ
エンタープライズ ポリシーに加えて、Chrome のフラグとコマンドライン スイッチを使用して、個々のユーザーのサポート終了を無効にできます。
chrome://flags/#deprecate-unload を enabled に設定すると、非推奨のデフォルトが転送され、unload ハンドラが呼び出されなくなります。権限ポリシーによりサイトごとにオーバーライドできますが、引き続きデフォルトで配信されます。
これらの設定は、コマンドライン スイッチで制御することもできます。
オプションの比較
次の表は、前述のオプションのさまざまな用途をまとめたものです。
| サポート終了を前倒しする | サポート終了を前倒しする（例外あり） | サポート終了を回避して移行時間を確保する | |
|---|---|---|---|
| 権限ポリシー （ページやサイトに適用） |
○ | ○ | ○ |
| エンタープライズ ポリシー （デバイスに適用） |
× | × | ○ |
| Chrome のフラグ （個々のユーザーに適用） |
○ | × | × |
| Chrome コマンドライン スイッチ （個々のユーザーに適用） |
○ | × | ○ |
おわりに
unload ハンドラは非推奨になります。長期間にわたって信頼性が低く、ドキュメントが破棄された場合に必ず実行される保証はありません。また、unload ハンドラは bfcache と互換性がありません。
現在 unload ハンドラを使用しているサイトでは、このサポート終了に備えて、既存の unload ハンドラをテストまたは削除または移行するか、さらに時間が必要な場合は最後の手段としてサポート終了を延期する必要があります。
謝辞
この記事のレビューに協力してくれた Kenji Baheux、Fergal Daly、Adriana Jara、Jeremy Wagner に感謝します。
ヒーロー画像（作成者: Anja Bauermann、出典: Unsplash）