Service Worker は非常に有用ですが 使い始めたばかりでは使いこなせませんWorkbox により、Service Worker が使いやすくなります。ただし、Service Worker は難しい問題を解決します。そのため、そのテクノロジーを抽象化するのは、理解していないと難しい作業になります。そのため、��初の数枚のドキュメントでは、Workbox の詳細に入る前に、その基盤となるテクノロジーについて説明します。
実行中の Service Worker のリストを表示するには、アドレスバーに「chrome://serviceworker-internals/」と入力します。
Service Worker には何の機能がありますか。
Service Worker は、ウェブブラウザとウェブサーバー間のプロキシとして機能する特殊な JavaScript アセットです。オフライン アクセスを提供することで信頼性を高め、ページのパフォーマンスを向上させることを目的としています。
段階的に強化される、アプリのようなライフサイクル
Service Worker は既存のウェブサイトの機能強化です。つまり、Service Worker をサポートしていないブラウザのユーザーが Service Worker を使用しているウェブサイトにアクセスしても、ベースライン機能は機能しません。ウェブの世界です。
Service Worker は、プラットフォーム固有のアプリケーションと同様のライフサイクルを通じてウェブサイトを段階的に拡張します。ネイティブ アプリがアプリストアからインストールされるとどうなるか考えてみましょう。
- アプリのダウンロード リクエストが送信されます。
- アプリのダウンロードとインストール。
- アプリを使用する準備が整い、起動できるようになりました。
- 新しいリリースがあると、アプリが更新されます。
Service Worker のライフサイクルも同様ですが、段階的な拡張アプローチを採用しています。新しい Service Worker をインストールするウェブページへの初回アクセスでは、そのページに初めてアクセスすると、Service Worker がダウンロードしている間、そのページに基本的な機能が提供されます。Service Worker をインストールして有効にすると、ページを制御して信頼性と速度を向上させることができます。
JavaScript によるキャッシュ API へのアクセス
Service Worker テクノロジー���不可欠な側面は Cache インターフェースです。これは、HTTP キャッシュとは完全に別のキャッシュ メカニズムです。Cache インターフェースには、Service Worker のスコープ内とメインスレッドのスコープ内でアクセスできます。これにより、Cache インスタンスに対するユーザー主導のインタラクションの可能性が広がります。
HTTP キャッシュは HTTP ヘッダーで指定されたキャッシュ ディレクティブの影響を受けますが、Cache インターフェースは JavaScript でプログラムできます。つまり、ネットワーク リクエストのレスポンスのキャッシュ保存は、特定のウェブサイトにとって最適なロジックに基づいて行うことができます。次に例を示します。
- 静的アセットの最初のリクエストでキャッシュに格納し、後続のすべてのリクエストでキャッシュからのみ提供します。
- キャッシュにページのマークアップを保存しますが、オフラインのシナリオではキャッシュからのマークアップのみを配信します。
- 特定のアセットに対する古いレスポンスをキャッシュから配信し、ネットワークからバックグラウンドで更新する。
- ネットワークから部分的なコンテンツをストリーミングし、キャッシュから App Shell と組み合わせてコンテンツの知覚パフォーマンスを向上させます。
これらはそれぞれ、キャッシュ戦略の一例です。キャッシュ戦略によりオフライン エクスペリエンスが可能になり、高レイテンシの再検証チェックによる HTTP キャッシュ開始チェックを回避することで、パフォーマンスが向上します。ワークボックスの説明に入る前に、キャッシュ戦略と、キャッシュを機能させるコードを確認します。
非同期かつイベント ドリブンの API
ネットワークを介したデータ転送は、本質的に非同期です。アセットがリクエストされ、サーバーがそのリクエストに応答し、レスポンスがダウンロードされるまでに時間がかかります。所要時間は一定ではありません。Service Worker は、イベント ドリブン API を介してこの非同期性に対応し、次のようなイベントにコールバックを使用します。
- Service Worker によるインストール
- Service Worker がアクティブ化されるとき。
- Service Worker がネットワーク リクエストを検出したとき。
イベントは、使い慣れた addEventListener API を使用して登録できます。これらのイベントはすべて、Cache インターフェースと通信する可能性があります。特に、ネットワーク リクエストのディスパッチ時にコールバックを実行���きることは、求められている信頼性とスピードを提供するうえで欠かせません。
JavaScript で非同期処理を実行するには、Promise を使用する必要があります。Promise は async と await もサポートしているため、これらの JavaScript の機能を使用して Service Worker（および Workbox）のコードを簡素化し、デベロッパー エクスペリエンスを向上させることもできます。
事前キャッシュとランタイム キャッシュ
Service Worker と Cache インスタンス間のインタラクションには、プリキャッシュとランタイム キャッシュという 2 つのキャッシュのコンセプトがあります。それぞれが、Service Worker のメリットの中心となっています。
プレキャッシュとは、通常は Service Worker のインストール時にアセットをキャッシュに保存するプロセスです。プレキャッシュを使用すると、オフライン アクセスに必要な主要な静的アセットとマテリアルをダウンロードして、Cache インスタンスに保存できます。このようにキャッシュすると、事前キャッシュされたアセットを必要とする後続のページが表示される速度も向上します。
ランタイム キャッシュでは、実行時にネットワークからリクエストされたときにアセットにキャッシュ戦略が適用されます。この種のキャッシュは、ユーザーがすでにアクセスしたページやアセットへのオフライン アクセスが保証されるので便利です。
Service Worker で Cache インターフェースを使用するこれらの方法を組み合わせることで、ユーザー エクスペリエンスに多大なメリットをもたらし、通常のウェブページにアプリと同様の動作をさせることができます。
メインスレッドからの分離
JavaScript のパフォーマンスの状態は、ウェブにおける進化し続ける課題であり、ユーザーの視点から見ると、これはデバイスの機能と高速インターネットへのアクセスに左右されます。使用される JavaScript が多ければ多いほど、快適なユーザー エクスペリエンスを提供する高速なウェブサイトの構築は難しくなります。
Service Worker は、すべての作業が独自のスレッドで実行されるという点で、ウェブワーカーに似ています。つまり、Service Worker のタスクが、メインスレッドの他のタスクとアテンションを奪い合うことはありません。Service Worker はユーザー ファーストの設計です。
今後の展望
この���キュメントは概要にすぎません。Workbox の適切な説明に入る前に、Service Worker についてもう少し詳しくご説明しますが、安心してください。Service Worker についてしっかりと理解すれば、Workbox をより簡単かつ生産的に操作できるようになります。