unload イベントは、ページ上で明示的にオプトインしない限り、ページでの unload ハンドラの呼び出しを停止するようデフォルトを段階的に変更することで、段階的にサポートが終了します。
サポート終了スケジュール
Google がバックフォワード キャッシュの実装予定を発表した 2019 年 1 月には、アンロード動作が変更される可能性があるとお知らせしました。実装作業と並行して大規模なアウトリーチを実施した結果、アンロードの使用量が大幅に減少しました。このアウトリーチを補完するために、Chrome 115 からのアンロードのサポート終了の影響をテストする方法の提供も開始しました。
- Permission-Policy API for unload による実際のテスト（Chrome 115、2023 年 7 月）
- フラグを有効にしてローカルテストを行う（Chrome 117）（2023 年 9 月）
アウトリーチとトライアルのフェーズを経て、ソフトサポートの終了がどのように展開されるかを以下にご紹介します。
- 上位 50 の人気サイトのアンロードが徐々に機能しなくなる範囲を定めたフェーズ（この資料の作成時点では参照）。
- ユーザーの 1% から Chrome 120（2023 年 11 月末）以降。
- 2024 年第 3 四半期末までに 100% のユーザーで終了する
- さらに、2024 年第 3 四半期から、全ユーザーの 1% から 2025 年第 1 四半期末までに 100% のユーザーに段階的にアンロード機能を段階的に停止させる汎用フェーズを開始する予定です。
なお、このソフトサポート終了スケジュールではアンロードから移行する十分な時間を確保できない場合に備えて、オプトアウト オプションのメニューも用意されています。このソフトサポートのサポート終了は、これらのオプトアウトが削除または削減される最終フェーズ（アンロードの厳格なサポート終了）のタイムラインを知らせるためのものです。
背景
unload は、ドキュメントがアンロードされるときに起動するように設計されていました。理論上は、ユーザーがページから移動するたびに、またはセッション終了時のコールバックとしてコードを実行するために使用できます。
このイベントが最もよく使用されたシナリオは次のとおりです。
- ユーザーデータの保存: ページから離れる前にデータを保存します。
- クリーンアップ タスクの実行: ページを放棄する前に、開いているリソースを閉じます。
- アナリティクスの送信: セッション終了時のユーザー操作に関連するデータを送信します。
しかし、unload イベントはまったく信頼できません。
パソコンの Chrome と Firefox では、unload は比較的信頼性がありますが、bfcache（バックフォワード キャッシュ）の使用が妨げられ、サイトのパフォーマンスに悪影響を及ぼします。
モバイル ブラウザでは、タブがバックグラウンドに移動してから強制終了されることが多いため、unload は頻繁に実行されません。このため、ブラウザはモバイルの bfcache を unload よりも優先し、信頼性をいっそう強めます。Safari でもパソコンでのこの動作が使用されています。
Chrome チームは、パソコンで unload よりも bfcache を優先するモバイルモデルを使用することは混乱を招く可能性があると考えています。以前は Chrome（および Firefox）ではかなり信頼できていましたが、パソコンでも信頼性が低下します。代わりに、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 を開き、[Application >] に移動します。バックグラウンド サービス >バックフォワード キャッシュ。
[バックフォワード キャッシュをテスト] をクリックします。Chrome は自動的に
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 ハンドラを有効または無効にして、ハンドラなしでのサイトの動作をテストし、今後のサポート終了に備えることができます。ポリシーにはさまざまな種類があります。
- 権限ポリシー: サイト所有者向けのプラットフォーム API です。HTTP ヘッダーを使用して、サイト単位または個々のページ単位で機能へのアクセスを制御できます。
- エンタープライズ ポリシー: IT 管理者が組織やビジネスに合わせて Chrome を設定するためのツール。Google 管理コンソールなどの管理パネルから設定できます。
- Chrome フラグ: 個々のデベロッパーが
unloadのサポート終了設定を変更して、さまざまなサイトへの影響をテストできます。
権限に関するポリシー
サイトが unload ハンドラの使用をオプトアウトし、bfcache をすぐに活用できるようにして、サイトのパフォーマンスを向上させるための権限ポリシーが Chrome 115 で追加されました。サイトでこれを設定する方法の例をご覧ください。これにより、サイトは unload のサポート終了に先駆けて対応できます。
この機能は Chrome 117 で拡張されます。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 に感謝します。
ヒーロー画像: Anja Bauermann、Unsplash より