fetchLaterAPIを触ってみる
概要
chrome135で、fetchLaterAPIが実装されました。 こちらのAPIを下記環境で、検証しまとめます
fetchLaterAPIの概要
fetchLaterが実装されるまでは、(歴史を振り返ればもう少しありますが...)下記二つがあるかと思います。
- fetch API
ブラウザで通信を行う際に、一番一般的な方法になるかと思います。
https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API - sendBeacon
ビーコンの通信を行う際に、fetchAPIに代わる方法になります。
ページが破棄されたとしても、通信が行われるためログの記録などではこちらが選ばれます。
fetchAPIと比べてheaderの変更ができないなどカスタマイズ性に難があります。
https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon
fetchLaterAPIはsendBeaconの難点を解消したものになります。 ページが破棄された時でも、ビーコンの通信を行うことができ、さらにfetchAPIと同等のカスタマイズ性を持っています。
動作の確認
こちらの検証環境をChrome136上で動作を確認します。
破棄時にリクエストが行われることを確認する
検証環境で、2回fetchLaterを実行したのが下記になります。
破棄時(ページリロード時)に、検証環境にGETリクエストが発生しているのがわかります。
※こちらに関して、sendBeaconの実行タイミングを確認すると、fetchLaterと異なり、ボタン押下時にbeaconが送信されているのがわかります。
sendBeaconが実行時に即座に送信されることが約束されているわけではないです
参考: https://w3c.github.io/beacon/#sendbeacon-method
DevTools上で表示を確認する
fetchLaterは、optionに、activateAfterというプロパティを受け付けます。
こちらを設定することでリクエストのタイミングを、ページ破棄時だけではなく、fetchLater実行から、activateAfterミリ秒後にリクエストを行う様にできます。
こちらを設定し、DevToolsでどのような表示になるかを確認します。
await fetchLater(url,{ method: 'GET', headers: {"test": "test"}, activateAfter: 1000 })
ネットワークパネルで確認する
実際に指定したミリ秒後に、ネットワークリクエストが発生し、パネルで確認できます。
こちらは、特にオプションで設定で変更していなければ、タイプ、優先度などはfetchAPIと同等のものになっているのがわかります。
パフォーマンスパネルで確認する
受け取り側（ターミナルのログ）では、fetchLaterのリクエストが実行されることは確認できますが、
少なくとも、Chrome136上ではfetchLaterのリクエストはパフォーマンスパネルで確認できません。
fetchLater自体がネットワーク帯域のボトルネックになる様な場合には、注意が必要そうです。
Discussion