webpackでServiceWorkerのオフラインキャッシュと戯れる』を参照ください)が、手当たり次第にキャッシュしてしまうとキャッシュストレージを圧迫してしまったり、更新性の高いコンテンツが反映されなかったりとさまざまな問題に直面します。自社プロダクトへの実装を考えるにあたり、キャッシュ戦略についてもう少し理解を深めて(考えて)みたいと思います。Cache”の2つが登場しました。これはキャッシュを生成するタイミングを管理する要素になります。実装するときには、まず各ファイルがこのどちらに分類した方がよいのかを考えることから始めることになるのではないかと思います。CacheServiceWorkerの起動時にキャッシュされます。事前キャッシュと表現されたりもしています。Cacheしたものは、URLにハッシュをつけたりしてユニークなものにしない限り変更されません。Cacheすると良いのではないかと思います。Cache指定した任意のURLにアクセスしたタイミングで取得したデータをキャッシュします。動的なリソースを指定します。APIからのGetリクエストなども含まれます。Cacheでは、データをどのように取得するのかという“キャッシュ戦略”も選択できます。Strategy)とはキャッシュ戦略と呼ばれているので、誰かがそういう戦略を提唱しているものだと思ってしまいそうですが、実際はファイルを「キャッシュから取得するのか」それとも「ネットワーク経由で取得するのか」というファイル取得のパターンをそのように呼んでいると解釈しました。Strategy”を単に和訳したのでそうなっているのだと思います。Strategy)のパターンいろいろパターンがあるのでここで軽く紹介します。実装時にはこれらのロジックをファイルの用途や性質などによって使い分ける必要があると思います。First文字通り最初にキャッシュに要求されたファイルを探しにいきます。キャッシュにデータがなければネットワーク経由でファイルを取得します。Onlyキャッシュからのみファイルを返します。Firstとは逆に最初にネットワーク経由で要求されたファイルを探しにいきます。ネットワークに接続できない状態だったりした場合はキャッシュにデータを探しにいきます。Onlyネットワーク経由でのみファイルを返します。Revalidateキャッシュに要求されたファイルを探しにいき、キャッシュにデータがなければネットワーク経由で取得します。Firstと異なる点は、バックグラウンドでfetchしてキャッシュのデータを更新します。Strategy)の特性を理解した上で弊社サイトの記事一覧ページ(https://www.hivelocity.co.jp/blog/)を例にして導入シミュレーションをしてみます。上記のページをざっとパーツごとに分類すると以下のようなパターンになるかと思います。ヘッダーエリアスライダーエリアコンテンツエリアフッターエリアそれぞれ見ていきましょう。Cacheしても良いと思います。スライダーエリアスライダーエリアでは、新着記事を表示していますので頻繁に更新がかかります。Cacheした方が良いと思います。Firstを選択しておいた方がよいのではないでしょうか。Cacheした方が良いと思います。Firstが良いと思います。Cacheしても良いと思います。Cacheしてしまって良いと思います。その他その他ページ全体で使用するデータについては以下のようなものがあります。Cacheで良いと思います。Cacheしても良いと思いますが、ここはサイトの構成によって変わってくると思います。弊社ではJavaScriptとCSSをコンポーネントやモジュールごとに分けておりますが最終的に1つのファイルにバンドルしています。Cacheするのが良いと思いました。致命的なバグを持った状態でProductionにdeployされないようにフローが整っていれば、Stale-While-Revalidateを採用しても良いかもしれません。Cacheを設定した方が良いのかなと感じました。Firstのキャッシュ戦略がベースとなる気がします。キャッシュはオフライン時でもある程度の閲覧を担保するための補助的な役割になると思いますので、基本的なレイアウトを描画する上で必要なファイルなどを含めておくというような感じになるのではないでしょうか。今回は自社サイトを例にして考えてみましたが、サイトの性質やファイル構成によって変わってくると思います。実際にProductionに投入してみて、新しい発見や問題などが見えてきたらまた考察してみたいと思います。隆行プロダクトマネージャー/フロントエンドエンジニア最近、肝臓が悪いと宣告されたので、何かというと牡蠣をアテに呑むように気をつけてます。酒飲むなよってハナシですがやめません。