ServiceWorkerがキャッシュを掌握する仕組み｜オフライン対応とキャッシュ戦略の実践ガイド

#PWA #ServiceWorker #オフライン対応 #キャッシュ戦略 #フロントエンド
C
クリオ
Web制作ディレクター / フロントエンジニア

こんにちは！

今日は「ServiceWorkerを使ったキャッシュ戦略」について解説します。
ブラウザキャッシュやWordPressキャッシュの話は結構出てくるんですが、実はめっちゃ強力な武器がもう一つあるんです。
それが「ServiceWorker」なんですよ。

ServiceWorkerって何？現場での位置づけ

ServiceWorkerは、ブラウザとネットワークの間に立つ「仲介役」みたいなイメージです。
普通のJavaScriptと違って、ページが閉じていてもバックグラウンドで動作するんですよ。

僕が初めてServiceWorkerに触れたときは「え、こんなことできるの？」ってビックリしました。
なぜなら、ブラウザキャッシュだけでは対応できない「細かいキャッシュ制御」ができるからなんです。

例えば、こんなシーン想像してみてください。
ユーザーがあなたのWebサイトを訪問して、その後ネットが不安定になった。
普通なら「申し訳ございません、接続できません」って表示されるやん。
でもServiceWorkerがあれば、以前キャッシュしたデータを「ちょい、こっち使ってや」って渡せるわけです。

ServiceWorkerの主な役割：

  • ブラウザのネットワークリクエストを「横取り」できる
  • キャッシュを戦略的に保存・削除できる
  • オフライン状態でも一部機能を動作させられる
  • 定期的に裏でコンテンツを更新できる（バックグラウンド同期）

キャッシュ戦略の3つのパターン

ServiceWorkerを使ったキャッシュには、いくつかの戦略があります。
どの戦略を選ぶかで、サイトの体感速度やデータ更新のタイミングが大きく変わるんですよ。

1. Cache First（キャッシュ優先戦略）

「まずキャッシュを見て、なかったらネットワークに行く」という戦略です。
めっちゃ高速ですが、古いデータを掴まされるリスクがあります。

使うべき場面：

  • 画像ファイル
  • CSS・JavaScriptファイル
  • フォントファイル
  • ほぼ更新されないアセット

コード例をざっくり書くと、こんな感じです。

self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request)
      .then((response) => {
        return response || fetch(event.request);
      })
  );
});

2. Network First（ネットワーク優先戦略）

「まずネットワークに行って、失敗したらキャッシュを使う」という戦略です。
常に最新データを取得しようとするので、新鮮な情報が取得できます。

使うべき場面：

  • 記事やニュースコンテンツ
  • ユーザー情報
  • リアルタイムで更新される情報

3. Stale While Revalidate（古いデータを使いながら更新戦略）

「キャッシュをすぐ返しておいて、同時にネットワークで新しいデータ取ってくるね」という戦略。
ユーザーは高速に画面が表示されるし、バックグラウンドで最新データも取得できるんです。

現場ではほんまにこれが便利です。
ユーザー体験とコンテンツの鮮度、両方を実現できるからですね。

僕が実際に失敗した事例と対策

ServiceWorkerの便利さを知った僕は、ある案件で張り切ってしまったんです。
「よし、全部のアセットをCache Firstにしたろ！」って。

結果は…悲劇でした。

クライアントが新しいバージョンの画像をアップロードしたのに、ユーザーの画面には古い画像が映ったままなんです。
「キャッシュがずっと残ってるせいや…」って気づいたのは、クレームの後でした。
ほんま、焦りました。

そこから学んだ対策：

  1. バージョニングを徹底する
    ファイル名にstyle.v1.cssとかバージョン番号を入れるんです。
    変更があったらstyle.v2.cssに変わるので、キャッシュが効かないわけです。
  2. キャッシュの有効期限を設定する
    ServiceWorkerは直接的な有効期限機能はないので、手動で古いキャッシュを削除する処理を書きます。
  3. 重要なアセットは更新チェック機能を付ける
    定期的にサーバーに「新しいバージョンあります？」って問い合わせる処理を仕込むんです。
    あったらユーザーに「更新があります、再読み込みしますか？」って案内できます。

実装は最初ちょっと複雑に感じるかもしれません。
でも一度理解すると、めっちゃ強力な武器になるんですよ。

実装時の注意点：

  • https環境が必須です。
    localhostならhttpでもいいですが、本番はかならずhttpsにしてください。
  • ServiceWorkerは登録後、すぐには有効にならないことがあります。
    ページのリロードが必要なケースもあります。
  • デバッグが少し難しいので、ブラウザの開発者ツール（DevTools）の「Application」タブで確認するといいですよ。
  • 古いServiceWorkerが残っていると、意図しない動作になることがあります。
    テスト時は「Unregister」をしてクリーンな状態を保つといいです。

まとめ

ServiceWorkerは、ブラウザキャッシュやWordPressキャッシュとは別レイヤーで動作する、めっちゃ強力なキャッシュ制御機能です。
正しく使えば、オフライン対応やUX向上に大きく貢献します。

ただし、「便利だから全部これでやろう」みたいなやり方はNGです。
キャッシュ戦略ごとに最適なパターンが違うので、コンテンツの特性に合わせて選ぶことが大事なんですよ。

僕の失敗から学んだのは「キャッシュはいつか古くなる」ということです。
その古いデータをどう扱うかが、良いWebサイトを作るコツなんだと思います。