Service Worker の概要

Service Worker は非常に有用ですが、最初は扱いが難しい場合があります。Workbox により、Service Worker が使いやすくなります。 ただし、Service Worker は困難な問題を解決するため、そのテクノロジーの抽象化も、理解がなければ難しいものです。したがって、Workbox の詳細に入る前に、これらのドキュメントの最初の数部分で基盤となるテクノロジーについて説明します。

実行中の Service Worker のリストを表示するには、アドレスバーに「chrome://serviceworker-internals/」と入力します。

Service Worker の実行リスト。

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 テクノロジーに不可欠な要素は、HTTP キャッシュから完全に独立したキャッシュ メカニズムである Cache インターフェースです。Cache インターフェースには、Service Worker のスコープ内とメインスレッドのスコープ内でアクセスできます。これにより、Cache インスタンスに対するユーザー主導のインタラクションの可能性が広がります。

HTTP キャッシュは HTTP ヘッダーに指定されたキャッシュ ディレクティブの影響を受けますが、Cache インターフェースは JavaScript でプログラムできます。つまり、特定のウェブサイトに最適なロジックに基づいて、ネットワーク リクエストに対するレスポンスをキャッシュに保存できます。例:

  • 静的アセットを最初のリクエストでキャッシュに保存し、後続のリクエストでのみキャッシュから配信します。
  • ページのマークアップはキャッシュに保存しますが、オフラインのシナリオではキャッシュからマークアップのみを提供します。
  • 特定のアセットについて古いレスポンスをキャッシュから配信し、それをバックグラウンドでネットワークから更新する。
  • ネットワークから部分的なコンテンツをストリーミングし、キャッシュの App Shell で組み合わせて、知覚のパフォーマンスを向上させます。

これらはいずれも、キャッシュ戦略の一例です。キャッシュ戦略は、オフライン エクスペリエンスを可能にします。また、高レイテンシの再検証による HTTP キャッシュの開始チェックを回避することで、パフォーマンスを向上させることができます。ワークボックスを掘り下げる前に、いくつかのキャッシュ戦略と、それを機能させるコードを確認します。

非同期のイベント ドリブン API

ネットワーク経由のデータ転送は、本質的に非同期です。アセットをリクエストし、サーバーがそのリクエストに応答してレスポンスをダウンロードするまでに時間がかかります。所要時間は多岐にわたり、不確定です。Service Worker は、次のようなイベントのコールバックを使用してイベント ドリブン API を介してこの非同期性に対応しています。

イベントは、使い慣れた addEventListener API を使用して登録できます。これらのイベントはすべて、Cache インターフェースとやり取りする可能性があります。特に、ネットワーク リクエストがディスパッチされたときにコールバックを実行できることは、要求される信頼性とスピードを提供するために不可欠です。

JavaScript で非同期処理を行うには、Promise を使用します。Promise は asyncawait も支えているため、これらの 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 の使用は簡単で生産的なものになるでしょう。