Service Workerのライフサイクルとキャッシュ戦略の内部

なぜライフサイクルを正確に理解する必要があるのか

Service Worker（以下 SW）は、ページとネットワークの間に常駐してリクエストを横取りできる強力なプロキシです。基礎は PWA とサービスワーカー を前提にします。ところが実務で最も多いトラブルは「コードを直してデプロイしたのに、ユーザーには古い挙動のまま」というものです。これは SW のライフサイクルが安全側に倒した厳密な状態遷移で設計されているために起きます。挙動を運や気分ではなく仕様アルゴリズムとして理解すれば、更新事故はほぼ消せます。本記事はその状態遷移と制御権の移動を内部レベルで解きほぐします。

スコープと制御権：どのページを支配するか

SW を navigator.serviceWorker.register('/sw.js', { scope: '/' }) で登録すると、その SW はスコープ配下のすべてのナビゲーションを制御する候補になります。重要な原則が3つあります。

• スコープはスクリプトの URL で頭打ち：/js/sw.js を登録すると既定スコープは /js/ 配下に限られる。ルート全体を制御したいなら SW スクリプトをルート直下に置くか、Service-Worker-Allowed ヘッダで上限を引き上げる。
• 登録と制御は別物：register に成功しても、そのページ自身は既定では制御されない。SW は「次にそのページを読み込んだとき」から制御を始めるのが原則で、初回ロードのページは SW なしで動く。
• 制御は再読み込み境界で切り替わる：あるページがどの SW に制御されるかは、ナビゲーション（ページ遷移・リロード）のタイミングで決まる。開きっぱなしのタブの制御権は、明示操作がない限り途中で変わらない。

状態遷移：parsed から redundant まで

register すると、ブラウザは SW スクリプトを取得・パースし、SW インスタンスは次の状態を順に辿ります。registration.installing / .waiting / .active の3スロットと、各 SW の state プロパティで観測できます。

install イベントは「新版の初期化」、activate イベントは「旧版の後始末」を担当します。両者とも event.waitUntil(promise) に渡した Promise が解決するまで次の状態へ進みません。install 中に cache.addAll([...]) でプリキャッシュを行い、activate 中に古い世代のキャッシュを削除する、という非対称な役割分担がここで効いてきます。

const CACHE = 'app-v3';

self.addEventListener('install', (event) => {
  // install を waitUntil で延長し、プリキャッシュ完了まで installed に進ませない
  event.waitUntil(
    caches.open(CACHE).then((c) => c.addAll(['/', '/app.js', '/offline.html']))
  );
});

self.addEventListener('activate', (event) => {
  // activate で古い世代のキャッシュを一掃（後始末は新版が制御を握ってから）
  event.waitUntil(
    caches.keys().then((keys) =>
      Promise.all(keys.filter((k) => k !== CACHE).map((k) => caches.delete(k)))
    )
  );
});

waiting フェーズ：更新が止まる仕組み

ここが事故の核心です。既に旧版 SW がページを制御している状態で新版を register すると、新版は install まで進んで installed(waiting) で停止します。既存版が制御するクライアントが1つでも残っている限り、新版は activate に進めません。これは「ページ表示中に裏でプロキシがすり替わると、リソースのバージョン不整合（HTML は旧版・JS は新版など）が起きる」ことを防ぐための安全装置です。

つまり、SW を更新するには本来「そのオリジンのタブを全部閉じる」必要があります。リロードだけでは不十分なことが多い点に注意してください。多くのブラウザではリロード時に旧クライアントが一瞬残り、新版は waiting のままになります。

skipWaiting と clients.claim：制御を奪う2つの操作

待機をスキップして即座に新版へ切り替えたい場合、操作は2段階に分かれます。混同すると中途半端な状態になるため、役割を厳密に分けて理解します。

• self.skipWaiting()：waiting フェーズを飛ばし、新版を即 activating → activated へ進める。ただしこれだけでは、既に開いているページの制御権は旧版のまま。skipWaiting は「待機列の追い越し」であって「制御権の移譲」ではない。
• self.clients.claim()：activate 済みの SW が、現在制御されていない／旧版に制御されているクライアントの制御権を奪い取る。これを呼んで初めて、開きっぱなしのタブが次の fetch から新版に流れる。

self.addEventListener('install', (event) => {
  // 待機をスキップして即 activate へ（install 完了直後に追い越す）
  self.skipWaiting();
  event.waitUntil(precache());
});

self.addEventListener('activate', (event) => {
  // activate 完了後、既存クライアントの制御権を即座に掌握
  event.waitUntil(self.clients.claim());
});

ナビゲーションプリロード：起動待ちを隠す

SW は常時メモリに常駐しているわけではなく、アイドル時に終了され、ナビゲーション発生時に再起動されます。問題は、ページ遷移のたびに SW を起動し、その fetch ハンドラが走り終えるまでネットワーク要求が始まらないと、SW 起動分の遅延がそのまま体感速度を悪化させることです。

ナビゲーションプリロード（Navigation Preload）はこれを解決します。registration.navigationPreload.enable() を有効にすると、ブラウザは SW の起動を待たず、ナビゲーション要求をネットワークへ先行送信します。SW の起動とサーバーへの往復が並行して走るため、起動時間が往復時間の陰に隠れます。

重要なのは、先行送信したレスポンスは event.preloadResponse（Promise）として fetch ハンドラに渡される点です。ハンドラ側でこれを消費しないと、先行送信は無駄打ちになります。

self.addEventListener('activate', (event) => {
  event.waitUntil(
    (async () => {
      if (self.registration.navigationPreload) {
        await self.registration.navigationPreload.enable(); // activate で有効化
      }
    })()
  );
});

self.addEventListener('fetch', (event) => {
  if (event.request.mode !== 'navigate') return; // ナビゲーションのみ対象
  event.respondWith(
    (async () => {
      // 先行送信済みレスポンスを優先利用。無ければ自前で fetch
      const preloaded = await event.preloadResponse;
      if (preloaded) return preloaded;
      return fetch(event.request);
    })()
  );
});

enable() は活性化以降に有効になり、送信される要求には Service-Worker-Navigation-Preload ヘッダが付くため、サーバー側で「これはプリロード要求」と判別して応答を最適化できます。プリロードはナビゲーション要求（mode === 'navigate'）にのみ効く点も押さえておきます。

キャッシュ戦略の使い分け

fetch ハンドラ内の応答方針は、SW が Cache Storage（HTTP キャッシュ のブラウザ自動キャッシュとは別の、SW が明示制御する独立した保存域）とネットワークをどう組み合わせるかで決まります。

// Stale-While-Revalidate：キャッシュを即返しつつ、裏で新しい応答を取得して更新
async function staleWhileRevalidate(request) {
  const cache = await caches.open(CACHE);
  const cached = await cache.match(request);
  const fetching = fetch(request).then((res) => {
    cache.put(request, res.clone()); // 次回用に更新（応答は一度しか読めないので clone）
    return res;
  });
  return cached || fetching; // あれば即キャッシュ、無ければネットワークを待つ
}

まとめ