Get to know MDN better
このページはコミュニティーの尽力で英語から翻訳されました。MDN Web Docs コミュニティーについてもっと知り、仲間になるにはこちらから。
fetchLater() API は、指定した時間が経過した後、またはページが閉じられたとき、あるいは別のページに移動したときに送信される遅延フェッチをリクエストするためのインターフェイスを提供します。
開発者は、例えば分析サービスのため、特にユーザーがページを離れる際など、サーバーへデータを送信（またはビーコンとして送信）する必要があることがよくあります。これを行う方法はいくつかあります。ページに 1 ピクセルの <img> 要素を追加する方法から、XMLHttpRequest、専用の ビーコン API、さらにはフェッチ APIそ のものまで、さまざまな方法があります。
課題は、これらのメソッドのすべてにおいて、セッション終了時のビーコン送信に関して信頼性の問題があることです。ビーコン API やフェッチ API の keepalive プロパティは、ドキュメントが破棄された場合でも（このシナリオにおいて可能な限りの努力を払って）データを送信しますが、これは課題の一部しか解決していません。
それ以外にも、解決がより難しい点は、データをいつ送信するかを決めることです。ページのライフサイクルにおいて、ビーコンを送信するための JavaScript 呼び出しを行うのに理想的な時点は存在しないからです。
つまり、ビーコンを介して確実にデータを送信したい開発者は、理想的な頻度よりも頻繁に送信を行う必要があります。例えば、ページの最終値がまだ到達していない場合でも、変更があるたびにビーコンを送信することになるかもしれません。これには、ネットワーク使用量、サーバー処理、およびサーバー側での古いビーコンの統合や破棄といったコストがかかります。
また、開発者は、以下のいずれかの方法により、ある程度の欠損データを受け入れることを選択することも可能です。
fetchLater() API は、フェッチ API を拡張し、フェッチリクエストを事前に設定することができるものです。これらの遅延フェッチは、送信される前に更新することが可能で、これにより、送信される内容に最新のデータが反映されるようになります。
その後、タブが閉じられたり、別のページに移動したりした際、あるいは指定されている場合は設定された時点が経過した後に、ブラウザーはビーコンを送信します。これにより、ビーコンの重複送信を避けることができますが、妥当な範囲内で（つまり、クラッシュによってブラウザープロセスが予期せず終了した場合を除き）、確実にビーコンを送信します。
必要なくなった場合は、AbortController を使用して遅延フェッチを中止することもでき、それによって不必要なオーバーヘッドを避けることができます。
遅延フェッチはバッチ処理され、タブが閉じられた時点で一括送信されます。この時点で、ユーザーがこれを中止する方法はありません。文書が帯域幅を悪用してネットワーク経由で無制限のデータを送信してしまう事態を避けるため、最上位文書の全体的なクォータは 640KiB に制限されています。
fetchLater()を呼び出し側は、特にサードパーティー製の JavaScript を埋め込んでいる場合は、ほぼすべての場合で QuotaExceededError エラーを捕捉するなどの予防措置を講じる必要があります。
この上限により、遅延フェッチの帯域幅は希少なリソースとなり、複数のレポート元（例えば、複数の RUM ライブラリー）や複数のオリジンからのサブフレーム間で共有される必要があるため、プラットフォームではこのクォータについて妥当なデフォルトの配分を提供しています。さらに、必要に応じて異なる割り当てを行うことができるよう、deferred-fetch および deferred-fetch-minimal の 権限ポリシーディレクティブを提供しており、必要に応じて異なる方法で割り当てを調整することができます。
fetchLater() の全体的なクォータは、文書あたり 640KiB です。デフォルトで、これは 512KiB の最上位クォータと 128KiB の共有クォータに分割されます。
fetchLater() によるリクエストは任意の URL に対して行うことができ、ドキュメントやサブフレームと同じオリジンに限定されるわけではないため、最上位の文書コンテンツ内で行われるリクエスト（ファーストパーティまたはサードパーティーのオリジンへのリクエストを問わず）と、サブフレーム内で行われるリクエストとを区別することが重要です。
例えば、最上位の a.com 文書が <script> を含み、それが analytics.example.com に対して fetchLater() リクエストを行う場合、このリクエストは最上位レベルの 512KiB の制限の対象となります。一方、最上位の文書に、ソースが analytics.example.com で fetchLater() リクエストを行う <iframe> が埋め込まれている場合、そのリクエストには 128KiB の制限が適用されます。
最上位の 512KiB のクォータのうち、同一のレポート送信元（リクエスト URL のオリジン）に対して同時に使用できるのは 64KiB のみです。これにより、サードパーティ製ライブラリーが、送信するデータがない段階で、機会を捉えてクォータを予約してしまうことを防ぎます。
それぞれのオリジン横断サブフレームには、デフォルトで共有の 128KiB のクォータのうち 8KiB が割り当てられます。この割り当ては、サブフレームが DOM に追加された時点で実行されます（そのサブフレームで fetchLater() が使用されるかどうかに関係なく）。つまり、一般的に、ページに追加されたオリジン横断サブフレームのうち、最初の 16 個のみがfetchLater()を使用することができます。これは、これら 16 個のサブフレームで 128KiB のクォータを使い切ってしまうためです。
最上位のオリジンは、選択されたオリジン横断サブフレームに対して、64KiB の追加クォータを付与できます。これにより、そのサブフレームは、最上位の 512KiB という制限から除外されます。この権限ポリシーディレクティブに、それらのオリジンを出力することで実現されます。これは、サブフレームが DOM に追加された際に割り当てられ、最上位の文書および直接の同一オリジンサブフレームに割り当てられるクォータを減少させます。複数の同一オリジンサブドメインが、それぞれ 64KiB のクォータを取得できます。
最上位のオリジンは、deferred-fetch-minimal 権限ポリシーに特定のオリジンを記載することで、128KiB の共有クォータを名前付きオリジン横断サブフレームに制限することも可能です。同時に、deferred-fetch-minimal 権限ポリシーを () に設定することで、128KiB のデフォルトのサブフレームクォータ全体を取り消し、代わりに自身および名前付き deferred-fetch のクロスオリジンに対して 640KiB のクォータを全量確保することも可能です。
デフォルトで、サブフレームのサブフレームにはクォータが割り当てられていないため、fetchLater() を使用することはできません。64KiB に増量されたクォータが割り当てられたサブフレームは、自分自身で deferred-fetch 権限ポリシーを設定することで、64KiB のクォータ全体をさらに下位のサブフレームに委譲し、それらのサブフレームが fetchLater() を使用することができるようにすることができます。ただし、クォータの一部ではなく、全量をさらなるサブフレームに委譲することしかできず、新しいクォータを指定することはできません。最小の 8KiB クォータを使用しているサブフレームは、サブフレームにクォータを委譲することはできません。クォータを委譲されるためには、サブサブフレームがトップレベルおよびサブフレームの deferred-fetch Permissions-Policy ディレクティブの両方に含まれている必要があります。
クォータを超過した場合、遅延リクエストを開始するために fetchLater() メソッドが呼び出されると、QuotaExceededError が発生します。
権限ポリシーのチェックは、クォータのチェックと区別がつきません。fetchLater() を呼び出すと、実際にクォータを超過している場合だけでなく、権限ポリシーによってそのオリジンに対してクォータが制限されている場合にも、QuotaExceededError が発生します。
fetchLater() を呼び出し側は、特にサードパーティー製の JavaScript を埋め込んでいる場合は、ほぼすべての場合で QuotaExceededError エラーをキャッチするなど、予防的な措置を講じる必要があります。
a.com 上の最上位文書があり、そこに a.com のサブフレームが埋め込まれ、さらにその中に b.com のサブフレームが埋め込まれているが、明示的な権限ポリシーは存在しない場合を想定します。
a.com 上の最上位文書があり、そこに <iframe src="https://b.com/"> が埋め込まれており、その中に <iframe src="https://a.com/embed"> のサブフレームが埋め込まれているが、明示的な権限ポリシーは設定されていない場合を想定します。
a.com 上の最上位文書があり、そこに <iframe src="https://b.com/"> が埋め込まれており、その中にさらに <iframe src="https://c.com/"> が埋め込まれているが、明示的な権限ポリシーは設定されていない場合を想定します。
a.com 上の最上位文書があり、そこに <iframe src="https://b.com/"> が埋め込まれており、その中にさらに <iframe src="https://c.com/"> が埋め込まれていると仮定します。
a.com が以下の権限ポリシーを持つことを想定します。
また、b.com が以下の権限ポリシーを持っていることを想定します。
a.com 上の最上位文書があり、そこに <iframe src="https://b.com/"> が埋め込まれており、これが c.com にリダイレクトされ、明示的な最上位の権限ポリシーが存在しない場合を想定します。
例えば、以下の <iframe> が https://www.example.com に埋め込まれている場合、
これは、最上位の文書と同じオリジンでホストされているにもかかわらず、「同一オリジン」とは見なされません。なぜなら、<iframe> はサンドボックス化された環境内にあるからです。したがって、デフォルトで、共有されている合計 128KiB のクォータから、8KiB のクォータが割り当てられることになります。
<iframe> に対して fetchLater() のクォータが割り当てられないようにするには、<iframe> の allow 属性を使用することができます。
同一オリジンの iframe が 512KiB の割り当てを消費してしまうのを防ぐには allow=「deferred-fetch」 ディレクティブが必要であり、別のオリジンの iframe が 128KiB の割り当てを消費してしまうのを防ぐには allow="deferred-fetch-minimal" ディレクティブが必要です。両方のディレクティブを記載することで、src の値にかかわらず、両方の割り当てが使用されるのを防ぐことができます。
最上位の文書に記述されている以下のシーケンスでは、最初の 2 つのリクエストは成功しますが、3 つ目のリクエストでは例外が発生します。これは、たとえ全体としての 640KiB のクォータは超過していないものの、3 つ目のリクエストが https://a.example.com のレポート対象オリジンごとのクォータを超過しているため、例外が発生するからです。
a.com にある最上位文書に、<iframe src="https://b.com/"> が埋め込まれており、これが a.com にリダイレクトされ、明示的な最上位の権限ポリシーが存在しない場合を想定します。
より良いインターネットのための青写真。
このコンテンツの一部は、©1998–2026 個人の mozilla.org 協力者です。コンテンツはクリエイティブ・コモンズ・ライセンスのもとで利用できます。