Service WorkerのライフサイクルとCache Storageのバージョン管理

Service Workerは登録範囲内のページに関するリクエストや機能イベントを処理できます。登録後にinstallイベントを受け取り、waitUntil()に渡すPromiseの成否がインストール完了に影響します。新しいワーカーがインストール済みでも、古いワーカーが制御するページが残っている間、新しいワーカーは待機状態になることがあります。この標準のライフサイクルは複数バージョンのサイトが同時に共有データを扱う際の問題を減らす設計です。Cache Storageは応答を保存するAPIであり、対象や更新方法はアプリ側が実装します。ブラウザーのHTTPキャッシュと自動連動したり、自動更新されたりはしません。

Jake ArchibaldによるService Workerのライフサイクル解説

Jake Archibaldのライフサイクルの解説は、古いワーカーがページを制御しなくなるまで新しいワーカーが待機する既定動作を説明しています。skipWaiting()は待機段階を省略し、clients.claim()は有効化済みワーカーが登録範囲内のページを制御できるようにします。これらを使うと旧バージョンのページと新しいワーカーが同時に動き、リソースやAPIの互換性問題が生じる可能性があります。Archibaldはこれらを考えずに入れる定型コードとして扱わないよう注意しています。即時切替が必要か、旧バージョンのページが新しいワーカーと互換かを先に検討してください。

`install`・`activate`とキャッシュの削除

オフライン利用に必要なリソースはインストール中にキャッシュに保存し、処理をwaitUntil()へ渡して成功前にワーカーがインストール済みとならないようにできます。インストール失敗時には新しいワーカーが破棄され、現在の有効化済みワーカーが維持されます。キャッシュ名にアプリ識別子とバージョンを付けると、有効化時に自分が管理する旧キャッシュだけを削除しやすくなります。同一オリジンで複数アプリがCache Storageを共有する場合があるため、無関係な項目を一括削除しないでください。非同期の有効化処理をライフサイクルイベントに結び、キャッシュ移行とfetch処理の競合を避けます。

保存容量、キャッシュの整合性、ブラウザーでの試験

Cache Storageはブラウザーが管理するオリジンのストレージを使い、無期限の保存を保証しません。容量圧迫、利用者操作、ブラウザーの設定で削除されることがあります。重要な利用者データをこれだけに保存せず、ネットワーク障害、キャッシュミス、スキーマ変更時の復旧経路を用意します。Service WorkerはHTTPSなどの安全な実行環境で利用し、登録範囲（scope）を確認してください。複数タブ、更新後のワーカーが待機している状態、skipWaiting()、オフライン時のインストール失敗、旧キャッシュ削除を対象ブラウザーで試験します。

仮想例：互換性のないキャッシュ形式の更新が待機している場合

旧版の購入ページを開いたまま、新しいService Workerのインストールが完了したものの、新しいキャッシュ形式が旧版ページと互換性がないと仮定します。更新を急ぐためだけにskipWaiting()を呼ばず、旧版を使うタブが閉じてから新しいワーカーを有効化する判断ができます。期待される動作は、開いているページが従来のワーカーとキャッシュを使い続け、旧版のクライアントがなくなった後に更新が有効になることです。即時切り替えが必要なら、両バージョンの互換性を確認し、対象ブラウザーで移行を試験してください。これは仕組みを示す仮想例であり、特定のアプリで実行した結果ではありません。（W3C Service Workers）

参考資料