Service Worker は、ウェブサイトをオフラインで動作させ、専用のキャッシュ ルールを作成できるようにするための優れたツールです。Service Worker の fetch ハンドラは、制御しているページからのすべてのリクエストを確認し、Service Worker のキャッシュからレスポンスを提供するかどうかを判断できます。また、URL を書き換えて、たとえばローカルのユーザー設定に基づく別のレスポンスを完全に取得することもできます。
ただし、ページがしばらく初めて読み込まれ、制御する Service Worker が現在実行されていない場合、Service Worker のパフォーマンス コストが発生することがあります。すべてのフェッチは Service Worker を介して行う必要があるため、ブラウザは Service Worker が起動して実行され、読み込むコンテンツを判別するまで待機する必要があります。Service Worker を使用してキャッシュ戦略のパフォーマンスを向上させる場合、この起動費用は少額ですが、多額になる場合があります。
ナビゲーションのプリロードは、問題を解決するためのアプローチの一つです。つまり、Service Worker の起動と並行してネットワーク経由でナビゲーション リクエストを行うことができます。ただし、これは最初のナビゲーション リクエストに限定され、クリティカル パスに Service Worker が含まれます。ナビゲーションのプリロードがリリースされて以来、問題空間の汎用的なソリューションを開発する取り組みが複数行われてきました。たとえば、Service Worker の起動時に一部のリクエストがまったくブロックされないようにする方法などです。
Service Worker Static Routing API
Chrome 116 以降では、試験運用版の Service Worker Static Routing API を使用して、このようなソリューションの最初のステップをテストできます。Service Worker をインストールすると、Service Worker Static Routing API を使用して、特定のリソースパスを取得する方法を宣言的に記述できます。
API の初期バージョンでは、パスが常に Service Worker ではなくネットワークから提供されるように宣言できます。制御対象 URL が後で読み込まれると、Service Worker の開始が完了する前に、ブラウザはこれらのパスからリソースの取得を開始できます。これにより、Service Worker が必要ないことがわかっているパスから Service Worker が削除されます。
API を使用するために、Service Worker は一連のルールを使用して install イベントの event.registerRouter を呼び出します。
self.addEventListener('install', event => {
if (event.registerRouter) {
// Go straight to the network and bypass invoking "fetch" handlers for all
// same-origin URLs that start with '/form/'.
event.registerRouter([{
condition: {
urlPattern: {pathname: '/form/*'},
},
source: 'network',
}]);
}
});
通常、各ルールには次の 2 つのプロパティがあります。
condition: URL パターン API を使用して、リソースパスを照合するためにルールを適用するタイミングを指定します。プロパティには、URLPatternインスタンス、またはURLPatternコンストラクタに渡されることと互換性のある同等のプレーン オブジェクト（たとえば、new URLPattern({pathname: '*.jpg'})または{pathname: '*.jpg'}）を指定できます。URL パターンには柔軟性があるため、ルールでは、パス内の任意のリソースのような単純なものから、非常に具体的で詳細な条件までマッチングできます。通常、これらのパターンは、一般的なルーティング ライブラリのユーザーにとってなじみがあるはずです。
source:conditionに一致するリソースを読み込む方法を指定します。現時点では'network'値のみがサポートされています（Service Worker をバイパスしてネットワーク経由でリソースを直接読み込むことはありません）。ただし、将来的にはこの値を他の値に拡張する予定です。
ユースケース
説明したとおり、API の初期バージョンは、基本的には、一部のパスを Service Worker で制御するための回避策です。これを使用する意味は、Service Worker の使用方法とユーザーがサイトをどのように移動するかによって異なります。
例としては、サイトでキャッシュ ファースト戦略（ネットワークにフォールバック）が採用されているものの、アクセス頻度が非常に低いコンテンツ（アーカイブ コンテンツや RSS フィードなど）がキャッシュにほとんどまたはまったく記録されない場合などがあります。これらのパスがネットワークからフェッチされるように制限することは、Service Worker でしか設定できませんが、それでも Service Worker は起動して実行し、リクエストの処理方法を決定する必要があります。
一方、静的ルーティング API は、いくつかの宣言行を使用して Service Worker を完全にバイパスします。
self.addEventListener('install', event => {
if (event.registerRouter) {
event.registerRouter([{
condition: {
urlPattern: {pathname: '/feeds/*.xml'},
},
source: 'network',
}, {
condition: {
urlPattern: {pathname: '/archives/*'},
},
source: 'network',
}]);
}
});
Service Worker Static Routing API の進化に伴い、この構成の柔軟性が向上し、ネットワーク フェッチや Service Worker の起動の宣言による競合など、より多くのシナリオに対応する予定です。詳しくは、仕様説明書の API の「最終形式」に関する調査をご覧ください。
Service Worker Static Routing API の試用
Service Worker Static Routing API は、オリジン トライアルの背後でバージョン 116 以降の Chrome で利用できます。これにより、デベロッパーは実際のユーザーを使用してサイトで API をテストして、その効果を測定できます。オリジン トライアルの背景情報については、オリジン トライアルを使ってみるをご覧ください。
ローカルテストでは、chrome://flags/#service-worker-static-router のフラグを使用するか、--enable-features=ServiceWorkerStaticRouter などのコマンドから Chrome を実行して、Service Worker Static Routing API を有効にできます。
フィードバックと今後の方向性
Service Worker Static Routing API は現在開発中で、開発中です。お役に立ちそうでしたら、オリジン トライアルでお試しいただき、API、実装、利用可能な機能に関するフィードバックをお送りください。