2024-11-03

Fetch APIとキャッシュ戦略のまとめ

FetchAPIのハンズオンとパフォーマンスまとめ

ハンズオン

https://github.com/soutaschool/karan-js-fetch-cache

結論

ざっくりとした認識。

もちろんキャッシュ戦略などによってそれぞれのトレードオフを考慮することが必要。

イメージ

実際の取得時間（1000件）

キャッシュをうまく利用できれば、パフォーマンスを大きく向上させることができる。

ネットワーク

概要

Default

ブラウザにキャッシュを依存する。

そのため他と比較して自由度は低いが十分なパフォーマンスと信頼性を提供できる。

ブラウザ側が最適化されているケースが多いので多くの場面でファーストチョイスになることが多い。

リクエスト及びレスポンスヘッダーに基づいて動作を自動的に決定。

No-store

キャッシュの読み込みも書き込みも行わない。

常にネットワークから最新のレスポンスを取得することができ、そのレスポンスもキャッシュとして保存しない。

毎回のサーバー間との通信が行われるため、サーバーの負荷は避けられない。

利用するときは常に最新のデータが欲しい場合などに抑える必要がある。

Reload

キャッシュが存在していても利用せず、リソースをサーバーから取得しそのリソースをキャッシュに保存する。

常に最新のデータをキャッシュしておくことができる。

No-storeのとの大きな違いとしてキャッシュを保存するため、次回からキャッシュを利用することができ、ネットワーク間での通信を削減することができる。

Force-cache

キャッシュが存在する場合はそれを優先して利用し、ない場合のみサーバーから取得する。

大きくパフォーマンスの向上につながるほか、サーバーの通信の削減にもつながる。

ただし、キャッシュのデータを毎回使い回すためデータが更新されている場合でも古いデータを取得してしまう。

そのため更新がある場合はExpiresなどをヘッダーに設定して、戦略的にサーバーからデータを取得しなければならない。

変更がないCSS、JS、画像などの静的アセットにはとても向いている。

ユースケース

このブログはSSGを利用しているためビルド時点ですでにStaticとして完成されているが、もし毎回サーバー間と通信を行うアーキテクチャだった場合は、Force-cacheを利用していたと考える。

Only-if-cached

リクエストがキャッシュに存在するのみ、キャッシュを利用し存在しない場合はリクエストを失敗させる。

オリジンが同じ環境でのみ利用でき、クロスオリジンでの利用はTypeErrorとなる。

キャッシュのみが存在する場合でのみ利用できるためオフライン環境での利用もできる。

Service workerと組み合わせて利用することが多い。

キャッシュが存在しない場合

ブラウザでマニュアルでキャッシュを削除するなどしたら確認できる。