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 ハンドラを有効または無効にして、ハンドラなしでサイトがどのように動作するかをテストし、今後のサポート終了に備えることができます。ポリシーには次の種類があります。
- 権限ポリシー: サイト所有者が 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 によるヒーロー画像