unload イベントは、デフォルトを段階的に変更することで段階的にサポートが終了されます。これにより、ページで明示的に有効にしない限り、unload ハンドラはページで発生しなくなります。
サポート終了のタイムライン
2019 年 1 月にバックフォワード キャッシュの実装に関する意向を発表した際、アンロードの動作が変更される可能性が高いことをお知らせしました。実装作業と並行して大規模なアウトリーチを実施した結果、アンロードの使用量が大幅に減少しました。このアウトリーチを補完するため、Chrome 115 以降、アンロードのサポート終了の影響をテストする方法も提供しています。
- Chrome 115 の Permission-Policy API for unload による一般ユーザー向けテスト（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 には、unload ハンドラの使用など、ページが前後キャッシュの対象にならない原因となる問題を特定できる back-forward-cache 監査が含まれています。
前後キャッシュをテストする手順は次のとおりです。
ページで 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 ハンドラを有効または無効にして、ハンドラなしでのサイトの動作をテストし、今後のサポート終了に備えることができます。ポリシーにはさまざまな種類があります。
- 権限ポリシー: サイト所有者向けのプラットフォーム API です。HTTP ヘッダーを使用して、サイトまたは個々のページレベルで機能へのアクセスを制御できます。
- エンタープライズ ポリシー: 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 によるヒーロー画像