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

バグのある Service Worker の削除

バグのある Service Worker がデプロイされ問題が発生します。たとえば、Service Worker が登録時に解析され、インストールが正常に完了する場合があります。ただし、fetch イベント内のバグのあるコードが原因でリクエストに応答しない場合があります。空白のページが返されますまた、ページのマークアップが積極的にキャッシュされていることも考えられます。また、Service Worker は、それ以降のアクセスに対して Cache インスタンスから古いマークアップレスポンスのみを返します。

Service Worker はさまざまな原因で本番環境用ウェブサイトには恐ろしい問題ですそれでも、すべてが失われません。問題を解決して元の状態に戻す方法はいくつかあります。

NoOps Service Worker をデプロイする

通常、バグのある Service Worker に対処するには、基本的な fetch イベントハンドラなしですぐにインストールして有効化する no-op Service Worker:

// sw.js

self.addEventListener('install', () => {
  // Skip over the "waiting" lifecycle state, to ensure that our
  // new service worker is activated immediately, even if there's
  // another tab open controlled by our older service worker code.
  self.skipWaiting();
});

self.addEventListener('activate', () => {
  // Optional: Get a list of all the current open windows/tabs under
  // our service worker's control, and force them to reload.
  // This can "unbreak" any open windows/tabs as soon as the new
  // service worker activates, rather than users having to manually reload.
  self.clients.matchAll({
    type: 'window'
  }).then(windowClients => {
    windowClients.forEach((windowClient) => {
      windowClient.navigate(windowClient.url);
    });
  });
});

この Service Worker は、 install イベントの self.skipWaiting()。必要に応じて、activate イベントに追加のコードをデプロイし、Service Worker が制御している WindowClient を使用して、他の開いているタブを強制的に再読み込みできます。

NoOps Service Worker に fetch イベントハンドラが含まれていないことは非常に重要です。 Service Worker がリクエストを処理していない場合これらのリクエストは、Service Worker が存在しないかのようにブラウザに渡されます。 NoOps Service Worker をデプロイしたら、バグのある Service Worker を修正し、後でアップデートとしてデプロイできます。

このアプローチがうまく機能するのは、ブラウザが HTTP キャッシュに Service Worker を配置しないようにする強固な安全保護対策を備えており、Service Worker のコンテンツの更新をバイト単位でチェックするためです。これらのデフォルトにより、バグのある Service Worker に NoOps の代替をデプロイして、問題を迅速に解決できます。

追加の対策を講じる

NoOps Service Worker をデプロイするだけで、バグのある Service Worker を無力化できます。必要に応じて追加の対策を講じることができます

古い Service Worker の URL が不明な場合はどうすればよいですか？

以前にインストールした Service Worker の URL が不明な場合があります。これは、バージョンがバージョニングされていること（ファイル名にハッシュが含まれているなど）が原因として考えられます。この場合、登録されている可能性のある各古い Service Worker の URL に一致する NoOps の Service Worker をデプロイすることは困難です。これはベストプラクティスに反しています。デプロイしたすべての Service Worker バージョンのすべてのハッシュをデベロッパーが記憶しているわけではないからです。

幸いにも、Service Worker スクリプトのリクエストとともに、有用な HTTP リクエストヘッダーが送信されます。 Service-Worker。ウェブサーバーでこのヘッダーを確認し、リクエストをインターセプトして NoOps Service Worker を提供します。これを実現する方法は、使用するウェブサーバーとバックエンドスタックによって異なります。方法については、該当する言語のドキュメントをご覧ください。

今後の Service Worker のデプロイでは、バージョニングされていないアセット名を使用します（例: sw.js）。そうすれば後でかなり複雑になります。

`Clear-Site-Data` ヘッダーを設定する

一部のブラウザでは、オリジンに対するすべての Service Worker の登録を解除します。値が 'storage' の Clear-Site-Data レスポンスヘッダーが設定されます。ただし、この方法では注意すべき点がいくつかあります。

この操作を行うと、関連付けられているオリジンのすべてのストレージがクリアされるため、注意が必要です。これには、localStorage、IndexedDB、sessionStorage、その他のストレージが含まれます（送信元の HTTP キャッシュは含まれません）。
このヘッダーは一部のブラウザではサポートされていません。

このヘッダーのサポートは完全ではないため、それだけで問題を解決することはできません。そのため、NoOps Service Worker のデプロイに加えて、Clear-Site-Data も行うことをおすすめします。

損傷が永続的ではない

バグのある Service Worker によってユーザーエクスペリエンスが妨げられた場合、恐ろしいことでしょう。特に大規模で有名なウェブサイトの場合、そのダメージは一時的で元に戻せません。

この状況を解決するために NoOps Service Worker をデプロイする必要がある場合は、問題を正確に把握するために時間を費やす必要があります。今後は、想定されたリクエストのみを Service Worker で処理するようにしてください。ステージング環境では頻繁にテストし、自信がある場合にのみ更新をデプロイする。