Service Worker は、ウェブサイトをオフラインで動作させ、独自の特別なキャッシュルールを作成するための強力なツールです。Service Worker の fetch ハンドラは、制御するページからのすべてのリクエストを認識し、Service Worker キャッシュからリクエストにレスポンスを提供するかどうかを決定できます。また、URL を書き換えて、ローカル ユーザー設定に基づいてまったく異なるレスポンスを取得することもできます。
ただし、ページが久しぶりに初めて読み込まれ、制御対象の Service Worker が現在実行されていない場合、Service Worker のパフォーマンスにコストが発生する可能性があります。すべての取得は Service Worker を介して行う必要があるため、ブラウザは Service Worker が起動して実行されるのを待ってから、読み込むコンテンツを把握する必要があります。この起動コストは小さいものの、サービス ワーカーを使用してキャッシュ戦略を通じてパフォーマンスを向上させるデベロッパーにとっては、大きなコストになる可能性があります。
ナビゲーションのプリロードは、この問題を解決する 1 つの方法です。Service Worker の起動と並行してネットワーク経由でナビゲーション リクエストを実行できますが、最初のナビゲーション リクエストに限定され、クリティカル パスに Service Worker が引き続き含まれます。ナビゲーション プリロードのリリース以降、サービス ワーカーの起動時に一部のリクエストがブロックされないようにする方法など、問題領域に対するより一般的なソリューションを開発するための取り組みが複数行われています。
Service Worker 静的ルーティング API
Chrome 116 以降では、試験運用版の Service Worker Static Routing API を使用して、このようなソリューションの最初のステップをテストできます。Service Worker がインストールされると、Service Worker 静的ルーティング API を使用して、特定のリソースパスを取得する方法を宣言的に指定できます。
API の初期バージョンでは、パスを常に Service Worker ではなくネットワークから提供するように宣言できます。後で制御対象の URL が読み込まれると、Service Worker の起動が完了する前に、ブラウザはこれらのパスからリソースの取得を開始できます。これにより、サービス ワーカーが必要ないことがわかっているパスからサービス ワーカーが削除されます。
API を使用するには、サービス ワーカーが、一連のルールを使用して 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 Pattern API を使用してリソースパスを照合し、ルールが適用されるタイミングを指定します。このプロパティには、URLPatternインスタンスまたは、URLPatternコンストラクタに渡すことに対応した同等のプレーン オブジェクトを指定できます（例:new URLPattern({pathname: '*.jpg'})または{pathname: '*.jpg'}）。URL パターンの柔軟性により、ルールはパス内の任意のリソースなどの単純なものから、非常に具体的で詳細な条件まで一致させることができます。一般に、これらのパターンは一般的なルーティング ライブラリのユーザーには馴染みがあるはずです。
source:conditionに一致するリソースの読み込み方法を指定します。現在、'network'値のみがサポートされています（サービス ワーカーをバイパスしてネットワーク経由でリソースを直接読み込みます）。今後は、これを他の値に拡張する予定です。
ユースケース
説明したように、API の初期バージョンは、一部のパスのサービス ワーカー制御からのエスケープ ハッチです。これを使用すべき場所は、サービス ワーカーの使用方法とユーザーがサイトを移動する方法によって異なります。
たとえば、サイトがキャッシュ優先戦略（ネットワークにフォールバック）を使用しているにもかかわらず、アクセス頻度が非常に低いコンテンツ（アーカイブされたコンテンツや RSS フィードなど）があり、キャッシュにヒットする価値がほとんどまたはまったくない場合です。これらのパスをネットワークからのみ取得するように制限することは、サービス ワーカーで設定できますが、サービス ワーカーは起動して実行し、これらのリクエストの処理方法を決定する必要があります。
一方、静的ルーティング 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 が進化するにつれて、この構成はより柔軟になり、ネットワーク取得とサービス ワーカーの起動を宣言的に競合させるなど、より多くのシナリオをサポートする予定です。詳細については、API の最終的な形態に関する仕様説明をご覧ください。
Service Worker の静的ルーティング API の試用
Service Worker Static Routing API は、Chrome バージョン 116 以降でオリジン トライアルとして利用できます。これにより、デベロッパーはサイト上で実際のユーザーを使用して API をテストし、効果を測定できます。オリジン トライアルの背景情報については、「オリジン トライアルの開始」をご覧ください。
ローカルテストでは、chrome://flags/#service-worker-static-router のフラグを使用して、または --enable-features=ServiceWorkerStaticRouter のようにコマンドから Chrome を実行して、Service Worker 静的ルーティング API を有効にできます。
フィードバックと今後の方向性
Service Worker 静的ルーティング API は現在も積極的に開発されており、まだ形作られています。有用と思われる場合は、オリジン トライアルで試し、API、実装、利用可能な機能に関するフィードバックをお寄せください。