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

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

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

ローカルでの開発の例外

一般に、Service Worker API は HTTPS 経由で提供されるページでのみ使用できます。 ただし例外として、HTTP 経由で使用できる場合もあります。 重要な例外の 1 つは、localhost 経由で提供されるページです。これはローカルでの開発には適しています。

ただし、デベロッパーが localhost 以外のローカルホスト名を hosts ファイル。 これは、複数のプロジェクトで個別のホスト名を必要とするローカル開発環境で必要です。 このような場合は、自己署名証明書をプロビジョニングすることで対処できます。

より便利な回避策は、Service Worker のテスト用に例外を生成するようにブラウザに指示することです。 Chrome の場合は、chrome://flags/#unsafely-treat-insecure-origin-as-secure に移動します 保護されていない発行元を指定して、安全な発行元として扱います。 Firefox では、about:config の devtools.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 のライフサイクルは、いくつかの方法で変更できます。

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

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

で確認できます。

注意: [Update for refresh] を使いたくなるかもしれませんがチェックボックスをオンにする必要があります。 実際、これはとても便利です。 残念なことに、そのままでも簡単に実装できます。Service Worker が有効になっていて、Chrome の DevTools が開いている限り、Service Worker のライフサイクルの仕組みが根本的に変化します。 この機能を Service Worker のテストの中心部分にすることはおすすめしません。

[Bypass for network] は便利な切り替えボタンです。 アクティブな Service Worker で プロジェクトを開発する場合や Service Worker なしで想定どおりに動作するようにしたいとも考えています。

Firefox のデベロッパー ツールにも、同様のアプリケーション パネルがあります。 ただし、機能はどの Service Worker がインストールされているか、 現在のページでアクティブな Service Worker をすべて手動で登録解除することもできます。 この方法は同じように役立ちますが、ローカルの開発サイクルでより多くの手作業が必要になります。

シフトして再読み込み

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

注: ヒント: このキーボードのみのバリエーションでは、 <kbd>Shift</kbd>、<kbd>Cmd</kbd>、<kbd>R</kbd>macOS マシン、および <kbd>Shift</kbd>、<kbd>Ctrl</kbd>、<kbd>R</kbd>実行できます。

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

注意: 強制更新が Service Worker をバイパスするのは 1 回のみで、後続のリクエストでバイパスされることはありません。 強制更新によって開始されていない次のナビゲーション リクエストで、Service Worker が再び制御を取得します。

この機能は、特定のキャッシュ戦略が意図したとおりに機能しているかどうかが不明な場合に役立ちます。 ネットワークからすべてを取得して、Service Worker の有無による動作を比較できます。 しかも、これは特定の動作なので、Service Worker をサポートするすべてのブラウザで、その動作が監視されます。

キャッシュの内容を検査する

キャッシュを検査できない場合、キャッシュ戦略が意図したとおりに機能しているかどうかを見分けるのは困難です。 キャッシュはコードで検査でき このタスクには、デバッガや console ステートメントを使用するのがよいでしょう。 Chrome DevTools の [Application] パネルには、Cache インスタンスの内容を検査するサブパネルがあります。

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

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

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

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

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

ストレージ容量の管理は、Service Worker の開発の一環として行います。 自分で管理するよりも簡単です ただし、Workbox の有無にかかわらず、カスタムの保存容量をシミュレートしてキャッシュ管理ロジックをテストすることをおすすめします。

<ph type="x-smartling-placeholder">

</ph>

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

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

なお、このサブパネルには [サイトデータを消去] ボタンと、そのボタンがクリックされたときに解除する項目に関連する一連のチェックボックスも含まれています。 これらのアイテムには、開いている Cache インスタンス、ページを制御しているアクティブな Service Worker の登録を解除できる機能が含まれます。

開発が容易になり、生産性が向上

開発者の負担が軽減されると、より自信を持って作業できるようになり、生産性が向上します。 Service Worker によるローカルでの開発は微妙に異なる場合がありますが、必ずしも手間がかかるものではありません。 これらのヒントを参考にすると、アクティブな Service Worker での開発の透明性と予測可能性が大幅に向上します。 開発者エクスペリエンスが向上します