APIレスポンスのキャッシング方法 + ウェブページのキャッシング

ウェブサイトで戻るボタンを押した際、既にロード済みのページを再度ロードする経験を多くされているのではないでしょうか。

例えば、ショッピングモールで検索結果に表示された商品をクリックした後、戻るボタンを押すと

再検索されるケースです。

既にロード済みのページを再度ロードする必要があるため、UXにも良くありませんが、システム的には更に大きな問題があります。

ページを新たにロードすることで、不要なAPIを呼び出し、トラフィックを増大させます。

コストの問題も発生する可能性があり、該当ページでデータを収集しているのであれば、特定データの過剰収集という問題もあります。

これを解決するために、ページやAPIの結果をキャッシュすると大きな効果が得られます。

- localStorageはブラウザを閉じてもデータが保持されます。

- sessionStorageはブラウザまたはタブを閉じるとデータが消えます。

- IndexedDBは大容量のデータを保存する際に使用します。非同期的に保存可能であり、NoSqlです。画像やビデオも保存可能です。最大容量はブラウザによって異なりますが、約50MB前後です。オフラインでも使用可能です。

axiosを使用するならば、内蔵機能としてインターセプターを活用できます。同一のリクエストに対して、サーバーに送信せずにレスポンスを返します。

あるコンポーネントをkeep-aliveタグで囲むと、コンポーネントをキャッシュできます。

サーバーサイドレンダリング中にfetch()を呼び出すかどうかを設定できます。falseの場合、クライアントサイドでのみfetchが呼び出されます。

Vuexを活用する方法もあります。原理はブラウザストレージと同じです。

ウェブサーバー（Nginx）を活用してレスポンスヘッダーにキャッシュ設定を含めることができます。

ただし、キャッシュによって画像などのリソース配布時に即時適用されない可能性があるため、このような場合はキャッシュを無効化する必要があります。ファイル名を変更するか、キャッシュを無効化するリクエストを入れるか、AWS CloudFrontを使用しているのであればキャッシュ無効化を適用できます。

Nuxtサーバーでレンダリングされたページ自体をメモリキャッシュに保存する方法もあります。

サーバーサイドキャッシュであり、APIだけでなくページ全体がキャッシュされます。つまり、戻るボタンを押すと遅延なくすぐにロードされます。パフォーマンスは非常に優れていますが、サーバーメモリを使用するため注意が必要です。

もし10,000人のユーザーが同一のページをリクエストする場合、

最初のユーザーがリクエストすると、ページがレンダリングされ、キャッシュされます。

その後、9,999人が同一のページにアクセスすると、サーバーはキャッシュされた結果をレスポンスします。

-> ユーザーごとに個別化されたデータを表示する必要がある場合は、この方法は適切ではありません。

+ cacheは内部的にはlru-cacheパッケージを使用しています。

* lru：最も長く使用されていないデータを優先的に削除するキャッシングアルゴリズムです。

ハッシュマップや二重連結リストデータ構造を使用して、キーバリューを高速に探し出します。：O(1)時間計算量