サービスワーカーとは何か、考えていますか？ あなただけではありません！
サービス ワーカーは、バックグラウンドで、ブラウザ UI とは別のスレッドで実行されるスクリプトです。 サービス ワーカーのキャッシュにより、Web サイトがオフラインで機能することが可能になります。 サービス ワーカーは、Web サイトをプログレッシブ Web アプリにレベルアップさせる技術的な強者です。 リッチなキャッシュ、プッシュ通知、バックグラウンド同期など、深いプラットフォーム統合を可能にします。
Service Worker は拡張可能なプラットフォームとして設計されており、現在、追加機能が計画されています。 これにより、開発者はリクエストがどのように処理されるかを制御する機会が得られ、Web サイトをオフラインで動作させるための豊富な方法を提供できます。 なぜなら、多くの必要とされる機能を実現し、私が長年使用してきたコア アーキテクチャをネイティブにするからです。
Service Workers は素晴らしい響きです！
Progressive Web アプリケーションの背後にあるキーテクノロジーまたは最新の Web API は、これです。 サービス ワーカーがなければ、Web サイトは単なる Web サイトに過ぎませんが、サービス ワーカーを追加すると、アプリケーションになります。
理解すべきサービス ワーカーの主な特徴がいくつかあります。
- A Service Worker is a JavaScript File
- UI とは別のスレッドで実行する
- DOM に直接アクセスできない
- サービス ワーカーにはライフサイクルまたはアクティブになるまでの一連のイベントがあり、後で説明します
- 使用中のみライブである
- サービス ワーカーが使用されている間は、アプリケーションを実行できない
- サービス ワーカーが使用中の場合、アプリケーションは実行できない
- サービス ワーカーは、登録されたオリジンまたはドメインに隔離される
- サービス ワーカーには HTTPS が必要
- UI との間でメッセージを送信できる
- 機能するのに Web ページが開いていなくてもよい
- すべての主要ブラウザによってサポートされています。 iOS の Safari を含む
- Web Workers に似ていますが、多くの点で優れています
- サービス ワーカーが使用中の場合は、アプリケーションを実行できない
- Service Workers はどのように動作しますか？
- Service Worker Extensibility
- Service Worker Life Cycle
- Service Workers の寿命はどのくらいですか？
- Service Worker が登録されているかどうか確認するにはどうすればよいですか？
- サービスワーカーの登録を解除するにはどうすればよいですか。
- サービスワーカーのキャッシュ
- サービスワーカーのキャッシュを更新するにはどうすればよいですか。
- どのブラウザがサービスワーをサポートしていますか。
- Service Worker と Web Worker の違い
- Service Worker にできないこと
サービスワーカーはどのように動作するか？
サービスワーカーはブラウザとネットワークの間に位置し、プロキシサーバーのように動作して非UI中心のタスク群を扱います。 サービス ワーカーはイベント駆動型で、ブラウザ プロセスの外側で動作するため、アクティブなブラウザ セッションなしで動作することができます。 サービスワーカーは、UI とは別のスレッドで実行されるスクリプトです。
Service Worker は使用しないときは終了し、必要なときに復元されるので、CPU に負荷をかけたりバッテリーを消耗させることがありません。 サービス ワーカーはブラウザとネットワークの間のプログラム可能なネットワーク プロキシ、または仲介者として機能し、開発者がネットワーク リクエストを処理する方法を設計できるようにします。 これは、豊富なキャッシュ API と、すべてのネットワーク リクエストを送信前にインターセプトすることで実現されます。
キャッシュはオフライン体験を可能にするだけでなく、キャッシュから取得したときに Web サイトを瞬時にロードすることができます。 サービス ワーカーのキャッシュにより、ネットワークはプログレッシブな強化になり、サイトを使用可能にするために必要なものではなくなります。 ブラウザで出荷されている最初の 2 つの機能は、ネイティブのプッシュ通知とバックグラウンド同期です。 さらに多くの新しい API が現在議論されており、近い将来、ブラウザに現れ始めるでしょう。
サービス ワーカーは独自のスレッドに住み、DOM にアクセスしません。 また、独自のグローバル スコープを持ち、「self」オブジェクトを使用して参照されます。
また、サイトが HTTPS を使用して提供される必要があります。 この要件は、サービスワーカーが提供する強力な機能によるものです。 HTTPS は多くの一般的な攻撃を防止します。 今日、すべてのサイトは HTTPS を使用して提供されるべきです。実装の障壁が取り除かれ、最小限のセキュリティが提供されるからです。 これは、すべての API がプロミスをサポートすることを意味します。 これは、特定の API や関数がサービス ワーカーでアクセスできないことも意味します。 最も顕著なのは localStorage です。
Service Worker Life Cycle
これらの優れたサービス ワーカー機能に飛び込む前に、開発者はライフ サイクルを理解する必要があります。 一部のブラウザはまだサービス ワーカーをサポートしていないため、サービス ワーカーを登録する前に機能チェックを実行する必要があります。 これは、navigator.
if ('serviceWorker' in navigator) { navigator.serviceWorker.register('/sw.js') .then(function(registration) { // Registration was successful }) .catch(function(err) { // registration failed :( }); } で ‘serviceWorker’ の存在を確認することで行われます。サービスワーカーを登録するには、 navigator.serviceWorker.register を呼び出してください。 サービスワーカーへのパスを渡します。
成功した場合、プロミスはサービスワーカー登録オブジェクトへの参照を返します。
Standard Service Worker Events
- install
- activate
- fetch
- push (Safari では未サポート)
- sync (ほとんどのブラウザで未サポート)
サービスワーカーが「インストール」イベントを登録された場合、サービスワーカーはこのイベントに参加できます。 このイベントで実行する最も一般的なタスクは、プリキャッシングと呼ばれます。
プリキャッシングとは、ページまたはサイトを形成するために必要な資産ファイルの事前定義されたリストを作成し、それらが要求される前にキャッシュに追加することを指します。 これは、これらの応答を持続させるためにサービス ワーカー キャッシュを利用します。
self.addEventListener("install", event => { event.waitUntil( caches.open(preCacheName) .then(function (cache) { return cache.addAll(precache_urls); }) ); }); インストール イベントは、サービス ワーカーのライフタイムで 1 回のみトリガーされます。
登録のライフサイクルの一部として発生する次のイベントは、「activate」です。 サービスワーカーがインストールされたとき、すぐにアクティブになるわけではありません。
サービスワーカーがすぐに引き継がないように設計されている理由は、ユーザー エクスペリエンスを破壊しないようにするためです。
self.skipWaiting(); 
サービスワーカーがアクティブになると、「activate」 イベントが発生します。 たとえば、新しいサービス ワーカーのキャッシュと競合する可能性のあるレガシー キャッシュを削除します。
How Long to Service Workers Last?
ブラウザがサービス ワーカーの実行を維持する時間について、明確なルールはありません。
一般に、Web ページが休止状態の場合、プロセスは 1、2 分後にスピンダウンし、早ければ 30 秒後に終了します。
良い知らせは、サービス ワーカーをオンにするのにわずか数ミリ秒しかかからないということです。 これは非常に高速であるため、遅延に気づくことはありません。 また、サービス ワーカーなしのシナリオに対処するために特別なプログラムを作成する必要はなく、サイトはそのまま機能します。 1540>
Service Worker が登録されているかどうかを確認する方法 Service Worker が登録されているかどうかを確認するには複数の方法があります。
navigator.serviceWorker.getRegistrations().then(registrations => { console.log(registrations); });
navigator.serviceWorker.getRegistrations().then(registrations => { console.log(registrations); });
これは、テクニカル サポートまたは開発者のデバッグのために登録を記録するために、ページ スクリプトに追加できるコードです。
もし、コンソールに登録を記録するだけなら、Dev Tools の ‘Application’ タブを見る方がよいでしょう。 これは、オリジンの登録されたサービスワーカーのビジュアルを表示するサブパネルがあります。 また、バックグラウンド同期イベントをトリガーし、プッシュ通知をテストできます。
また、サービス ワーカーの削除、強制更新、その他開発に役立つ一般的な管理もできます。 リモートで誰かを助けようとしても、問題のトラブルシューティングを行うために DevTools にアクセスできないことがどのようなことか、私たちは皆知っています。 時には、アプリケーションの状態に関する情報を提供するために、ある種の視覚的なサポート ページまたはモーダルが必要になるでしょう。
一般消費者は、DevTools コンソール パネルにアクセスする方法を知らないでしょう。
How do I Unregister a Service Worker
願わくば、サービス ワーカー コードがユーザー体験のバグを作成したシナリオに遭遇しないようにしてください。
サービス ワーカーを削除する必要があるほとんどのシナリオは、アプリケーションを開発しているときです。 この場合、DevTools を使用して、サービス ワーカーを削除または削除できます。
展開されたサービス ワーカーを削除する必要がある場合は、少し難しくなります。
削除テクニックの詳細については、こちらを参照してください。 これは、作成以来、多くの管理問題を引き起こしてきた従来の appCache を置き換えるものです。 キャッシュ API は、一致するリクエストによってクエリできるネットワーク応答を格納する永続層を提供します。 このイベントは各ネットワーク リクエストに対してトリガーされ、リクエストを傍受し、ネットワークに行く前に応答がキャッシュされているかどうかをチェックすることができます。 これは、ネットワークがないとき、オフラインのとき、またはネットワークの接続性が悪いとき、低いバーまたは偽の携帯電話接続 (LiFi として知られている) でサイトが機能できることを意味します。
self.addEventListener("fetch", event => { event.respondWith( fetchFromCache(event) .catch(() => fetch(request) .then(response => addToCache(cacheKey, request, response)) .catch(() => offlineResponse(resourceType, opts)) ) ); }); 上記の例では、コードは応答が以前にキャッシュされたかどうかをチェックします。 もしそうなら、キャッシュされた応答が返されます。
要求が戻ると、応答はキャッシュされ UI に返されます。
ネットワークが失敗すると、論理はオフライン応答へとフォールバックされます。
How do I Update My Service Worker Cache
A common misconception is once you cache a network request it is stored for eternity.
一度ネットワーク要求をキャッシュすると、それは永遠に保存されます。 これは事実ではありません。 キャッシュがいつ、どのように無効化され、更新されるかを完全に制御できます。 私は個人的に約 3 ダースのキャッシュ戦略を詳述できると思いますが、すべてキャッシュの無効化または更新を管理する方法を伴います。
無効化の鍵は、無効化する時間 (time to live) 値、マニフェスト、またはバックグラウンド更新プロセスのいずれかを決定することだと思います。 後者では、レスポンスがキャッシュされた時間に対して last-updated ヘッダー値を比較することにより、サーバー上で更新が行われたかどうかを確認するために HEAD リクエストを作成することができます。
どのブラウザーがサービスワーカーをサポートしていますか
すべてのモダンなブラウザーは、少なくともキャッシュを含むサービスワーカーをサポートしています。 Chrome、FireFox、および Edge はネイティブのプッシュ通知をサポートし、Chrome と Edge はバックグラウンド同期をサポートしています。
これは、PWA のコア機能がすべてのデバイスとブラウザーで利用可能であることを意味します。 プッシュとバックグラウンド同期は拡張機能です。
私たちは、iOS でもアプリケーションがオフラインで動作するように、高度なオフライン キャッシュ戦略を必要とするいくつかの Progressive Web Apps を構築してきました。 これらのアプリケーションでは、POST、PUT、および DELETE アクションであっても、すべてのリクエストがキューにキャッシュされる必要があります。
Service Worker と Web Worker の違い
Service Worker と Web Worker は類似したツールです。 どちらもユーザー インターフェイスから別のスレッドでプロセスを実行します。 本当の違いは、実際の使用コンテキストにあります。
どちらも DOM またはウィンドウ オブジェクトにアクセスすることはありません。 Web ワーカーは、Web ページが開いていて、ページ内のスクリプトからタスクがトリガーされたときのみ実行されます。
Service Worker もページが開いているときに実行できますが、プッシュ通知のようなプラットフォーム イベントによってトリガーされる場合もあります。 サービスワーカーが実行するために Web ページが開いている必要はありません。
サービスワーカーは、ネットワークとユーザー インターフェイスの間のプロキシとして機能します。 ページが使用されている場合 (最も一般的なシナリオ)、キャッシュのセクションで学んだように、すべての HTTPS ネットワーク リクエストはサービス ワーカーを通過します。
UI と両方のワーカーの間の通信は、postMessage メソッドと message イベントを使用して行われます。
サービスワーカーにできないこと
サービスワーカーはウィンドウ オブジェクトにアクセスできない
ウィンドウ オブジェクトはサービスワーカー スレッドとは別に、UI スレッドで実行されます。 これは、サービスワーカーがDOM要素を直接操作できないことを意味します。 サービスワーカーとウィンドウは、postMessage メソッドで通信することができます。 これにより、メッセージの受け渡しができるようになります。 メッセージを処理し、異なるワークフローをトリガーするために、それぞれの側でロジックを持つ必要があります。
Service Workers Require HTTPS
サービス ワーカーは非常に強力なので、ページが HTTPS を使用して提供される場合のみ有効になります。 これにより、サービス ワーカーが行うように設計されたことを実行できるように、セキュリティ レベルが保証されます。
HTTP では、サービス ワーカーは中間者攻撃（man in the middle attack）の影響を受けやすくなります。 開発者は localhost で作業できるため、ローカル TLS 証明書をインストールする必要はありません。
言い換えると、サービス ワーカーが HTTP で動作するかどうかの答えは「いいえ」です。
Are Only Asynchronous
サービス ワーカーは非同期であり、プロミスおよびプロミスを使用する API を使用し、それに依存することを意味します。 これは、XHR や localStorage のような同期 API がサービス ワーカーに利用できないことを意味します。 心配はいりません。Fetch API (XHRに代わるもの) と IndexedDB は使えます。 ウィンドウ オブジェクトと直接対話しないほとんどの API は、サービス ワーカーでアクセス可能です
。