Service Worker は「リッチなオフライン体験」を提供することができる比較的新しい JavaScript APIです。
これを使えば、たとえばネットワークに繋がらない時、通常現れる恐竜の代わりにカスタマイズしたページを表示させることができるようになります。
必要な知識
Service Worker は難易度が高い分野です。少なくとも次のスキルが求められます。
- HTML、CSS、JavaScript や HTTP 通信などウェブ技術の基本的な理解があること
- JavaScript の Promise の使い方を知っていること
- ブラウザの開発者ツールを扱うことができること
Service Worker 概要
Service Worker は、WebブラウザがWeb ページとは別にバックグラウンドで実行する、アプリケーションのキャッシュを管理するスクリプトです。 HTMLで参照されるリソースや、最初のindex.html
へのリクエストでさえもキャッシュ可能で、サーバー指定のキャッシュヘッダーに依存しません。
Service Worker を活用すればユーザー体験を大幅に向上させることができます。
特徴
- Service worker は、JavaScript の Worker の一種です。そのため、メインスレッドから独立したスレッドで実行されます。
- HTTPS 通信を前提としています。HTTP通信では使用できません。
- Promise を多用します。予め Promise の扱いに慣れておきましょう。
- 1つの Service Worker で複数のページを制御することができます。逆に、それぞれのページは独自の Service Worker を持ちません。
- Service Worker は使用されていない間は終了していて、必要なときになったら起動します。異なるライフサイクル間でデータを共有したい場合は、IndexedDB を使用します。
できること
- ブラウザのオフライン画面(Chromeなら恐竜)を表示させないようにする(カスタムオフラインページ)
- 位置情報やジャイロスコープのような計算コストの高いデータの更新を集中的に受信して、複数のページがデータの一部を利用できるようにすること
- 特定のURLパターンに基づくテンプレートのカスタマイズ
- ユーザーが近く必要になるであろうデータの先読み
- バックグランドのデータ同期
できないこと
- DOMへのアクセス
- HTTPでの使用
- 同期型の XHR やlocalStorage のようなAPIの使用
ブラウザーのサポート状況
Internet Explorer でのサポートはありません。Safari や Edge のサポートが乏しかったのですが、Safari はバージョン11.1から、Edge はバージョン17から十分なサポートにあるようです。
詳しくは、Jake Archibaldの Is Serviceworker ready? や Can I Use で確認できます。
一連の流れ
- navigator.serviceWorker.register() で Service Worker の登録を行う
- 成功すると、メインスレッドから独立している
ServiceWorkerGlobalScope
で実行される - インストールが試みられ、完了すると、ページ読み込みが起こった後に Service Worker が有効化される
- この時点で Service Worker はページを制御しているため、リクエストを受け取るたびにキャッシュを返すなどの処理を行うことができる
Service Worker の登録
- if ('serviceWorker' in navigator) {
- window.addEventListener('load', function() {
- navigator.serviceWorker.register('/sw.js')
- .then(function(registration) {
- // 登録成功
- console.log('ServiceWorker 登録成功: ', registration.scope);
- })
- .catch(function(err) {
- // 登録失敗 :(
- console.log('ServiceWorker 登録失敗: ', err);
- });
- });
- }
まず、Service Worker API が利用可能かチェックします。
- if ('serviceWorker' in navigator) {
利用可能であれば、ページを読み込む時に JavaScript ファイルである Service Worker /sw.js
を、ServiceWorkerContainer.register()
で登録します。これは、ページが読み込まれる度に行いますが、実際に登録が行われるかはブラウザが自動でうまいことやってくれるので心配はいりません。
- window.addEventListener('load', function() {
- navigator.serviceWorker.register('/sw.js')
ここで注意点があって、この例ではドメインのルートに sw.js
があるので、この Service Worker はこのドメインのすべての fetch
イベントを受け取ります。つまり、Service Worker ファイルのある場所がそのまま Service Worker のスコープになります。もし /sub/sw.js
としたら、Service Worker は、ページのURLが /sub/
から始まるもののみの fetch
イベントを受け取ります。これは、デフォルトの動作であり、Service Worker ファイルとは異なる階層をスコープにしたいのなら、次のように scope
オプションで指定します。
scope オプションを指定する場合:
- navigator.serviceWorker.register('/sw.js', {scope: '/sub/'})
register()
メソッドは Promise を返すので、成功の場合と失敗の場合の処理をメソッドチェーンで記述します。
- .then(function(registration) {
- // 登録成功
- console.log('ServiceWorker 登録成功: ', registration.scope);
- })
- .catch(function(err) {
- // 登録失敗 :(
- console.log('ServiceWorker 登録失敗: ', err);
- });
Service Worker のインストール
ここからは Service Worker スクリプトに移ります。
Service Worker の登録が終わると、ブラウザーは Service Worker をインストールしようします。この時に発火するのが install
イベントです。このイベントのコールバックにキャッシュしたいアセットを指定します。まず、コールバックの書き方です。
- self.addEventListener('install', function(event) {
- event.waitUntil(
- // インストールステップ
- );
- });
ここで、見慣れないものが2つ出てきましたね。
まず self
ですが、これはService Worker のグローバル実行コンテキストです。Service Worker 版 window
といったところです。そしてwaitUntil()
メソッドは、内部の処理が成功(resolve)するまでは Service Worker がインストールされないことを保証する記述です。
続いて、インストールステップの内容を付け加えます
- self.addEventListener('install', function(event) {
- event.waitUntil(
- caches.open('cache-v1')
- .then(function(cache) {
- return cache.addAll([
- '/',
- '/styles.css',
- 'app.js',
- '/images/default.png'
- ]);
- })
- );
- });
caches.open()
メソッドは、任意のキャッシュ名を引数にとってコールします。解決(resolve)されると、パラメータとしてオープンしたキャッシを返すので、addAll()
メソッドにキャッシュしたいすべてのリソースのオリジン相対URLを配列で指定してコールします。これもまた成功または失敗の Promise を返します。
レスポンスを制御する
サイトのアセットはキャッシュされたので、リクエストに対してキャッシュのレスポンスを行えます。ここが一番やりたいと思える部分ではないでしょうか。
そのために新しいイベントである fetch
の登場です。Service Worker がインストールされた状態で、他のページヘ移動したりページを更新したりすると、Service Worker は fetch
イベントを受け取ります。
- self.addEventListener('fetch', function(event) {
- event.respondWith(
- caches.match(event.request)
- .then(function(response) {
- // キャッシュがあったのでレスポンスを返す
- if (response) {
- return response;
- }
- // キャッシュがなかったので通常の fetch を行う
- return fetch(event.request);
- }
- )
- );
- });
event.respondWith()
では、ブラウザー既定の fetch ハンドリングを抑止するはたらきがあり、引数にレスポンスの Promise を受け取ります。caches.match()
でキャッシュの確認を行って、 キャッシュがあればキャッシュを返し、なければ規程の fetch を行うように場合分けして使います。
ここまでの例では、キャッシュの作成はインストールの時に行うのみでした。しかし、後の要求がオフラインであるかもしれないことに備えてリクエストがある度にアセットをキャッシュに追加していきたいと思うでしょう。その場合は次のように、キャッシュがなかったときの fetch リクエストのレスポンスを取得してにキャッシュに追加します。
- // キャッシュがなかったので通常の fetch を行う
- // 重要:リクエストはストリームであり、1度しか読み取れないため複製します。
- // ブラウザーのフェッチに加え、キャッシュで使用するため2つ必要になります。
- var fetchRequest = event.request.clone();
- return fetch(fetchRequest)
- .then(
- function(response) {
- // 有効な応答を受信したかどうかを確認します
- if(!response || response.status !== 200 || response.type !== 'basic') {
- return response;
- }
- // 有効な応答を受信したようなので、キャッシュに追加していきます。
- // 重要:リクエストと同様の理由により、レスポンスも複製します。
- var responseToCache = response.clone();
- caches.open('cache-v1')
- .then(function(cache) {
- cache.put(event.request, responseToCache);
- });
- return response;
- }
- );
- }
- )
- );
- });
コメントに記載してありますが、リクエストとレスポンスはストリームであるので、読み取れるのは1度きりです。それぞれキャッシュ用に追加で1回使用するので .clone()
しています。リクエストは14行目と27行目、レスポンスは27行目と30行目で使用されています。
ここまでの例でかなり対応が柔軟になりましが、リクエストの際にアセットがキャッシュになく、それでいてネットワークがオフラインの場合は、リクエスト失敗の恐竜が現れてしまいます。
- self.addEventListener('fetch', function(event) {
- event.respondWith(
- caches.match(event.request)
- .then(function(response) {...})
- .catch(function() {
- return caches.match('/images/default.png');
- })
- );
- });
この '/images/default.png'
というのは、先の install
イベントで登録しておいたものです。
Service worker の更新
Service Worker が既にインストールされていて、ページの更新や読み込みが行われた時に新しいバージョンの Service worker が利用できる場合はバックグラウンドでインストールされます(起動はまだされません)。バージョンの異なるかどうかはバイトの差異で判断されます。インストールが完了した後でページの読み込みが発生すると新しいバージョンが起動されます。
新しい Service Worker がページを制御するようになると activate
イベントが起こります。このタイミングで不要になった古いキャッシュを削除することができます。
次の例では、’cache-v2′ 以外のキャッシュを削除します。削除には caches.delete()
を使います。
- self.addEventListener('activate', function(event) {
- var cacheKeeplist = ['cache-v2'];
- event.waitUntil(
- caches.keys().then(function(keyList) {
- return Promise.all(keyList.map(function(key) {
- if (cacheKeeplist.indexOf(key) === -1) {
- return caches.delete(key);
- }
- }));
- })
- );
- });
全体像
ここまでのコードの全体像を確認します。
まず、app.js
は、メインスレッドで実行される通常の JavaScript です。ページが読み込まれた際に実行され、ServiceWorker の登録を指示します。
- if ('serviceWorker' in navigator) {
- window.addEventListener('load', function() {
- navigator.serviceWorker.register('/sw.js')
- .then(function(registration) {
- // 登録成功
- console.log('ServiceWorker 登録成功: ', registration.scope);
- })
- .catch(function(err) {
- // 登録失敗 :(
- console.log('ServiceWorker 登録失敗: ', err);
- });
- });
- }
もう一方は ServiceWorker のコードです。メインスレッドからは独立して動作し、様々な処理を記述します。
- self.addEventListener('install', function(event) {
- event.waitUntil(
- caches.open('cache-v1')
- .then(function(cache) {
- return cache.addAll([
- '/',
- '/styles.css',
- 'app.js',
- '/images/default.png'
- ]);
- })
- );
- });
-
- self.addEventListener('fetch', function(event) {
- event.respondWith(
- caches.match(event.request)
- .then(function(response) {
- // キャッシュがあったのでレスポンスを返す
- if (response) {
- return response;
- }
- // キャッシュがなかったので通常の fetch を行う
- // 重要:リクエストはストリームであり、1度しか読み取れないため複製します。
- // ブラウザーのフェッチに加え、キャッシュで使用するため2つ必要になります。
- var fetchRequest = event.request.clone();
- return fetch(fetchRequest)
- .then(
- function(response) {
- // 有効な応答を受信したかどうかを確認します
- if(!response || response.status !== 200 || response.type !== 'basic') {
- return response;
- }
- // 有効な応答を受信したようなので、キャッシュに追加していきます。
- // 重要:リクエストと同様の理由により、レスポンスも複製します。
- var responseToCache = response.clone();
- caches.open('cache-v1')
- .then(function(cache) {
- cache.put(event.request, responseToCache);
- });
- return response;
- }
- );
- }
- )
- );
- });
-
- self.addEventListener('activate', function(event) {
- var cacheKeeplist = ['cache-v2'];
- event.waitUntil(
- caches.keys().then(function(keyList) {
- return Promise.all(keyList.map(function(key) {
- if (cacheKeeplist.indexOf(key) === -1) {
- return caches.delete(key);
- }
- }));
- })
- );
- });
開発で役に立つこと
- 有効になっている Service Worker を知るには、
chrome://inspect/#service-workers
にアクセスするとわかる(Chrome や Opera の場合) - テストはシークレットウインドウで行うといい。なぜなら、ウィンドウを閉じてから開けばそれまでの Service Worker の影響を受けないから。
ブラウザーの開発者ツールの [Application] タブには Sevice Worker の項目があります。