Browser Cache API

リンク集

• https://developer.mozilla.org/ja/docs/Web/API/Cache
• https://developer.mozilla.org/ja/docs/Web/API/CacheStorage
• ブラウザーのストレージ制限と削除基準 MDN
  • Firefoxにおけるeviction戦略
• https://chromium.googlesource.com/chromium/src/+/refs/heads/main/content/browser/service_worker/README.md#eviction
  • Google Chromeにおけるeviction戦略
• The Cache API: A quick guide
• Storage for the web
  • 各ブラウザのeviction戦略が書かれている
• Cache API を利用したフロントエンドキャッシュ
  • fetch以外からのデータを保存する例
• ServiceWorker, Cache API を使用して 4万件のアセット永続化を試した話
  
  • 事例。役立つ記事かは微妙

ブラウザによるevictionを当てにしてはいけなさそう。以下は動作確認をしたわけではなく、文書を読んで得た話。

ブラウザによるけど、たとえばFirefoxはドメイン単位で割り当てられた容量を使い切ったとしても、Firefox全体に割り当てられた容量を使い切らない限りevictされない。つまり、そのドメインの中では永遠に容量が足りないままになる。
https://developer.mozilla.org/ja/docs/Web/API/IndexedDB_API/Browser_storage_limits_and_eviction_criteria の話。

こういう挙動をするブラウザがあることを考えると、バージョンをキーに入れておいて、古いキャッシュはバージョンをbumpすることで放置する、という手法は取りづらい。なぜならば、古いキャッシュは自動的にはevictされないため。
なので、古いキャッシュを自分でevictするようなコードを書く必要がある。

基本的にrequest-responseの組を保存するためのキャッシュストア。
ただし、responseを適当に生成すれば任意のデータも保存可能。そういう使い方が推奨されているのかはよくわからない。(事例はある)

evictionを自分で実装したり、expires_inの設定がなかったりするのが不便そう。これらをいい感じにやってくれるNPMパッケージがあるかは調べて良さそう。とはいえ自前で実装したほうがマシかもしれない。

ServiceWorkerではなくメインスレッド側から使うと、キャッシュの取得に数百msかかってしまって使い物にならないことが分かった。
Google Chromeで300msほど、Firefoxでも100msほどかかっている。

おそらく、「awaitが連続する→別の処理に移る→それが合計で300msほどかかってしまう→キャッシュの取得に300msかかっているように見える」といった状態なのでは。それを裏付けるような状況証拠として、他の処理が特に動いていないような状態でキャッシュを取得すると10ms程度で終わる。

ブラウザのperformanceタブでprofilingしてみるとやっぱりCPUバウンドな処理が動いていて、それをなんとか倒したところだいぶマシになった。Chromeで100msほど、Firefoxで50msほどまで改善。
まあメインスレッドで使うのが良くない気がする

HTTPS or localhostでのみ動く。なのでlvh.meをつかって開発していると使えなくて不便。