Open6

Browser Cache API

ブラウザによる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をつかって開発していると使えなくて不便。

作成者以外のコメントは許可されていません