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
イベントの外観は、さまざまなツールで確認できます。これにより、サイトはこのイベントを使用しているかどうかを(独自のコードまたはライブラリ経由で)確認できます。また、今後のサポート終了による影響を受ける可能性があります。
Chrome DevTools
Chrome DevTools では、back-forward-cache
監査を使用して、ページのバックフォワード キャッシュの対象を妨げている可能性のある問題(unload
ハンドラの使用など)を特定できます。
バックフォワード キャッシュをテストする手順は次のとおりです。
ページで DevTools を開き、[アプリケーション] > [バックグラウンド サービス] > [バックフォワード キャッシュ] に移動します。
[バックフォワード キャッシュのテスト] をクリックすると、自動的に
chrome://terms/
に移動し、元のページに戻ります。または、ブラウザの [戻る] ボタンと [進む] ボタンをクリックします。
ページがバックフォワード キャッシュの対象でない場合は、[バックフォワード キャッシュ] タブに問題のリストが表示されます。[Actionable] で、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
ハンドラを今後も呼び出すことをオプトインできるようにします。サイトのアンロード ハンドラを引き続き起動できるようにする方法については、こちらの例をご覧ください。このオプトインは永久に維持されるわけではなく、サイトが 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)