Service Worker は、基本的にウェブアプリケーション、ブラウザー、そして（もし繋がっていれば）ネットワークの間に介在するプロキシサーバーのように振る舞います。これは、よりよいオフライン体験を可能にするように意図されており、ネットワークのリクエストに介在してネットワークの使用可否の状況に基づいて適切な対応を取ったり、サーバー上にあるアセットを更新したりします。また、プッシュ通知やバックグラウンド同期の API 群へのアクセスもできるようになります。
Service Worker は、あるオリジンとパスに対して登録されたイベント駆動型の worker です。JavaScript ファイルの形を取り、ナビゲーションやリソースへのリクエストを横取りや改変したり細かい粒度でリソースをキャッシュすることで関連付けられたウェブページやサイトを制御し、それぞれの状況（もっとも顕著な例は、ネットワークが利用できないとき）にアプリがどのように振舞うかを完全に制御することができます。
Service Worker は worker のコンテキストで実行されます。従って、DOM へアクセスすることができず、アプリを実行する主要な JavaScript とは異なるスレッドで実行されるため、他のタスクをブロックすることはありません。完全に非同期で設計されています。そのため、同期型の XHR や localStorage のような API を Service Worker で利用することはできません。
Service worker はセキュリティ上の理由から、HTTPS 通信でのみ動作します。ネットワークリクエストが改変されると、中間者攻撃を受けるので、人間に広く開かれているのは本当にまずいことです。Firefox ではプライベートブラウジングモードで Service Worker API を利用することはできません。
メモ: Service Worker は AppCache のような、この分野における以前の試みより勝っています。以前のものは、あなたがしようとしていることを想定していなかったり、想定が正しくなかったときに壊れたりしていたのに対して、Service Worker はあなたがすべてを細かく制御することができるためです。
メモ: Service Worker は promise を頻繁に使用して、応答が来るのを待ってから、成功または失敗のアクションで応答します。promise のアーキテクチャはこの領域に対して理想的なものです。
Service Worker は最初に {{DOMxRef("ServiceWorkerContainer.register()")}} メソッドを使って登録されます。成功したら、Service Worker がクライアントにダウンロードされ、ユーザーがアクセスした URL のオリジン内全体、または指定したそのサブセット内に対してインストールと有効化（下記参照）が試みられます。
この段階で、Service Worker は以下のライフサイクルで実行されます。
ユーザーが最初に Service Worker が制御するサイトやページにアクセスすると、Service Worker が直ちにダウンロードされます。
その後、次の場面で更新されます。
ダウンロードしたファイルが新しいと分かった場合、既存の Service Worker とバイト単位に比較して異なっていた場合や、そのページやサイトで最初の Service Worker が見つかった場合は、インストールが試みられます。
Service Worker が初めて有効化されるときであれば、インストールが試みられ、インストールに成功した後で、有効化されます。
利用できる既存の Service Worker があった場合は、新しいバージョンがバックグラウンドでインストールされますが、まだ有効化 (activate) されません。この時点のものを待機中の (waiting) ワーカーと呼びます。まだ使用している古い Service Worker が読み込んでいるページがなくなった時のみ、有効化されます。ページが読み込まれなくなったらすぐに、新しい Service Worker が有効化されます（アクティブワーカーになります）。{{DOMxRef("ServiceWorkerGlobalScope.skipWaiting()")}} を使用するとすぐに有効化することができ、{{DOMxRef("Clients.claim()")}} を使用してアクティブワーカーが既存のページの管理を始めることができます。
{{DOMxRef("InstallEvent")}} を受け取ることもできます。イベントが発火したときの標準的なアクションは、使用するために Service Worker を準備すること、例えば組込みストレージ API を使用してキャッシュを構築したり、アプリがオフラインの時に使用したい資産をその中に配置したりすることです。
activate イベントもあります。このイベントが発火した時点は、古いキャッシュや、前のバージョンの Service Worker に関するその他のものを整理するのによいタイミングです。
Service Worker は {{DOMxRef("FetchEvent")}} イベントを使用してリクエストに応答することができます。{{DOMxRef("event.respondWith") }} メソッドを使用して、これらのリクエストに対するレスポンスを何でも思うように変更できます。
メモ: oninstall/onactivate は完了するまでに時間がかかる可能性があるため、Service Worker の仕様書では waitUntil メソッドを提供しており、これが oninstall 又は onactivate を呼び出すと、promise を渡します。promise が正常に解決されるまで、関数イベントは Service Worker に配信されません。
最初の基本的な例をどのように構築するかについての完全なチュートリアルは、Service Worker の使用を読んでください。
Service Worker は次のようなことにも利用されることを想定しています。
近い将来、Service Worker はネイティブアプリで実現できることに近い、その他いくつもの便利なことを、ウェブプラットフォーム上でも実現する事ができるようになるでしょう。興味深いことに、次のような他の仕様書でも、Service Worker のコンテキストを利用できるようになってきています。
install イベントや activate イベントのライフタイムを伸ばします。これは、データベーススキーマの更新や使われなくなったキャッシュエントリの削除などが終わるまで機能的イベント (Functional events) が {{DOMxRef("ServiceWorker")}} にディスパッチされないことを保証します。FetchEvent represents a fetch action that is dispatched on the {{DOMxRef("ServiceWorkerGlobalScope")}} of a {{DOMxRef("ServiceWorker")}}. It contains information about the request and resulting response, and provides the {{DOMxRef("FetchEvent.respondWith", "FetchEvent.respondWith()")}} method, which allows us to provide an arbitrary response back to the controlled page.InstallEvent interface represents an install action that is dispatched on the {{DOMxRef("ServiceWorkerGlobalScope")}} of a {{DOMxRef("ServiceWorker")}}. As a child of {{DOMxRef("ExtendableEvent")}}, it ensures that functional events such as {{DOMxRef("FetchEvent")}} are not dispatched during installation.NotificationEvent interface represents a notification click event that is dispatched on the {{DOMxRef("ServiceWorkerGlobalScope")}} of a {{DOMxRef("ServiceWorker")}}.ServiceWorker object.ServiceWorker の状態に関連付けられています。SyncEventインターフェイスはService Workerの{{DOMxRef("ServiceWorkerGlobalScope")}}でディスパッチされた同期アクションを表します。
| 仕様書 | 状態 | 備考 |
|---|---|---|
| {{SpecName("Service Workers")}} | {{Spec2("Service Workers")}} | 初回定義。 |