unload イベントは、デフォルトを段階的に変更することで段階的にサポートが終了されます。これにより、ページで明示的に有効にしない限り、unload ハンドラはページで発生しなくなります。
サポート終了のタイムライン
2019 年 1 月にバックフォワード キャッシュの実装に関する意向を発表した際、アンロードの動作が変更される可能性が高いことをお知らせしました。実装作業と並行して大規模なアウトリーチを実施した結果、アンロードの使用量が大幅に減少しました。このアウトリーチを補完するため、Chrome 115 以降、アンロードのサポート終了の影響をテストする方法も提供しています。
- Permission-Policy API for unload による実際のテスト（Chrome 115、2023 年 7 月）
- Chrome 117 でフラグを有効にしてローカルでテストする（2023 年 9 月）
アウトリーチとトライアルのフェーズを経て、ソフトサポートの終了がどのように展開されるかを以下にご紹介します。
- 上位 50 件の人気サイト（記事作成時点の参照）でアンロードが段階的に機能しなくなるスコープ設定されたフェーズ。
- Chrome 120 から 1% のユーザー（2023 年 11 月末）を対象に開始します。
- 2024 年第 3 四半期末までにすべてのユーザーに適用
- また、2024 年第 3 四半期から、すべてのサイトでアンロードが段階的に機能しなくなる一般的なフェーズを開始する予定です。これは、ユーザーの 1% から始まり、2025 年第 1 四半期末までにすべてのユーザーに拡大される予定です。
また、この段階的なサポート終了のタイムラインでアンロードから移行する十分な時間がない場合に備えて、オプトアウト オプションのメニューも用意されています。Google は、このサポート終了の猶予期間を利用して、これらのオプトアウトが削除または削減される最終段階（アンロードのサポート終了）のタイムラインをお知らせすることを目標としています。
背景
unload は、ドキュメントのアンロード時にトリガーするように設計されています。理論上は、ユーザーがページから離れるたびにコードを実行したり、セッション終了のコールバックとして使用したりできます。
このイベントが最も一般的に使用されていたシナリオには、次のものがあります。
- ユーザーデータの保存: ページを離れる前にデータを保存します。
- クリーンアップ タスクの実行: ページを破棄する前に、開いているリソースを閉じます。
- アナリティクスの送信: セッションの終了時に、ユーザー操作に関連するデータを送信します。
ただし、unload イベントは非常に信頼性が低いため、
デスクトップ版 Chrome と Firefox では、unload は比較的信頼性が高いですが、bfcache（前後キャッシュ）の使用を妨げ、サイトのパフォーマンスに悪影響を及ぼします。
モバイル ブラウザでは、タブが頻繁にバックグラウンドに移動されて終了するため、unload が実行されないことがよくあります。このため、ブラウザはモバイルで unload よりも bfcache を優先し、信頼性がさらに低下します。Safari ではパソコンでもこの動作が使用されます。
Chrome チームは、デスクトップで 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 DevTools
Chrome DevTools の 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
PerformanceNavigationTiming クラスに追加された notRestoredReasons プロパティは、ドキュメントのナビゲーションでの bfcache の使用がブロックされたかどうか、およびブロックされた理由を報告します。使用方法については、こちらをご覧ください。次の例は、既存の unload リスナーのレスポンス オブジェクト警告を示しています。
{
children: [],
id: null,
name: null,
reasons: [
{"reason", "unload-handler"}
],
src: null,
url: "https://www.example.com/page/"
}
unload へのアクセスを制御する
Chrome では、unload イベントが段階的に非推奨になります。それまでは、さまざまなツールを使用してこの動作を制御し、今後の非推奨化に備えることができます。これらの手法は長期的に使用しないでください。できるだけ早く代替手段に移行することを計画してください。
次のオプションを使用すると、unload ハンドラを有効または無効にして、ハンドラなしでサイトがどのように動作するかをテストし、今後のサポート終了に備えることができます。ポリシーには次の種類があります。
- 権限ポリシー: サイト所有者が HTTP ヘッダーを使用して、サイトまたは個々のページレベルで機能へのアクセスを制御するためのプラットフォーム API です。
- エンタープライズ ポリシー: IT 管理者が組織や企業の Chrome を設定するためのツール。Google 管理コンソールなどの管理パネルから設定できます。
- Chrome フラグ: 個々のデベロッパーが
unloadのサポート終了設定を変更して、さまざまなサイトへの影響をテストできます。
権限に関するポリシー
Chrome 115 から権限ポリシーが追加され、サイトが unload ハンドラの使用をオプトアウトし、bfcache をすぐに利用してサイトのパフォーマンスを向上させることができるようになりました。サイトでこれを設定する方法の例をご覧ください。これにより、サイトは unload のサポート終了に先駆けて対応できます。
これは Chrome 117 で拡張され、サイトが逆の操作を行い、unload ハンドラの呼び出しを継続的に試行することをオプトインできるようになります。これは、Chrome で今後デフォルトで 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 に感謝します。
Unsplash の Anja Bauermann によるヒーロー画像