Service Worker の開発エクスペリエンスの向上

Service Worker のライフサイクルでは、インストールと更新のプロセスを予測できますが、ローカルの開発サイクルは若干複雑になります。

一般的なローカル開発サイクルでは、デベロッパーはテキスト エディタでファイルに変更を保存してから、ブラウザに切り替えて変更を検証すると、このプロセスが繰り返されます。Service Worker が含まれている場合でも、このサイクルはほぼ同じですが、デベロッパーが想定する動作とブラウザの動作が異なる場合があります。

ローカルでの開発の例外

一般に、Service Worker API は HTTPS 経由で提供されるページでのみ利用可能ですが、このルールの例外で HTTP 経由で使用できる場合があります。1 つの注目すべき例外は localhost で提供されるページです。これはローカルでの開発に適しています。

しかし、デベロッパーが hosts ファイルlocalhost 以外のローカルホスト名を指定することは珍しくありません。これは、ローカル開発環境で複数のプロジェクトで別々のホスト名が必要な場合に必要になります。そのような場合は、自己署名証明書のプロビジョニングで対応できます。

より便利な回避策としては、Service Worker のテストで例外を作成するようにブラウザに指示する方法があります。Chrome の場合は、chrome://flags/#unsafely-treat-insecure-origin-as-secure に移動し、保護されていないオリジンを安全なオリジンとして指定します。 Firefox では、about:configdevtools.serviceWorkers.testing.enabled 設定を通じて、保護されていないオリジンで Service Worker をテストできます。

Service Worker の開発支援

Service Worker が混在するローカルでの開発では、予期しない動作が発生する可能性があります。 たとえば、バージョニングされていない静的アセットや、変更後に再読み込みで更新されることが予想される、事前キャッシュされた「オフラインです」ページに対して、キャッシュのみの戦略を導入するとします。 古いバージョンのアセットは常に Cache インスタンスから提供されるため、更新されることはないように見えます。Service Worker は、動作するように設計されたものだけですが、テストを容易にする方法がいくつかあります。

Service Worker のテストに最も効果的な方法は、Chrome のシークレット ウィンドウや Firefox のプライベート ブラウジング機能などのプライベート ブラウジング ウィンドウを利用することです。シークレット ブラウジング ウィンドウを開くたびに、新しいウィンドウが起動します。 アクティブな Service Worker も、開いている Cache インスタンスもありません。この種のテストのルーチンは次のとおりです。

  1. シークレット ブラウジング ウィンドウを開きます。
  2. Service Worker を登録するページに移動します。
  3. Service Worker が期待どおりに動作するかどうかを確認します。
  4. シークレット ウィンドウを閉じます。
  5. その繰り返し。

このプロセスでは、Service Worker のライフサイクルを忠実に再現します。

Chrome DevTools の [Application] パネルで利用できる他のテストツールが役立ちます。ただし、Service Worker のライフサイクルを変更できる点がいくつかあります。

Chrome DevTools のアプリケーション パネル

アプリケーション パネルには [Service Workers] というサブパネルがあり、現在のページでアクティブな Service Worker が表示されます。アクティブな各 Service Worker を手動で更新したり、登録を解除したりできます。 上部には開発に役立つ切り替えボタンも 3 つあります。

  1. [Offline] は、オフラインの状態をシミュレートします。これは、アクティブな Service Worker がオフライン コンテンツを配信しているかどうかをテストする際に役立ちます。
  2. 再読み込み時の更新: オンにすると、ページが再読み込みされるたびに現在の Service Worker が再取得されて置き換えられます。
  3. ネットワークをバイパス: オンにすると、Service Worker の fetch イベントに含まれるコードを回避し、常にネットワークからコンテンツを取得します。

これらは便利な切り替えボタンです。特にネットワークをバイパスします。これは、アクティブな Service Worker を使用するプロジェクトを開発する場合に便利です。また、Service Worker がなくても想定どおりに動作するようにしたい場合に最適です。

Firefox のデベロッパー ツールにも同様のアプリケーション パネルがありますが、使用できる機能は、インストールされている Service Worker を表示する機能と、現在のページでアクティブな Service Worker を手動で登録解除することです。同様に有用ですが、ローカルの開発サイクルでは多くの手作業が必要となります。

シフトして再読み込み

アクティブな Service Worker を使用してローカルで開発し、更新時の更新ネットワークのバイパスが提供する機能を必要としない場合は、Shift キーを押しながら更新ボタンを押すと便利です。

これを「強制更新」といいます。これにより、ネットワークの HTTP キャッシュがバイパスされます。 Service Worker がアクティブな場合、強制更新も Service Worker を完全にバイパスします。

この機能は、特定のキャッシュ戦略が意図したとおりに機能しているかどうか不確かである場合に役立ちます。また、ネットワークからすべての情報を取得して、Service Worker を使用する場合と使用しない場合の動作を比較する際に役立ちます。これは指定された動作であるため、Service Worker をサポートするすべてのブラウザで監視の対象となります。

キャッシュの内容の検査

キャッシュを検査できなければ、キャッシュ戦略が意図したとおりに機能しているかどうかを判断するのは困難です。もちろん、キャッシュはコード内で検査できますが、これは、ビジュアル ツールの方がタスクに適した場合はデバッガや console ステートメントが関係するプロセスです。 Chrome DevTools の [Application] パネルには、Cache インスタンスの内容を調べるためのサブパネルがあります。

DevTools でのキャッシュの検査

このサブパネルには次のような機能が用意されているため、Service Worker の開発が容易になります。

  • Cache インスタンスの名前を表示します。
  • キャッシュに保存されたアセットのレスポンス本文と、関連するレスポンス ヘッダーを検査する機能。
  • キャッシュから 1 つ以上のアイテムを削除します。Cache インスタンス全体を削除することもできます。

このグラフィカル ユーザー インターフェースを使用すると、Service Worker のキャッシュを調べ、Service Worker のキャッシュに対してアイテムが追加、更新、削除されたかどうかを簡単に確認できます。Firefox には同様の機能を持つ独自のキャッシュ ビューアが用意されていますが、別の [ストレージ] パネルにあります。

保存容量のシミュレーション

大きな静的アセット(高解像度画像など)を多く含むウェブサイトでは、保存容量の上限に達する可能性があります。この場合、ブラウザは、古くなっていると判断したアイテム、または新しいアセット用のスペースを確保するために犠牲にする価値があるアイテムをキャッシュから削除します。

保存容量の割り当ての処理は Service Worker の開発の一部である必要があります。Workbox では、自身で管理するよりもこのプロセスがシンプルになります。ただし、Workbox の有無にかかわらず、カスタム ストレージ割り当てをシミュレートしてキャッシュ管理ロジックをテストすることをおすすめします。

ストレージ使用量のビューア。
Chrome の DevTools の [Application] パネルにあるストレージ使用量ビューア。この例では、カスタムの保存容量割り当てが設定されています。

Chrome の DevTools の [Application] パネルには、[Storage] サブパネルがあり、ページによって現在使用されている保存容量の割り当てが表示されます。 また、カスタム割り当てをメガバイト単位で指定することもできます。 有効になっている場合、Chrome ではカスタムの保存容量の割り当てが適用され、テストが可能になります。

なお、このサブパネルには [サイトデータを消去] ボタンと、このボタンをクリックすると消去される項目に対応する一連のチェックボックス全体が表示されます。 その中には、開いている Cache インスタンスと、ページを制御しているアクティブな Service Worker の登録解除機能があります。

開発が容易で生産性が向上

開発者の制約がなくなると、自信を持って作業し、生産性を高めることができます。 Service Worker を使ったローカルでの開発は微妙に異なりますが、手間をかける必要はありません。ここで紹介するヒントとコツを理解すれば、アクティブな Service Worker を使った開発の方法がはるかにわかりやすく、予測可能になり、デベロッパーのエクスペリエンス向上につながります。