公開日: 2023 年 8 月 10 日、最終更新日: 2026 年 4 月 28 日
unload イベントは、unload ハンドラがページで発生しないようにデフォルトを徐々に変更することで、段階的に サポート終了 となります。ページで unload ハンドラを再度有効にするには、明示的にオプトインする必要があります。
サポート終了スケジュール
Google は、バックフォワード キャッシュの実装の意向を発表した 2019 年 1 月に、アンロードの動作が変更される可能性があることをお知らせしました。実装作業と並行して、大規模なアウトリーチを実施した結果、アンロードの使用量が大幅に減少しました。このアウトリーチを補完するために、Chrome 115 以降でアンロードのサポート終了の影響をテストする方法も提供しました。
- Chrome 115 でアンロードの Permission-Policy API を使用した実際のテスト（2023 年 7 月）
- Chrome 117 でフラグを有効にしてローカルテストを実施（2023 年 9 月）
2024 年には、ロールアウトの開始を妨げるいくつかの問題に対処し、2025 年には、上位 50 サイトでサポート終了をロールアウトしました。
| マイルストーン | マイルストーンの日付 | 上位 50 サイト | その他のオリジンの割合（%） |
|---|---|---|---|
| 135 | 2025 年 3 月 26 日 | 1（www.google.com） |
0 |
| 139 | 2025 年 7 月 30 日 | 5 | 0 |
| 140 | 2025 年 8 月 27 日 | 10 | 0 |
| 141 | 2025 年 9 月 24 日 | 25 | 0 |
| 142 | 2025 年 10 月 22 日 | 50 | 0 |
上位 50 サイトのサポート終了が完了したため、次の表に示すように、8 つのマイルストーン（約 32 週間）にわたってすべてのオリジンにロールアウトするための承認を得ました。
| マイルストーン | マイルストーンの日付 | 上位 50 サイト | すべてのサイトの Chrome ページ読み込みの割合（%） |
|---|---|---|---|
| 146 | 2026 年 3 月 10 日 | 50 | 1 |
| 147 | 2026 年 4 月 7 日 | 50 | 5 |
| 148 | 2026 年 5 月 5 日 | 50 | 10 |
| 149 | 2026 年 6 月 2 日 | 50 | 20 |
| 150 | 2026 年 6 月 30 日 | 50 | 40 |
| 151 | 2026 年 7 月 28 日 | 50 | 60 |
| 152 | 2026 年 8 月 25 日 | 50 | 80 |
| 153 | 2026 年 9 月 22 日 | 50 | 100 |
完全に展開は、個々のユーザーやサイトではなく、ページ読み込み（時間の経過に伴う一貫性）に基づいて行われます。これは、他のユーザーやサイトよりも影響を受けないようにするためです。サポート終了の意向で説明されているように。
このサポート終了スケジュールではアンロードからの移行に十分な時間が確保できない場合に備えて、オプトアウト オプションのメニューも用意しています。Google の目標は、この ソフト サポート終了 を使用して、これらのオプトアウトが削除または削減される最終フェーズ（アンロードのハード サポート終了）のスケジュールを通知することです。
背景
unload は、ドキュメントがアンロードされるときに発生するように設計されています。理論的には、ユーザーがページから移動するたびにコードを実行したり、セッション終了時のコールバックとして使用したりできます。
このイベントが最も一般的に使用されるシナリオは次のとおりです。
- ユーザーデータの保存: ページを離れる前にデータを保存します。
- クリーンアップ タスクの実行: ページを破棄する前に開いているリソースを閉じます。
- アナリティクスの送信: セッション終了時にユーザー インタラクションに関連するデータを送信します。
ただし、unload イベントは非常に信頼性が低くなります。
パソコン版 Chrome と Firefox では、unload は比較的信頼性が高いですが、bfcache（バックフォワード キャッシュ）の使用を妨げるため、サイトのパフォーマンスに悪影響を及ぼします。
モバイル ブラウザでは、タブが頻繁にバックグラウンドに移動して終了するため、unload が実行されないことがよくあります。そのため、ブラウザではモバイルで unload よりも bfcache が優先されるため、信頼性がさらに低下します。Safari でも、パソコンでこの動作が使用されます。
Chrome チームは、パソコンで bfcache よりも unload を優先するモバイルモデルを使用すると、以前は 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 に移動します。
[Test back/forward cache] をクリックします。Chrome は自動的に
chrome://terms/に移動し、ページに戻ります。または、ブラウザの [戻る] ボタンと [進む] ボタンをクリックすることもできます。
ページがバックフォワード キャッシュの対象外の場合、[Back/forward cache] タブに問題のリストが表示されます。[Actionable] で、unload を使用しているかどうかを確認できます。
Reporting API
Reporting API は、読み取り専用の権限に関するポリシーと組み合わせて使用して、ウェブサイト ユーザーからの unload の使用状況を検出できます。
詳しくは、Reporting API を使用してアンロードを検出するをご覧ください。
Bfcache notRestoredReasons API
notRestoredReasons プロパティ—PerformanceNavigationTiming クラスに追加された—は、ナビゲーションでドキュメントが bfcache の使用をブロックされたかどうかと、その理由に関する情報を報告します。既存の unload リスナーに関するレスポンス オブジェクトの警告の例を次に示します。
{
children: [],
id: null,
name: null,
reasons: [
{"reason", "unload-listener"}
],
src: null,
url: "https://www.example.com/page/"
}
unload へのアクセスを制御する
Chrome は unload イベントを段階的にサポート終了にします。それまでは、さまざまなツールを使用してこの動作を制御し、今後のサポート終了に備えることができます。これらの手法に長期的に依存するのではなく、できるだけ早く代替手段に移行することを計画してください。
次のオプションを使用すると、unload ハンドラを有効または無効にして、unload ハンドラがない場合にサイトがどのように動作するかをテストし、今後のサポート終了に備えることができます。ポリシーにはさまざまな種類があります。
- 権限に関するポリシー: これは、サイト所有者が HTTP ヘッダーを使用して、サイトまたは個々のページレベルで機能へのアクセスを制御するためのプラットフォーム API です。
- エンタープライズ ポリシー: IT 管理者が組織や企業の Chrome を構成するためのツールです。Google 管理コンソールなどの管理者パネルを使用して構成できます。
- Chrome フラグ: これにより、個々のデベロッパーが
unloadのサポート終了設定を変更して、さまざまなサイトへの影響をテストできます。
権限に関するポリシー
Chrome 115 から権限に関するポリシーが追加され、サイトは unload ハンドラの使用をオプトアウトして、bfcache のメリットをすぐに活用してサイト パフォーマンスを向上させることができます。サイトでこの設定を行う方法については、こちらの例をご覧ください。これにより、サイトは unload のサポート終了に先駆けて対応できます。
Chrome 117 では、サイトが逆の操作を行えるように拡張されました。つまり、Chrome がデフォルトで unload ハンドラを発生させないように変更しても、現在と同じように unload ハンドラを発生させ続けるようにオプトインできます。サイトでアンロード ハンドラを引き続き発生させる方法については、こちらの例をご覧ください。unload ハンドラの信頼性が低いことを考慮すると、サイト所有者は unload ハンドラの使用を中止することをおすすめしますが、Google は、unload ハンドラを使用する必要があるサイトに対して、今後もこのオプトアウトをサポートする予定です。また、オプトインしても、モバイルでの unload ハンドラの信頼性は向上しません。現在の現状が復元されるだけです。
エンタープライズ ポリシー
unload イベントに依存して正しく機能するソフトウェアを使用している企業は、ForcePermissionPolicyUnloadDefaultEnabled ポリシーを使用して、管理下のデバイスで段階的なサポート終了を回避できます。このポリシーを有効にすると、unload はすべてのオリジンでデフォルトで有効になります。必要に応じて、ページでより厳格なポリシーを設定することもできます。権限に関するポリシーのオプトアウトと同様に、これは潜在的な破壊的変更を軽減するためのツールです。繰り返しになりますが、サイト所有者は unload ハンドラへの依存を停止することをおすすめしますが、Chrome は、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