このページは Cloud Translation API によって翻訳されました。

命令型キャッシュガイド

Andrew Guan

Demián Renzulli

ウェブサイトによっては、結果を通知されることなくサービスワーカーと通信する必要がある場合があります。次に例を示します。

ページは、プリフェッチする URL のリストを Service Worker に送信します。これにより、ユーザーがリンクをクリックしたときに、ドキュメントまたはページのサブリソースがすでにキャッシュに存在するため、その後のナビゲーションが大幅に高速化されます。
ページは、一連のトップ記事を取得してキャッシュに保存し、オフラインで利用できるように Service Worker にリクエストします。

この種の重要でないタスクを Service Worker に委任すると、メインスレッドが解放され、ユーザー操作への応答など、より差し迫ったタスクをより適切に処理できるというメリットがあります。

キャッシュに保存するリソースを Service Worker にリクエストするページの図。

このガイドでは、標準のブラウザ API と Workbox ライブラリを使用して、ページからサービスワーカーへの一方向通信手法を実装する方法について説明します。このようなユースケースを「強制キャッシュ」と呼びます。

本番環境のケース

1-800-Flowers.com は、postMessage() を介してサービスワーカーで強制キャッシング（プリフェッチ）を実装し、カテゴリページのトップアイテムをプリフェッチして、商品の詳細ページへのその後のナビゲーションを高速化しました。

プリフェッチするアイテムを決定する方法は次のとおりです。

ページの読み込み時に、上位 9 個のアイテムの JSON データを取得し、結果のレスポンスオブジェクトをキャッシュに追加するよう、サービス提供者ワーカーに依頼します。
残りのアイテムについては、mouseover イベントをリッスンします。これにより、ユーザーがアイテムの上にカーソルを移動したときに、リソースの取得を「オンデマンド」でトリガーできます。

Cache API を使用して JSON レスポンスを保存します。

1-800Flowers.com の商品リスティングページから JSON 商品データをプリフェッチ。

ユーザーがアイテムをクリックすると、ネットワークにアクセスすることなく、アイテムに関連付けられた JSON データをキャッシュから取得できるため、ナビゲーションが高速化されます。

Workbox の使用

Workbox を使用すると、workbox-window パッケージ（ウィンドウコンテキストで実行することを目的とした一連のモジュール）を介して、サービスワーカーにメッセージを簡単に送信できます。これらは、サービスワーカーで実行される他の Workbox パッケージを補完するものです。

ページを Service Worker と通信するには、まず、登録済みの Service Worker への Workbox オブジェクト参照を取得します。

const wb = new Workbox('/sw.js');
wb.register();

その後、登録の取得、有効性の確認、基盤となる通信 API の考慮といった手間をかけることなく、宣言的にメッセージを直接送信できます。

wb.messageSW({"type": "PREFETCH", "payload": {"urls": ["/data1.json", "data2.json"]}}); });

Service Worker は、これらのメッセージをリッスンする message ハンドラを実装します。必要に応じてレスポンスを返すことができます。ただし、次のような場合は必要ありません。

self.addEventListener('message', (event) => {
  if (event.data && event.data.type === 'PREFETCH') {
    // do something
  }
});

ブラウザの API を使用する

Workbox ライブラリがニーズを満たしていない場合は、ブラウザ API を使用して、ウィンドウからサービスワーカーへの通信を実装する方法をご覧ください。

postMessage API を使用すると、ページからサービスワーカーへの一方向通信メカニズムを確立できます。

ページで Service Worker インターフェースの postMessage() が呼び出されます。

navigator.serviceWorker.controller.postMessage({
  type: 'MSG_ID',
  payload: 'some data to perform the task',
});

Service Worker は、これらのメッセージをリッスンする message ハンドラを実装します。

self.addEventListener('message', (event) => {
  if (event.data && event.data.type === MSG_ID) {
    // do something
  }
});

{type : 'MSG_ID'} 属性は必須ではありませんが、ページが Service Worker にさまざまなタイプの指示（「プリフェッチ」と「ストレージの消去」など）を送信できるようにする方法の一つです。サービスワーカーは、このフラグに基づいて異なる実行パスに分岐できます。

オペレーションが成功すると、ユーザーはオペレーションのメリットを享受できますが、失敗してもメインのユーザーフローは変更されません。たとえば、1-800-Flowers.com がプリキャッシュを試行する場合、ページは Service Worker が成功したかどうかを認識する必要はありません。対応している場合は、ユーザーはより速いナビゲーションを利用できます。そうでない場合は、引き続き新しいページに移動する必要があります。もう少し時間がかかります。

簡単なプリフェッチの例

命令型キャッシュの最も一般的な用途の 1 つは、プリフェッチです。これは、ナビゲーションを高速化するために、ユーザーが特定の URL に移動する前に、その URL のリソースを取得することを意味します。

サイトにプリフェッチを実装する方法はいくつかあります。

ページでリンクプリフェッチタグを使用する: リソースはブラウザキャッシュに 5 分間保持され、その後、リソースの通常の Cache-Control ルールが適用されます。
前述の手法を Service Worker のランタイムキャッシュ戦略で補完し、プリフェッチリソースの存続期間をこの上限を超えて延長します。

ドキュメントや特定のアセット（JS、CSS など）のプリフェッチなど、比較的シンプルなプリフェッチシナリオでは、これらの手法が最適なアプローチです。

内部 URL を取得するためにプリフェッチリソース（JSON ファイルまたはページ）を解析するなど、追加のロジックが必要な場合は、このタスクをサービスワーカーに完全に委任することをおすすめします。

このタイプのオペレーションを Service Worker に委任すると、次のようなメリットがあります。

フェッチとフェッチ後の処理（後述）の負荷をセカンダリスレッドにオフロードする。これにより、メインスレッドが解放され、ユーザー操作への応答などのより重要なタスクを処理できるようになります。
複数のクライアント（タブなど）が共通の機能を再利用できるようにし、メインスレッドをブロックすることなくサービスを同時に呼び出せるようにします。

商品の詳細ページをプリフェッチする

まず、Service Worker インターフェースで postMessage() を使用し、キャッシュに保存する URL の配列を渡します。

navigator.serviceWorker.controller.postMessage({
  type: 'PREFETCH',
  payload: {
    urls: [
      'www.exmaple.com/apis/data_1.json',
      'www.exmaple.com/apis/data_2.json',
    ],
  },
});

サービスワーカーで message ハンドラを実装して、アクティブなタブから送信されたメッセージをインターセプトして処理します。

addEventListener('message', (event) => {
  let data = event.data;
  if (data && data.type === 'PREFETCH') {
    let urls = data.payload.urls;
    for (let i in urls) {
      fetchAsync(urls[i]);
    }
  }
});

上記のコードでは、fetchAsync() という小さなヘルパー関数を導入して、URL の配列を反復処理し、各 URL に対して取得リクエストを発行しています。

async function fetchAsync(url) {
  // await response of fetch call
  let prefetched = await fetch(url);
  // (optionally) cache resources in the service worker storage
}

レスポンスが取得されたら、リソースのキャッシュヘッダーを使用できます。ただし、商品の詳細ページなどでは、多くの場合、リソースはキャッシュに保存されません（つまり、no-cache の Cache-control ヘッダーがあります）。このような場合は、フェッチしたリソースをサービスワーカーキャッシュに保存することで、この動作をオーバーライドできます。これには、オフラインのシナリオでもファイルを提供できるという利点もあります。

JSON データ以外

JSON データがサーバーエンドポイントから取得されると、多くの場合、この第 1 レベルのデータに関連付けられている画像やその他のエンドポイントデータなど、プリフェッチ価値のある他の URL が含まれます。

この例では、返される JSON データが食料品店サイトの情報であるとします。

{
  "productName": "banana",
  "productPic": "https://cdn.example.com/product_images/banana.jpeg",
  "unitPrice": "1.99"
 }

fetchAsync() コードを変更して、商品のリストを反復処理し、各商品のヒーロー画像をキャッシュに保存します。

async function fetchAsync(url, postProcess) {
  // await response of fetch call
  let prefetched = await fetch(url);

  //(optionally) cache resource in the service worker cache

  // carry out the post fetch process if supplied
  if (postProcess) {
    await postProcess(prefetched);
  }
}

async function postProcess(prefetched) {
  let productJson = await prefetched.json();
  if (productJson && productJson.product_pic) {
    fetchAsync(productJson.product_pic);
  }
}

404 などの状況に備えて、このコードの周囲に例外処理を追加できます。ただし、サービスワーカーを使用してプリフェッチを行うメリットは、ページとメインスレッドに大きな影響を与えることなく失敗できることです。また、プリフェッチされたコンテンツの後処理でより複雑なロジックを使用して、柔軟性を高め、処理するデータと分離することもできます。扱う内容に制限はありません。

まとめ

この記事では、ページとサービスワーカー間の一方向通信の一般的なユースケースである強制キャッシュについて説明しました。ここで説明する例は、このパターンを使用する 1 つの方法を示すことのみを目的としています。同じアプローチは、オフラインでの使用、ブックマークなどのために人気記事をオンデマンドでキャッシュに保存するなどの他のユースケースにも適用できます。

ページと Service Worker のその他の通信パターンについては、以下をご覧ください。

ブロードキャストアップデート: Service Worker からページを呼び出して、重要なアップデート（新しいバージョンのウェブアプリが利用可能になったなど）を通知します。
双方向通信: サービスワーカーにタスク（負荷の高いダウンロードなど）を委任し、ページに進行状況を通知します。