イベントに参加できなかった方に向けてセッションの内容を記事にまとめましたので、ぜひご覧ください。

この記事では、昨今話題に上ることが多いPWAことProgressive Webアプリケーションについて、実際の作り方を解説しながら、それがいったいどういったものであるかを詳(つまび)らかに紹介することを目的としています。

Webでは、「ネイティブアプリと同じことができる」「ネイティブアプリを置き換える」など、期待に胸を膨らませずにいられない浪漫に満ちた噂がありますが、それが本当かどうか記事をご覧いただくとご理解いただけると思います。

Progressive Web Appsの作り方を紹介する前に、簡単に概要を紹介しましょう。

Progressive Web Appsとは?

Progressive Web Apps(以下PWAと記述) は、一言でいうならば「ネイティブアプリのようなUXを提供するWebアプリの概念」といったところでしょう。2015年の11月に開催されたChrome Dev Summit 2015のキーノートで発表されて話題となりました。

もともとは、その年の10月にAlex Russell氏(Google)がブログ記事に投稿した、クライアントの性能に合わせて段階的に進歩するWebアプリケーションのコンセプトでした。

PWAというと、”ネイティブアプリのような体験”といった特徴ばかりが注目されますが、大きな特徴がもう一つあります。それは、PWAという名前にも含まれているProgressiveというところです。

これはHTML5が普及しはじめた頃にあった、「HTML5が解釈できるモダンブラウザーにはリッチな体験を、そうでないブラウザーには従来とおなじ体験を」というデザインの考え方 Progressive Enhancementに由来します。

PWAはこの思想を踏襲し、性能の低いWebブラウザーを切り捨てることなく、クライアントの性能に合わせた機能提供を行います。

PWAは、性能の低いWebブラウザーからアクセスがあった場合は従来と同じWebページとして動作し、PWAが動作する機能を備えたWebブラウザーからアクセスがあった場合は、その機能を活かし、これまでのWebアプリにはなかったネイティブアプリのような体験を提供します。

Progressive Web Appsを実現する機能

それでは、”これまでのWebアプリにはなかったネイティブアプリのような体験”というのはどのようなものがあるでしょう?

代表的なものとしては以下の4つが挙げられます。

1. オフラインサポート
2. プッシュ通知
3. バックグラウンド処理
4. デバイスへのインストール(デバイスのホーム画面から起動できる)

これらはの機能はそれぞれ以下のような新しいAPIによって実現されます。

1. オフラインサポート – Cache API
2. プッシュ通知 – Push API
3. バックグラウンド処理 – Background Sync
4. デバイスへのインストール(OSのメニューから起動できる) – Web App Manifest

そして、これらの機能を提供しているのが1～3がService Workerで、4がWeb App Manifestです。

PWAの定義に明確なものはありませんが、上記の機能の中からオフラインサポートと、インストール（アイコンをデバイスのホーム画面に追加）機能をサポートしていれば、PWAを名乗ってもそう否定されることはないでしょう。

これらの機能により、デバイスのホーム画面から、ナビゲーションバーなどのブラウザーUIがない状態でアプリケーションを起動し、オフラインの状態でも使用できる、という体験をユーザーに提供できます。これらの体験は、これまでのWebアプリケーションにはなかったネイティブアプリのならではのメリットと言えるでしょう。

それでは、逆に Web ならではのメリットとはなんでしょう?

Webのメリット

ネイティブアプリにはないWebならではのメリットを、Googleさんのイベントではよく以下のSLICEという言葉で表しています。

• Secure (安全)
• Linkable (リンク可能)
• Indexable (インデックス可能)
• Composable (再構成可能)
• Ephemeral (一時的な利用)

これら従来のWebとネイティブアプリの体験上のメリットを合わせたものが、PWAのメリットとなります。

Progressive Web Appsが提供する価値

PWAの提供する価値について、GoogleさんのイベントではよくFIREという言葉で紹介されていますが、

• Fast: パフォーマンスの良い、軽快な動作
• Integrated: OSと統合されたユーザー体験
• Reliable: オフラインでも動作する利便性と信頼性
• Engaging: Webサイトの価値向上

この記事ではもう少しかみ砕いて紹介しましょう。

発見性

PWAであれば、アプリを公開するのにアプリストアにわざわざお金を払ってアプリを提出したり、審査を通すための不自由なルールに縛られる必要はありません。これまでのWebアプリと同じようにインターネットに公開しておけば、検索エンジンがクロールして見つけてくれます。

いままでのSEOのスキルがそのまま使える上、Webはアプリストアとは比べものにならない数のユーザーが、比べものにならないくらいの回数、常に検索を行っています。この圧倒的なオポチュニティ（機会）の違いは、自分自身が今日何回Webを検索したか、アプリストアを何回検索したか、比べてみればよくわかるでしょう。

インストール可能

PWAはさまざまなデバイスにインストール可能ですが、そのためにプラットフォームごとに違う開発言語で書き直したりパッケージンクしなおしたりする必要はありません。PWAをサポートしているWebブラウザーであれば、同じアプリケーションをその全部にインストールして使うことができます。

また、”インストールしなくても使える”点もメリットです。もともとがWebページなので、ちょっとだけ使ってみるということが可能です。

サービスを試用してみようと思ったときに、”アプリのインストールが障壁になって利用を中断してしまった”、という経験は誰にでもあることでしょう。また、スマートフォンでコンテンツを閲覧中に、突然、アプリのストア画面が表示され、アプリのインストールを促されて不快な思いをしたこともあるかと思いますが、そういったことを避けられます。

PWAであれば提供者もユーザーもアプリのインストールについてのネガティブな点を回避することができます。

再エンゲージ可能

従来のWebページであれば、ユーザーがコンテンツから離脱したあとは、再び訪問してくれることを祈るくらいしかできませんでしたが PWAはサーバー側から通知をPushすることができます。

これによりユーザーに即時的な価値を提供できます。例えば、ECショップであればタイムセールの開始であるとか、オークションサイトであればオークションの開始や、最高落札額の更新などです。

通知機能を適切に利用することで、ユーザー側の機会獲得を増やし、再エンゲージを促すことができます。

逆にどうでもいいことを通知しすぎるとユーザーの心象を害するので注意が必要です。特に、初めてページを訪問したユーザーに「プッシュ通知を許可しますか?」というメッセージを表示するのは避けたいところです。

ネットワーク非依存

PWAはオフラインでの使用が可能ですので、ネットワークの状態に左右されないように作ることが可能です。また、常に使用されるアセットをローカルにキャッシュすることで表示のスピードアップや、回線の使用料を減らすことにも貢献します。

プログレッシブとレスポンシブ

PWAはきちんとその思想を理解して開発すれば、低機能なブラウザーやPWAをサポートしないデバイスにもサービスを提供できます。また、さまざまな画面サイズに対応するためのレスポンシブな機能については、WebにはMedia Queries等、そのためのナレッジもリソースも豊富に存在するため、既存のスキルを活かして機能を実装できます。

安全

PWAはWebコンテンツと同じWebブラウザーの強力なサンドボックス内で動作するため、ネイティブアプリのようにユーザーの強い権限で動作しないため、誤動作や悪意のあるコードによってシステムに深刻なダメージを与えることはありません。またhttpsによる接続でのみ動作するのでサーバーとのやりとりを安全に行うことができます。

リンク可能

PWAはインターネット上でユニークな URL をもっており、ハイパーリンクのあるさまざまなところからサービスに接続することができます。PWAを使用するのにアプリ ストアは必要なく、面倒なインストールプロセスも必要ありません。

PWAのメリットは、Webとネイティブ アプリのメリットを合わせたということだけでなく、それらを状況に合わせて取捨選択できることです。

Progressive Web Appsを実現するAPI

ここからはPWAを実現するためのAPIと、それらをどのように使ってアプリケーションを構築していくかについて紹介します。

Service Worker

PWAを実現する上で中心となる機能を提供するのが、Service Workerです。

Service Workerとは何か？ 端的に言うと、「バックグラウンドで動作する“プログラミング可能な”ネットワークプロキシ」です。

Service WorkerはWeb Workerの一つで、Webページのスクリプトとは独立して動作しており、DOMにアクセスしたりすることはできませんが、Webページのネットワークリクエストすべてをインターセプトできます。

つまり、Webページからのリクエストを横取りしてキャッシュしたものを返したり、改ざんしたりといったことができます。そのため localhost、127.0.0.1接続以外はhttpsの使用が必須となります。

Service Workerが提供する機能

Service Workerが提供する機能は主に以下の4つです。

• キャッシュ
• リクエストのハンドリング
• Push通知
• バックグラウンド同期

これらの機能を図で紹介します。

キャッシュとリクエストのハンドリング

Service WorkerはWebページからのリクエストの中に、自分のキャッシュリストに含まれるアセットを見つけると、レスポンスからこれを取得してキャッシュします。

それ以降、Webページからリクエストされたアセットがキャッシュ内に存在する場合は、そのキャッシュされたアセットを返します。ネットワークから取得しないので、アセットの取得は高速に完了し、通信コストは発生しません。

Push通知

関連付けられたWebページがアクティブでなくても、サーバーからのPushを受け取り、Notification API等を使用してユーザーに通知を行えます。

バックグラウンド同期

オフライン中にユーザーが行った操作をキャッシュし、

オンライン時にその内容を同期することができます。

このように Service Worker はプログラミング可能なネットワークプロキシとして、これまでにないさまざまな機能を提供します。

これらの機能の2018年6月時点のサポート状況は以下のとおりです。

ここからは、Service Workerの具体的使い方について解説していきます。

Service Workerを使う準備

Service Workerを使った開発を行う際に用意しなければならないものがあります。

まず、Service Workerを利用するためのWebアプリケーション、もしくはWebコンテンツが必要です。これはけしてSPA(Single Page Application)のようなアプリケーション然としたものである必要はなく、既存の一般的な Web ページであってもかまいません。

このWebページ、もしくはWebアプリケーションは、htmlやcss、jsや画像に代表されるメディアといった複数のファイルで構成されていると思いますが、それとはべつにService Worker用のJavaScriptファイルをひとつ用意します。ここでは便宜上sw.jsと名付けます。

このService Worker用のJavaScriptファイルはWebコンテンツ側のJavaScriptコードから登録され稼働を開始します。

Service Workerは、自身のファイルが配置された以下のディレクトリに対しスコープを持つので、コンテンツ/アプリケーション全体をキャッシュするなど管理下におきたい場合はWebサイトのルートに配置します。

Service Workerの登録

Service Workerの登録はWebコンテンツのJavaScript から行います。

登録に必要なコードは非常にシンプルで、最低限、以下のコードで問題を発生させることなく、Service Workerの登録が行えます。

Webコンテンツ側のコードから、navigator.serviceWorker.registerメソッドにより、Service Workerの登録が行われると、Service Worker用のJavaScriptコード（ここではsw.js）ではinstallイベントが発生します。

install イベントハンドラ内では、キャッシュを開き

キャッシュにアセットのリストを登録します。

Service Workerが登録され、installイベント内の処理が無事に完了すると、次にactivateイベントが発生します。（もしinstallイベント内の処理が失敗した際にはerrorイベントが発生します）

installイベント内で”しなければいけない処理”というものは特にないのですが、一般的に古いキャッシュを削除するのに使用されます。このサンプルコードではキャッシュからキーの一覧を取り出し、

キャッシュの名前（新しく指定された）と比較し、異なるものをすべて削除しています。

上記サンプルコードの、”キーの一覧と新しく登録されたキャッシュの名前を比較して異なるものをすべて削除してしまう”、というやり方は少々乱暴かもしれませんので、実際に実装を行う際にはどのようにキャッシュの削除を行うかは十分に考慮してください。

なぜ、activateイベントでキャッシュを削除するのか？

Service Worker自体は、Service Worker用のJSファイルを更新することで再登録されますが、キャッシュが削除されるわけではありません。よって、いずれどこかのタイミングで用済みとなった古いキャッシュを削除する必要が出てきます。

例えば、キャッシュの対象となっているindex.htmlに更新があった場合は、更新前のindex.htmlを保持しているキャッシュを削除しないかぎりユーザーにはいつまでも更新前のindex.htmlが表示されることになります。

Service Worker用のJSファイルが更新されたあと、新しいService Workerはバックグラウンドでインストールされますが、まだ動作はしません。新しいService Workerに制御が移るタイミングは、古いService Workerが制御しているすべてのページが閉じた後からになります。そのためinstallイベントで古いキャッシュを削除してしまうと、まだ動作している古いService Workerはキャッシュを使用できなくなってしまいます。

一方、activateイベントではページの制御が新しいService Workerに移っているので、古いService Workerが使用していたキャッシュを削除することができます。

何をキャッシュさせるか？

Service Workerにキャッシュさせるべきは、App Shellです。App ShellはアプリケーションのUIが機能するために必要な最小限のリソースです。App Shellをローカルにキャッシュすることで、アプリケーションのUI表示と使用可能となるまでの時間を短縮することができ、オフラインでの使用も可能になります。また要件に応じて、キャッシュが有効となるアセット類を指定してもよいでしょう。

しかし、何でもキャッシュさせればよいというものでもありません。例えば、WebGLベースのゲームは、一般的に使用するアセット類のサイズが大きく、これを毎度起動する際にサーバーからダウンロードするのは時間もかかり、通信コストもかさみます。たしかに、これらをキャッシュさせておけば、通信コストを下げ、ゲーム開始までの時間も短縮できます。

しかし、キャッシュストレージの容量には制限があり、また、cacheオブジェクトの代わりに容量の大きいIndexedDBを使用したとしてもクライアントのストレージを占有することになります。

PCなどのストレージ容量の大きいデバイスではあまり問題にならないかもしれませんが、スマートフォンのようなモバイルデバイスではストレージ容量を圧迫することにつながります。よって、なにをキャッシュさせるかは十分に考慮する必要があります。

リクエストのハンドリング

Service Workerは有効化(activate)された後、アイドル状態となり、WebページからのリクエストやサーバーからのPushを待ちます。

アイドル状態のとき、制御下にあるWebページでリンクをクリックするなどしてネットワークリクエストが発生するとService Worker ではfetchイベントが発生します。

fetchイベントハンドラの引数として渡されるオブジェクトに、発生したリクエストが含まれるので、同リクエストがキャッシュ内に存在するのか調べ、

キャッシュ内にリクエストが存在すればそれを返し、存在しなければfetchメソッドを使用してネットワークにリクエストを投げます。

それぞれの処理結果をリクエスト元のWebコンテンツ側に返します。

この動作により、Webコンテンツ側ではService Workerやキャッシュを意識することなく、これまで通りの方法でページの制作を行うことができます。

また既存のWebコンテンツにService Workerの機能を追加する場合も、Service Workerを登録するためコードを追加する以外の作業は基本的に必要ありません。

de:code 2018のセッション動画でService Workerを追加するデモを行っていますので、ぜひ実際の動作をご覧ください。

Web App Manifest

Web App Manifestは、デバイスのブラウザーによって[ホーム画面に追加]される際のアイコンや、ホーム画面から起動した際のスプラッシュアイコンや背景色、アプリケーションが動作するウィンドウのスタイルを定義します。

manifestは、json形式で記述し、以下のようなlinkタグをWebコンテンツ/アプリケーション側に追加して参照させます。

Web App Manifestについては、詳しい解説がMDNにあるので、そちらを参照することをお勧めしますが、以下に簡単な説明を兼ねたサンプルを掲示します。

de:code 2018のセッション動画でWeb App Manifest を追加するデモを行っているので、ぜひ実際の動作をご覧ください。

現在のWindows 10バージョン 1803のProgressive Web Appsの動作

なお、2018年6月現在のWindows 10バージョン1803(OS ビルド 17134.112)では、残念ながらWeb App Manifestによるウィンドウの制御は有効になりません。

例えば、Windows 10のMicrosoft EdgeでProgressive Web Appsのページをタスクバーにピン留めして起動したとしてもWebブラウザーのUIを表示したまま起動してきます。

Windows 10でProgressive Web Appsにそれらしい動作をさせるにはUWP(Universal Windows Platform)アプリでラップする必要があります。

しかし、Windows 10の次のアップデートでは、Web App Manifestのdisplayの設定に対し、PWAのウィンドウは以下のような表示になるそうです。

マイクロソフトのProgressive Web Appsへの
取り組み

Windows 10の[Microsoft Store]から Progressive Web Appsとして作られたアプリを入手することができます。

Web App Manifestのところで書いたとおり、現在のWindows 10にプレーンな Progressive Web Appsをインストールしても、ネイティブアプリのような外観にはなりません。そのためMicrosoft Storeから入手できるProgressive Web AppsはUWPアプリにラップされています。

MicrosoftストアでのProgressive Web Appsの公開

MicrosoftストアでProgressive Web Appsを公開するには 2つの方法があります。

1つめがBingによる自動インデックスによる登録と、2つめがProgressive Web Appsの提供者がMicrosoftストアにProgressive Web Appsを提出するセルフパブリッシングです。

以下でこの 2つの方法について紹介します。

Bingによる自動インデックス(BETA)

現在はまだBETAの状態ですが、BingがWeb上のProgressive Web Appsを検出し、レビューを行い、自動的にMicrosoftストアに公開します。

Bingに自動インデックスされるための条件は、現在のところ以下のようなものがあります。

• HTTPS、セキュアなエンドポイント
• 高品質の manifest
• オフラインサポート
• ストアの審査をパス
  • デジタルグッズを販売しないこと
  • アダルトコンテンツを含まないこと
  • 不快なコンテンツは不可
• Windowsならではの差別化がされている

上記リストで、最後の”Windowsならではの差別化がされている”というのは、少しわかりづらいかもしれません。

Microsoft Storeで公開されるProgressive Web Appsは、UWPアプリにラップされるのでWinRT (Windows Runtime) APIを使用することができます。

つまりWinRT APIを使用することで、Windows 10で使用した際には、純粋なProgressive Web Appsからはアクセスできないプラットプラットフォームやハードウェアリソースの機能を使用することができるため、これらを利用した機能を実装することで差別化を図ることができます。

Microsoftストア向けProgressive Web Appsの検証

決して、Progressive Web Appsの検証に限ったものでなく、ましてやMicrosoftストア向けのWebコンテンツ用に限定するものではありませんが、WebサイトやProgressive Web Appsの品質をチェックするためのsonarwhalというサービスが公開されています。

sonarwhalはProgressive Web AppsがMicrosoftストア向けの準備がてきているか、だけでなく、一般的なWebサイトやアプリケーションのパフォーマンスやユーザーエクスペリエンス、セキュリティの向上の役に立つ情報を提供してくれます。

Bingに検出されないようにするには

インターネットで公開しているProgressive Web AppsをMicrosoftストアから配布されたくない場合、Progressive Web Appsが以下のいずれかの条件に合致していた場合、Bingは自動インデックスを行いません。

• manifest なし
• https なし、もしくは オフラインで動作しない
• Robot.txtファイルが設定されている
• manifestのdisplay設定がbrowser

既に Microsoftストアで公開されているものを取り消したい場合は、アプリを削除するよう reportapp@microsoft.com宛にサービスリクエストを出します。

セルフパブリッシングによるMicrosoftストアでの公開

Bingの自動インデックスに期待するのではなく、明示的にMicrosoftストアでProgressive Web Appsを公開するにはdev.microsoft.comで開発者アカウントを取得し、パッケージ(appx)化してMicrosoftストアに提出します。アプリの内容がMicrosoftストアの審査をパスすればMicrosoftストアで公開されます。

Progressive Web Appsをパッケージ化するには以下の方法があります。

• Visual Studio 2018 を使用する
• PWABuilder を使用する
• pwa-builder CLI を使用する

PWABuilder

PWABuilderはインターネットにホストされているサービスで、同じくインターネットにホストされているWebアプリケーションのためのmanifestファイルやService Workerのコード、Service Workerを登録するためのコードを生成します。

また、UWPのHostedアプリのパッケージも生成できるので、Progressive Web AppsをMicrosoftストアで公開する際にはこれをストアに提出します。

PWABuilderを使用した既存のWebアプリケーション用のmanifestファイルやService Workerのコードを生成する手順については de:code 2018 の セッション動画のデモをご覧ください。

Windows ストア(UWP) アプリの価値

前述しましたが、Progressive Web AppsをUWPアプリ(Hosted Web アプリ)としてラップすることで WinRT が提供するすべての機能を利用することができます。

これは予定表やアドレス帳といったプラットフォームが提供するソフトウェア的なリソースはもちろん、USBやセンサー類といったハードウェアリソースも含まれます。

アプリケーションが通常のWebブラウザー上で動作しているのか、UWPで動作しているかは JavaScriptのif文で簡単に判断できるので、WinRT APIにアクセスするためのコードをインターネットでホストされているコンテンツに含めておくことができます。

JavaScriptで記述したUWPから,WinRT APIを使用するサンプルコードは以下に豊富に用意されているので、Windows 10限定となってしまいますが、純粋なProgressive Web Appsの機能だけでは実現できない要件がある場合は、こういった方法もあるということを覚えておくとよいかもしれません。

・コードサンプル – Windows アプリの開発

Visual Studio 2018を使用してProgressive Web AppsをUWPでラップし、WindowsRT APIを使用する方法については、de:code 2018 のセッション動画のデモをご覧ください。

その他、Progressive Web AppsをUWPとしてMicrosoftストアに公開することで、Microsoftストアの提供するマーケティングデータ (ダウンロード数、ユーザーの性別、年齢層、国、etc.)や、決済のためのストアのAPIが利用できたり、人気があればMicrosoftストアのトップページに掲示されたり、とさまざまなメリットもあります。

しかも、Hostedアプリであれば、共通のコンテンツでありながら純粋なままのProgressive Web Appsがインターネットでホストされているので、アプリストアを通さない場合のメリットも享受できます。

【参考】
・Windows デベロッパーセンター – PWAとWindows10

この記事では、UWPのHostedアプリについて紹介しましたが、Apache Cordovaでもさまざまなモバイル プラットプラットフォーム向けに Hostedアプリを開発することができます。興味のある方は以下の記事をご覧ください。

・Create a hosted web app using Apache Cordova

Progressive Web Appsの価値を高める API

ここまでWindows 10で動作するUWPアプリでラップされたProgressive Web Appsの紹介をしていましたが、ここからは再びプレーンな Progressive Web Appsについてです。

Progressive Web Appsは、ネイティブアプリのような体験を提供しますが、WebアプリケーションなのでWebブラウザーの機能を超えて動作することはできません。

例えば、表示速度や動作速度はネイティブアプリと比較するとどうしても劣ります。

しかし、Webブラウザーで新しくサポートされた以下のような機能を使用すれば、その能力的な差を縮めることができます。これまでの Webコンテンツにはなかった新しい体験をユーザーに提供したり、決済の仕組みもWeb標準のAPIを使用してこれまでよりも少ない工数で組み込むことができるので、これらを使用してアプリケーションの価値を高めることができます。

• CSS3 3D Transform関連等GPUを使用する設定があり、これを意識的に利用することで描画速度を向上させることができます。
• WebAssembly C言語などで記述し、あらかじめコンパイルしたものをWebブラウザーで動作させるため高速な計算が可能となります。
• WebVR VRデバイスの提供するAPIをサポートし、ユーザーによりImmersiveな体験を提供できます。
• Web Payments 決済画面その他、支払いに関する機能を提供します。これとPaypalやStripeなどが提供する決済用のAPIを繋げれば少ない工数で独自に決済期の機能を実装できます。自前の決済の仕組みがあれば、もう何かを販売するたびにアプリ ストアに使用料を支払う必要はありません

この他にも、最新のWebブラウザーにはこれまでできなかった機能が日々搭載されてきます。そういった新機能をいち早く利用できるのも、逆にレガシーなWebブラウザーには引き算した機能を提供できるのもProgressive Web Appsの良いところです。(もちろん、そう作れば、ですが)

Progressive Web Appsの位置づけ

PWAことProgressive Web Appsは「ネイティブアプリのような体験を提供する」という言葉が独り歩きしてしまい、まるで「ネイティブアプリを置き換える」といった印象を持っている人も多いようです。とはいえ、「ネイティブアプリを置き換えることはできない」というのも真ではないでしょう。

例えば、スマートフォンアプリには、アプリとしてインストールさせるためだけに外側をWeb Viewでラップしたいわゆる「ガワアプリ」と呼ばれるものがあります。こういったものは今後はProgressive Web Appsに置き換えられていくでしょう。

実際にイベントサイトや、カンファレンスのセッションスケジュールの部分をPWA化してユーザーが持ち歩けるようにしているサイトはすでにいくつか存在します。

• ABC 2018 Spring | 日本最大級のAndroidデベロッパーの祭典
• ng-japan – The Angular conference in Tokyo, Japan (2018/6/16)

こういったものもProgressive Web Appsが出てくる以前はWebページとは別にスマートフォン用のアプリを、場合によってはプラットフォームごとに別々の言語で開発し、それぞれのアプリストアに提出して審査を受けるといったことをしていました。

Webページとアプリの開発が共通化でき、配布の手間もかからないということは予算や時間的にも非常に大きなメリットがあります。

しかし、Webブラウザー内のJavaScriptからアクセスできないプラットフォームの機能を利用するアプリケーションや、高速な動作や描画を必要とする用途には今後もネイティブ アプリが選択されることでしょう。

Progressive Web AppsはWebアプリケーションとネイティブアプリの体験的なメリットを受け継ぎ、ちょうどその中間に位置し、その隙間を埋めるものです。

Webのページではpoorだったもの、逆にネイティブアプリではtoo muchだったものが、Progressive Web Appsには最適なのかもしれません。

少し作って試すだけの実装ならそれほど難しくありませんので、気になる人はぜひProgressive Web Appsを作ってみることをお勧めします。

Webに足りなかったもの

私はWebが大好きです。リンクを1つクリックしたら（インストールなど煩わしい手続きなしで）すぐに新しいコンテンツを読めるのは最高の体験だなと常日頃感じています。ただし、今までのWebアプリのユーザー体験は決して最適なものではないとも思っています。たとえば以下のような体験をした覚えはありませんか？

• 朝の満員電車でも情報収集に勤しむ現代のビジネスパーソンのあなた。つり革に捕まりながらなんらかの記事コンテンツを見ようとリンクをタップする
• 途端にHTMLのレスポンス待ちで真っ白な画面。レスポンスが返ってきたと思ったら今度はWebアプリ側のローディングGIFが動き出す。
• しばらく待つとテキストが表示され読み始めるものの、時間差で画像が差し込まれレイアウトがずれる（どこを読んでいたんだっけ？）。極めつけは全画面広告が画面を占拠し、嫌になってそっとブラウザを閉じる（代わりにソーシャルアプリやゲームアプリを起動する）。

このように世に出回っている多くのWebアプリはパフォーマンスに課題があります。特に、さまざまなスペックなデバイスがあらゆる環境で利用されるモバイルにおいては、Webアプリは単純に耐えられないくらい遅く、実測で3G回線と同等な環境における平均ページロード時間は19秒もかかっているという統計もあります[1]。 Webアプリはとにかくこのパフォーマンスをどうにかしなければなりません。

一方ですでにネイティブ アプリに慣れ親しんでいるユーザーの期待値を満たすためには、パフォーマンスを改善するだけでは十分ではありません。

• ホーム画面にアイコンを追加したり
• プッシュ通知がタイミングよく送られてきたり
• オフラインでも動作する信頼性だったり

「ユーザー体験の基準」がどんどん上がっていくなか、Webアプリだけがこのような体験を提供できずに取り残されている状況がずっと続いていました。時代に合わせて、ユーザーが求める機能性もWebアプリで実現できなければならないのです。

PWAはベストプラクティス集である

そこで満を持して登場したのがPWAです。PWAと聞くと何かを特定の技術を指すものと思われるかもしれませんが、実はそのコンセプトは幅広く、どちらかというと前述した Webアプリ本来の課題を解決し、よりよいユーザー体験を実現するためのベストプラクティス集のようなものです。Googleが提供しているProgressive Web App Checklist なるものがあり詳細な内容はそちらを確認いただければと思いますが、PWAのコンセプトをざっくり申し上げると以下となります。

• とにかくパフォーマンスいいWebアプリを作りましょう。SPAでもSPAじゃなくても、どんなフレームワーク使っても使わなくても、なんでもいいので、表示が速くて画面遷移がスムーズなものにしてユーザーに好かれましょう。
• また、最新のWeb APIを積極的に使って、機能性も身につけましょう。たとえば、Webアプリをホーム画面に追加できるようにしたり、オフラインでも動作するようにしたり。そんな今までWebアプリでは実現できなかった機能が実装できるようになったんだから、やらない手はないでしょう？

少し上記でも触れていますが、PWAはあくまでベストプラクティス集なので特定のサードパーティーフレームワークやライブラリには依存しません。世の中には ReactやAngularを使ったPWAもありますし、Vanilla JavaScriptなPWAもあります。また、サーバーサイドの構成には一切言及しません。したがって技術スタックを変えずとも適用可能なベストプラクティスでありますし、一度に全部を適用するのではなく段階的に（= Progressively）最適化することもできます。

以下の項目でPWAの特徴をより具体的に見ていきます。

ハイパフォーマンス

何より重要であり最も難しいテーマとなります。パフォーマンスの基準としては、2015年にChromeチームが発表したユーザー中心に考えるパフォーマンスモデルであるRAIL[2]を前提に考えていただければ間違いありませんが、各Webアプリの特性や環境に応じてそれぞれのサービスごとに Performance Budget（ロード時間やファイルサイズ等の上限を決め、それを「予算」として管理する）を設けることをオススメします。たとえば、2017年のChrome Dev SummitでChromeチームが推奨したPerfromance Budgetは、TTI（Time to interactive)を5秒以内、それを実現するためにクリティカルパスのファイルサイズを170KB以内に収めるというものです。[3][4]

何事もまずは現状分析から。Webアプリのパフォーマンス測定やプロファイリングをするLighthouseやChrome DevTools等のツールを使って現状の評価とボトルネックを確認し、対応すべきポイントを決めて最適化を進めます。その後はCalibreやSpeedCurveといったパフォーマンスモニタリングツールを利用して定点観測するといいでしょう。

ハイパフォーマンスなPWAを作るためのデザインパターンであるPRPLパターンもまた参考にすべき方式です。PRPLパターンはPush 、Render、Pre-cache、Lazy-loadの頭文字を取ったもので、主にApp Shell モデルやSPAを採用したWebアプリのために用意されたパターンですが、それ以外の構成に関してもパフォーマンス向上のヒントとなる点が多くあります。

• Push/Render: 初期描画に必須なリソースをHTTP/2 Server Pushするか link rel=preload を利用することで先行取得します。そしてそのリソースを利用し、特にAbove the fold [5] (スクロールしないで見える範囲)を優先してレンダリングします。
• Pre-cache: 次ページ（またはルート）で使用するであろうリソースを先読みします。これにはService Workerを利用するといいでしょう。
• Lazy-load: 初期描画に必要なもの以外はすべてLazy-loadします。SPAであれば別ルートの取得がこちら該当しますし、スクロールに合わせたフラグメントの取得であればIntersection Observer APIを利用するといいでしょう。

上記のとおり、Webアプリでもパフォーマンスをあげるためのツールやデザインパターンなど、使えるナレッジが多くたまってきました。ぜひともこれらを利用してハイパフォーマンスなWebアプリの開発を実現してください。

ホーム画面に追加

Web App Manifestを実装するとWebアプリをホーム画面に追加できるようになります。以下のようなJSON形式のマニフェストファイルを用意し、

{
   "name": “PWA Demo Application”,    
   "short_name": “PWA demo”,
    "icons": [{
        "src": “/assets/icon.png”, "sizes": “192x192”
     }],
    "start_url": “/index.html”,
    "display": “standalone”,
    "scope": “/”
}

link タグでページにひも付けた上で、Service Workerをインストールすると、

<link rel="manifest" href="/manifest.json">

<script>
if ('serviceWorker' in navigator)    
   navigator.serviceWorker.register('/sw.js')
</script>

このようにホーム画面へ追加を促すプロンプトが上がってきます。ホームに追加した後はフルスクリーンで起動しますし、Androidの場合は1つの アプリとしてみなされディープリンクまで可能です。

1点補足すると、この「ホーム画面に追加」は強力ですが、よりユーザーに気持ちよく追加してもらえるように、意味のあるタイミングでプロンプトを表示するとさらにいいでしょう。これを実現するためにぜひともonbeforeinstallpromptイベントハンドラーを利用してください。

onbeforeinstallpromptイベントハンドラーはプロンプトが表示される直前に呼び出されます。そのタイミングでプロンプト表示が適切でなければ表示をキャンセルし、別の任意のタイミングで表示することができます。たとえば、画面上に独自の「ホームに追加アイコン」を作成し、それの onclickのイベントハンドラ内でプロンプトを表示させることも可能です。

var deferredPrompt;
window.addEventListener('beforeinstallprompt', (e) => {
  console.log('beforeinstallprompt Event fired');
  // デフォルトのタイミングでは表示させない
  e.preventDefault();
  // Eventオブジェクトを保存しておく
  deferredPrompt = e;
  return false;
});
// どっか別のタイミングで...
deferredPrompt.prompt();

また執筆時点での最新のChrome Canary (67.0.3394.0)ではプロンプト表示形式を以下のように変更して、ホームに追加の体験をより良くすべく機能検証をしています。ポイントはページ下部に表示されるバナーがコンテンツの邪魔にならないサイズに調整され、PWAが追加済であればそのディープリンク用のバナーに差し替えます。また、前述のprompt関数を利用してユーザーのインタラクションに応じてプロンプトを表示する際は、モーダル表示に切り替わります。

オフライン対応

ハイパフォーマンスの解説でも少し登場したService Worker と Cache APIを利用することでWebアプリをオフラインで実行することが可能になります。Service Workerとはオリジン単位（またはパスの粒度）でインストール可能なJavaScriptで書かれたクライントサイドプロキシのことで、ページ内で発生するHTTPリクエスト / レスポンスを監視したり、それを書き換えたり、必要に応じてリソースを先読みすることもできます。これとCache APIというHTTPリクエスト/ レスポンスオブジェクトをKey-Value形式で保存できるAPIを組み合わせることで、オフライン時でもあらかじめキャッシュしておいたレスポンスを利用すことができるようになるわけです。

このService WorkerとCache APIの組み合わせは「Service Worker の紹介」に記載の方法で使用することができますが、より汎用的な使い方をまとめたWorkboxというライブラリを利用するのも1つの手です。Workbox を利用すると実装が煩雑になる、特定のファイルのラインタイムキャッシュも以下のようにシンプルに記述することができます。

workbox.routing.registerRoute(
  new RegExp('.*\.js'),
  workbox.strategies.networkFirst()
);

Workboxはその他にも、ファイル単位でリビジョンを付与したPrecaching、Expirationの定義やBackground Syncを利用したオフライン時の Google Analytics の計測などの機能も提供します。

オフラインの戦略はWebアプリの特性に応じて変わってくるものです。例えばニュースサイトであれば、トップページに出ている注目記事をすべて先読みし、オフラインでも読めるようにすることも考えられますし、ECサイトであればまた別の戦略が適している場合もあるでしょう。電波状況が比較的良好な日本においても、速度制限や電車内などオフライン（または不安定なネットワーク）になりえるユースケースは存在しますし、最低限でも Offline Dinasourはユーザーに見せないようにフォールバックページを用意すべきです。

その他のWeb API

以下にPWAを実装する上で注目すべきその他のWeb APIを列挙します。

• プッシュ通知: Push API / Notification API
• 自動ログイン: Credential Management API
• 支払いフォームの強化: Payment Request API

上記のAPIも組み合わせることによって、リエンゲージメント性の向上や商品の購買フローを最適化することができます。

クロスプラットフォームなイニシアチブ

上記にあげたPWAで利用するWeb APIは、すべてのブラウザで利用できることを目標に標準化を進めています。個別の対応状況を確認するにはCan I Useをご参照いただければと思いますが、冒頭に述べましたとおりiOSでもiOS 11.3からSafariでService Workerが動作するようになりましたし、Microsoft はWindowsストアにPWAを載せはじめました[6]。このように、さまざまな形でPWAのクロスプラットフォーム利用の機運が高まっていると言えます。

また、PWAはProgressive Enhancementな実装を推奨している点も改めて触れておきます。たとえばService Workerを利用したオフラインキャッシュの実装は、Service Workerが未実装なブラウザでもWebアプリ本来の動作には影響がないように以下のように条件分岐をいれることを推奨しています。

// ServiceWorkerが利用できる場合にのみ
if ('serviceWorker' in navigator) {
  // ServiceWorkerを登録する
  navigator.serviceWorker.register('/sw.js')
}

特定の環境のみでしか動かないWebアプリを作るのではなく、どの環境でもハイパフォーマンスに動作するようにし、最新のWeb APIが利用できる環境では進んでそれをレバレッジするとよいでしょう。

Webアプリ vs ネイティブ アプリ

PWAはその機能性や実現したいコンセプトから「PWAはネイティブ アプリを潰そうとしているのか？」「Webアプリがネイティブアプリにかなうはずない！」など当該テーマにおいては辛辣なコメントを見かける場面もあります。ここで1つお伝えしたいことは、多くのユーザーはネイティブアプリなのかWebアプリなのかというプラットフォームの選択には関心がないということです。大事なのは「うまい、やすい、はやい」ユーザー体験の良いサービスを提供することです。PWAの出現によりWebアプリでもそれを実現する準備が整いつつあり、事業者やソフトウェア エンジニアとしては理想のサービスを提供できるプラットフォームのオプションが増えるという意味で、このWebの進化を前向きに捉えていただければ幸いです。

実際Webアプリにはまだできないこともあります[7]。ただし、Webアプリには他のプラットフォームよりも優れたリーチがあり、その意味でWeb アプリとネイティブ アプリがむしろ手を取ることは、戦略としても決して矛盾しません。

使用したい機能がWebプラットフォームが提供するもので十分であり、技術スタックをWebのみに集約するメリットも感じるのであれば「PWA のみ」という選択肢も今後は出てくるかと思います。しかし、前述した「まだできないこともある」という前提を加味するとネイティブアプリが活躍する場面は引き続きありますし、PWAは「Webアプリ vs ネイティブアプリ」という二者択一を迫る提案ではない点をご理解ください。

ユーザー体験の新たな基準

このようにPWAはWebアプリの「ユーザー体験の新たな基準」を満たすために作られたベストプラクティスでしかありません。重要なのはそれぞれの機能を単純に実装するのではなく、Webアプリの特性に応じて使い分け、ときにはカスタマイズし、ユーザーによりよいサービスを提供することです。今回ご紹介しました各種ツールやデザインパターン、iOSでもService Workerが利用できるようになった点など、舞台は整いつつあります。ぜひとも最高のWeb体験を実現すべくPWAの考え方を取り入れてみてください。

• [1] The need for mobile speed: How mobile latency impacts publisher revenue
• [2] RAILモデルでパフォーマンスを計測する
• [3] Fast By Default: Modern Loading Best Practices (Chrome Dev Summit 2017)
• [4] Can You Afford It?: Real-world Web Performance Budgets
• [5] Above the fold
• [6] First Windows 10 Progressive Web Apps (PWA) published by Microsoft hit the Store
• [7] What Web Can Do Today

はじめまして。GoogleでChromeの開発をしている保呂毅です。
Chromeの中では特にService Worker周りを担当してまして、最近はNavigation Preloadという新機能をがんばって実装しています。 先日開催されたHTML5 Conference 2016でService Worker周辺の最近（ここ1年くらい）の動向に関する発表をさせていただいきました。
今回は、この発表の内容を振り返りたいと思います。

Service Workerとは

まず本題に入る前に簡単にService Workerの説明します。 Service Workerとはどういうものかと言いますと、 下のコードのようにnavigator.serviceWorker.registerというAPIで登録する、バックグラウンドで動作するJavaScript実行環境です。

navigator.serviceWorker.register('./sw.js', {scope: './'});

登録されたServiceWorkerでは、ページからのネットワークリクエストを横取りすることができます。 下のコードでは、ページからのネットワークリクエストを横取りしてHello Worldという文字列をページに返しています。

self.addEventListener('fetch', event => {
  event.respondWith(new Response('Hello World!'));
});

また、ページからのネットワークリクエストの横取りをする以外にも、ページを開いていなくても Push通知を受け取って Notification （通知）を表示する、Push Notificationsという機能も備えています。

Service Workerは新しいAPIでして、まだ利用できるブラウザが限られています。 Is ServiceWorker ready?というページに各ブラウザの対応状況が書かれています。ChromeとFirefox、Opera、Samsungのブラウザは対応していて、Edgeは開発中、Safariは検討中となっています。

Push Notifications

Push Notificationsの仕組み

Push Notificationはどういう仕組みかといいますと、WebサービスのサーバーからFCM (Firebase Cloud Messaging)のサーバーにメッセージをポストすると、それがブラウザに届いて通知を表示できるというものです。FCMは、最近GCM (Google Cloud Messaging)から名前が変わりました。

Push Event

self.addEventListener('push', event => {  
  event.waitUntil(  
    self.registration.showNotification(
      'Hello',
      {
        body: 'We have received a push message.',
        icon: 'message.png',
        tag: 'tag'
      }));  
});

このコードはService Worker上のPushイベントハンドラです。WebサービスのサーバーからFCMのサーバーにPOSTリクエストすると、このイベントハンドラが呼びだされます。このコードでは、ServiceWorkerRegistration の showNotification というAPIで下のような通知を表示しています。 タイトルが’Hello’で中身が’We have received a push message.’で、アイコンにmessage.pngを指定しています。

Notificationclick Event

self.addEventListener('notificationclick', event => {
  event.notification.close();
  clients.openWindow('/messages');
});

このコードはNotificationClickイベントハンドラで、先ほどの通知をクリックした際の処理を書いています。このコードでは、通知を閉じて、messagesというページをopenWindowで開いています。

Payload Data

ここまでの機能は2015年4月にリリースされたChrome 42から使えます。 ところが、Chrome 49までは、Pushメッセージにデータを含めることができないという制限がありました。例えばチャットアプリなどでチャットの内容を通知に表示する場合は、Fetch APIを使ってWebサーバーに問い合わせる必要がありました。 それが、今年の4月にリリースされたChrome 50からは、Pushメッセージ自体に暗号化したデータを含めることができるようになりました。

self.addEventListener('push', event => {
  if (event.data) {
    console.log(event.data.json());
  }
});

Service Worker側ではこちらのコードのようにPushEventにdataというプロパティがついて、データを読めるようになります。 サーバーからどう送信するかの詳細はこちらのURLで説明されているので、興味のある方はぜひ読んでみてください。Node.js用のライブラリ Web Push library for Node.js もありますので、Node.jsをサーバーで使っている方はこちらを使うといいかと思います。

Notification Actions

続きまして、Chrome 48から使える機能、Notification Actionsです。この機能を使うと上の絵のように、ボタンを追加できるようになります。

self.registration.showNotification(
  'Hello',
  {
    body: 'We have received a push message.',
    icon: 'message.png',
    tag: 'tag',
    data: 1234,
    actions: [
      {action: 'like', title: 'Like', icon: 'like.png'},
      {action: 'reply', title: 'Reply', icon: 'reply.png'}]
  });

コードを見ると、Actionsという項目で指定しているのが分かるかと思います。各ボタンに対応する、actionの文字列と、titleの文字列と、iconの画像を指定しています。

Notificationclick Event

このボタンをクリックすると、NotificationClickイベントハンドラが実行され、NotificationClickEventのactionを見ることで、どのボタンがクリックされたのかがわかります。

self.addEventListener('notificationclick', event => { 
  var messageId = event.notification.data;
  event.notification.close();
  if (event.action == 'like') {
    silentlyLikeItem();
  } else if (event.action == 'reply') {
    clients.openWindow('/messages?reply=' + messageId);
  } else {
    clients.openWindow('/messages?reply=' + messageId);
  }
});

このコードの場合、likeがクリックされたらsilentlyLikeItem()というメソッドを呼び出しています。Replyがクリックされた場合は、該当するメッセージのページを開いています。ボタン以外の部分がクリックされた場合も同様です。 ちなみに、メッセージを表示するURLのメッセージIDにnotification.dataの値を使っていますが、こちらはさきほどの通知を表示する際に指定したdataが渡ってきています。 この値は、Pushイベントのdataから取得するといいかと思います。

Standard Web Push Protocol

Chrome 51までは、Web Pushを実現するためには、以下のような手順が必要でした。この認証方法はFCM独自のプロトコルです。

1. 事前にFCMに登録をしてgcm_sender_idというIDを取得
2. manifest.jsonにそのIDを記述
3. FCMサーバーへのPOSTリクエストの際にAuthorizationヘッダにAPIキーを指定する

ところが、Chrome 52からVoluntary Application Server Identification (VAPID) という標準化されたプロトコルでサーバー認証することでFCMへの事前登録が必要なくなりました。 詳しくはこちらのURLを御覧ください。

Stream

サーバーにFetchリクエストをして、帰ってきたレスポンスに手を加えてページに返すService Workerを考えます。

Chrome 51までは、このような処理をした場合、上のアニメにあるようにレスポンスを最後まで読んでからでないと、ページに返すことができませんでした。 しかし、今年の７月にリリースされたChrome 52から、Streamの新しい機能を使うことで、サーバーからのレスポンスを逐次処理しながらページに返すことができるようになりました。

具体的な例で解説します。

ページのヘッダとフッタを事前にキャッシュに入れておいて、ページを読み込む際はコンテンツだけをサーバに問い合わせて、Service Worker内で文字列連結してページに返す。ということを考えます。

self.addEventListener('install', event => {
    event.waitUntil(
      caches.open('cache_name')
        .then(cache => cache.addAll(['./header.txt',
                                     './footer.txt'])));
});

まず、ヘッダとフッタをキャッシュに入れるには、Installイベントハンドラで上のコードのようにCacheStorage APIを使います。この例ではheader.txtとfooter.txtをキャッシュに保存しています。 caches.open()でキャッシュを開き、取得したcacheに対して、cache.addAll()を呼んでヘッダとフッタをサーバーから取ってきて保存しています。

self.addEventListener('fetch', event => {
  var url = event.request.url;
  if (!url.endsWith('.html'))
    return;

  event.respondWith(
    Promise.all(
        [caches.match('./header.txt'),
         fetch(url +  '.txt'),
         caches.match('./footer.txt')])
      .then(responseList => Promise.all(responseList.map(res => res.text())))
      .then(textList =>
            new Response(textList.join(''),
                         {headers:[['content-type', 'text/html']]})));
});

次に、Fetchイベントハンドラで、先ほど保存したヘッダとフッタをキャッシュから取り出して、サーバーから取得したコンテンツと文字列連結します。 先ほど保存したheader.txtとfooter.txtをキャッシュから読み込みつつ、Fetch APIで元のURLに”.txt”をつなげたURLにネットワークリクエストを投げています。 そして、それらすべてのレスポンスから、text()でコンテンツ本文を取得し、その後、joinで連結しています。 これで目的通り、ヘッダとフッタを連結してページに返すことができるのですが、問題があります。 先ほど書いたとおり、サーバーからのコンテンツ全体を取得完了するまでページに返せないのです。 そこで、解決方法がStreamです。Streamを使えば、サーバーから取得したコンテンツを徐々にページに返していくことができます。

self.addEventListener('fetch', event => {
    var url = event.request.url;
    if (!url.endsWith('.html'))
      return;

    var stream = new ReadableStream({
        【次コード参照】
    });

    event.respondWith(new Response(
        stream,
        {headers:[['content-type', 'text/html']]}));
  });

具体的にコードを見ていきましょう。 Installイベントハンドラは先ほどと同じです。 Fetch イベントハンドラは上のコードのようになります。 ReadableStreamという新しいクラスが登場します。中身は下で説明しますが、ここでReadableStreamをつくって、それをResponseオブジェクトを作る際に渡し、respondWith()でレスポンスをページに返しています。

var stream = new ReadableStream({
start(controller) {
  var promises = [caches.match('./header.txt'),
                  fetch(url + '.txt'),
                  caches.match('./footer.txt')];
  function pushStream(body) {
    var reader = body.getReader();
    return reader.read().then(function proc(result) {
      if (result.done)
        return;
      controller.enqueue(result.value);
      return reader.read().then(proc);
    });
  }
  promises[0]
    .then(response => pushStream(response.body))
    .then(() => promises[1]).then(response => pushStream(response.body))
    .then(() => promises[2]).then(response => pushStream(response.body))
    .then(() => controller.close());
}});

ReadableStreamの中身は、このようになります。 start()というメソッドの中でまず、header.txtとfooter.txtのキャッシュからの読み込みと、サーバへのFetchリクエストのPromiseを作っています。 下の方で、まず、ひとつ目のPromise、つまりHeader読み込みのPromiseからレスポンスを取得し、そのレスポンスボディをpushStream()という関数に渡しています。 pushStream()ではbodyからreaderを取得して、順番に読んでいって、controller.enqueue()で詰め込んでいきます。 それが終わったら２つ目のPromise、つまりFetchのPromiseからレスポンスを取得して、あとは同様にbodyの中身を徐々にenqueueしていきます。その後、３つ目のPromise、つまりfooter.txtのPromiseも同様です。最後に、controller.close()を呼んでStreamを閉じています。

このようにすると、サーバーからのレスポンスを最後まで待たずに、徐々にページにデータを返していくことができます。

Unified Media Pipeline

実は、Android Chromeは51まで、audioエレメントやvideoエレメントではAndroidのメディアスタックを利用していました。それが、7月にリリースされたChrome 52からデスクトップ版Chromeと共通化されました。 そのおかげで、

• Service Workerを使ったキャッシュ
• Blob URLからの再生
• playbackRateの指定
• MediaRecorderからのMediaStreamsをWeb Audioに送信する

といったことができるようになり、クロスデバイスの開発が容易になりました。 詳細はこちらのURLを参照してください。

Background Sync

Background Syncはどういうものかと言いますと、その名の通り、バックグラウンドでデータを送受信できる機能です。 例えば、「オフライン時にメッセージを書いて、オンラインになったときに自動で送信」といったことができるようになります。AndroidだとChromeアプリを閉じていても動作します。 この機能はChrome 49 から利用可能です。

ちょうどいい動画がYouTubeにあったのでこちらをご覧ください。 この動画は、Service Workerを使ってオフラインでもWikipediaの記事を読むことができるというWebアプリのデモです。このアプリで、キャッシュに入っていない記事を読もうとしたら、エラーになるのですが、Background Syncを使ってオンラインになった時に自動で記事をダウンロードし、ダウンロードが完了したら先ほど紹介したNotificationのAPIで通知を表示しています。

Foreign Fetch

普通の Fetchイベント

Foreign Fetchの説明をする前に通常のFetchイベントを復習します。 a.comのサイトにService Workerが登録されているとします。 この場合、

• a.comのページ自体のHTMLファイル（メインリソースと言います）へのリクエスト
• このページで読み込まれる、a.com上にある画像等のサブリソースへのリクエスト
• このページで読み込まれる、b.com上にあるサブリソースへのリクエスト

これらはすべて、Service WorkerのFetchイベントハンドラで横取りすることができます。

しかし、例えば、b.comのサイトのページからa.com上にある画像などのサブリソースへのリクエストはFetchイベントハンドラで横取りすることができません。

Foreign Fetchを使うと

これを可能にするのがForeign Fetchです。 Foreign Fetchを使うと、他のサイト(この図の場合はb.com)からの自分のサイト(この図の場合はa.com)へのサブリソースのリクエストをa.comのService Workerで横取りすることができるようになります。

普通のFetchイベント vs Foreign Fetchイベント

まとめますとこうなります。 「ネットワークリクエストを横取りする」という点は共通です。 相違点としては、 普通のFetchイベントは自分のサイトのページからのネットワークリクエストを横取りします。自分のサイトのHTMLページと、そこからの画像などのサブリソースリクエストも横取りできます。

それに対してForeignFetchイベントでは、他のサイトから自分のサイトへのサブリソースのリクエストを横取りすることができるようになります。Web FontサーバやCDN等で活用できるのではと考えられます。

Foreign Fetch の登録方法

具体的にコードを見ていきましょう

self.addEventListener('install', event => {
    event.registerForeignFetch({
        scopes: ['/myscope/'],
        origins: ['https://b.com/']
      });
  });

Foreign Fetchの登録方法ですが、先程の例のように、a.com上のService Workerが、 b.com からの a.com/myscope/ 以下へのリクエストを横取りしたい場合は、Installイベントハンドラで上のコードのようにregisterForeignFetch()というAPIを叩きます。 scopesに横取りしたいリクエストの範囲、originsにリクエスト元のオリジンを指定します。すべてのオリジンからのリクエストを横取りしたい場合は、originsにアスタリスクを指定します。

上のコードのようにForeign Fetchを登録すると、 a.com/myscope/ 以下へのネットワークリクエストの度にForeignFetchイベントハンドラが実行されるようになります。

Foreign Fetch Event

ForeignFetchイベントハンドラでは普通のFetchイベントと同じようにrespondWith()でページにレスポンスを返すことができるのですが、普通のFetchイベントと違って、辞書に包む（以下のコードの{response: res}）必要があります。

self.addEventListener('foreignfetch', event => {
    event.respondWith(
        fetch(event.request).then(res => ({response: res}));
  });

注意点として、このようにしてページに返したレスポンスはページではOpaqueになります。つまり、<img>タグで画面に表示はできるのですが、JavaScriptから中身を読むことができません。 これを読めるようにするにはCORSの設定が必要になります。

CORS (Cross-Origin Resource Sharing)

self.addEventListener('foreignfetch', event => {
  event.respondWith(
     fetch(event.request)
       .then(response =>({response: response,
                          origin: event.origin,
                          headers: ['...']})));
});

具体的にはこのように、respondWith()に渡す辞書でページのoriginを指定します。headersを指定すると、指定したHTTPヘッダもページ側で読めるようになります。

このForeign Fetchですが、まだ実験中の機能でして、試す場合は、Chrome 54以降でchrome://flagsのenable-experimental-web-platform-featuresを有効にしてください。

Header-based Installation

今まで、Service Workerを登録する場合、JavaScriptでnavigator.serviceWorker.register()を呼ぶ必要がありました。

navigator.serviceWorker.register('/sw.js', {scope: '/'});

Header-based Installationを使うと，これが、下のようなHTTPのLink Headerで登録したり、

Link: </sw.js>; rel=serviceworker; scope=/

下のような、HTMLのLink Elementで登録できるようになります。

<link rel="serviceworker" scope="/" href="/sw.js">

ここでポイントとなるのが、サブリソースのリクエストに対するHTTPレスポンスのLink HeaderでもService Workerをインストールできるということです。この機能を使うと、Iframe等でHTMLを読み込ませる必要なく、Foreign FetchのService Workerをインストールできます。CDNなどでサブリソースをサーブしている場合でもCDNのドメインに対してForeign FetchのService Workerを登録できるようになるのです。

この機能もForeign Fetchと同様に実験中の機能でして、試す場合は、Chrome 54以降でchrome://flagsのenable-experimental-web-platform-featuresを有効にしてください。

Origin Trials

Origin TrialとはChromeの実験的な新しいAPIを、申請のあった特定のオリジン(ドメイン)で一定期間だけ使ってもらってフィードバックをもらう仕組みです。 いま(2016年10月現在)はPersistent Storage, Web Bluetooth, Web USB, Foreign Fetch (Header-based Installation含む)が対象になっています。

申請の方法など詳しくはこちらのURLを参照してください

AppCache

Application Cache (通称AppCache)という、Webサイトのオフライン対応のためにかつて提案された機能があります。

しかし、FirefoxはApplication Cacheの非サポート化を明言してまして、Chromeも非セキュアなコンテクストではAppCacheをサポートしなくするとしています。 ですので、Webサイトのオフライン対応はAppCacheではなく、Service Workerを使おうという流れにあります。

Service Workerに移行する際の参考として紹介したいのが、sw-appcache-behaviorというAppCacheの動作を Service Workerを使ってシミュレーションするライブラリです。 もし興味がありましたら、このURLを参照してください。

DevTools

DevToolsは進化が早くてよくUIが変わるのですが、今は、”Application”というタブの中にService Workersというのがありまして、こちらでService Workerの状態を確認したり、デバッグしたりすることができます。

この画面で注目していただきたいのが、このメッセージです。 Service Worker termination by a timeout timer was canceled because DevTools is attached. このメッセージは最近表示するようにしたのですが、「DevToolsがアタッチされてるので、タイムアウトによるService Workerの停止がキャンセルされました」と書かれてます。

Service Workerは一定期間イベントが実行されないと停止し、次回イベントで再起動するようになっています。ただし、DevToolsを開いている間は停止しません。 つまり、通常の状態だと、しばらくほっておくと勝手に停止し、FetchEventなどのイベントハンドラを呼ぶ必要が出ると再起動します。 ですので、Globalスコープに変数を置いて保存していると、再起動時に消えるので、Service Workerのコードを書く際は気をつけてください。

まとめ

駆け足になりましたが、Service Worker周辺の最近（ここ１年くらい）の動向について説明いたしました。下に関連リンクを貼り付けていますので、もっと詳細を確認したい方はご参照ください。

関連リンク集

Introduction to Service Worker

• https://developers.google.com/web/fundamentals/primers/service-worker/

Push

• https://developers.google.com/web/updates/2015/03/push-notifications-on-the-open-web
• https://developers.google.com/web/updates/2016/01/notification-actions
• https://developers.google.com/web/updates/2016/03/web-push-encryption
• https://developers.google.com/web/updates/2016/03/notifications
• https://developers.google.com/web/updates/2016/07/web-push-interop-wins
• https://github.com/web-push-libs/web-push/
• https://developers.google.com/cloud-messaging/

Stream

• https://developers.google.com/web/updates/2016/06/sw-readablestreams
• https://www.youtube.com/watch?v=Pii-LaWOyuo
• https://jakearchibald.com/2016/streams-ftw/#creating-your-own-readable-stream

Unified Media Pipeline

• https://developers.google.com/web/updates/2016/06/ump

Background Sync

• https://developers.google.com/web/updates/2015/12/background-sync
• https://github.com/WICG/BackgroundSync/blob/master/explainer.md
• https://ponyfoo.com/articles/backgroundsync

Foreign Fetch

• https://github.com/slightlyoff/ServiceWorker/blob/master/foreign_fetch_explainer.md
• https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#on-foreign-fetch-request-algorithm
• https://crbug.com/540509
• https://github.com/slightlyoff/ServiceWorker/pull/751

Header-based installation

• https://crbug.com/582310
• https://github.com/slightlyoff/ServiceWorker/issues/685#issuecomment-176473764

Origin Trials

• https://github.com/jpchase/OriginTrials/blob/gh-pages/developer-guide.md

Web Bluetooth

• https://developers.google.com/web/updates/2015/07/interact-with-ble-devices-on-the-web?hl=en

WebUSB

• https://developers.google.com/web/updates/2016/03/access-usb-devices-on-the-web

当日の講演資料と動画は下記で公開されていますので、こちらも参照してください。

• 講演資料

Web技術でアプリ開発2016特集・第5弾は、プログレッシブウェブアプリ (Progressive Web Apps)をご紹介させていただきます。

はじめに

プログレッシブウェブアプリ(Progressive Web Apps)という言葉が初めて登場したのは2015年8月のAlex Russellによる記事Progressive Web Apps: Escaping Tabs Without Losing Our Soulです。当時オフラインやプッシュ通知など、モバイルウェブを飛躍的に進化させる画期的な機能が次々と追加されていた状況において、このムーブメントを呼称するための言葉が求められていました。Google社内でいくつもの候補が挙げられましたが、Service Workerの発案者としてAlex Russellが推したのが、この「プログレッシブウェブアプリ」でした。

また、当初Googleで始まったプログレッシブウェブアプリの動きではありましたが、先日のProgressive Web App Dev SummitではMicrosoft、Mozilla、Opera、Samsungの代表者も登壇するなど、各ブラウザベンダーとも足並みが揃いつつあります。これはもはやウェブ全体の動きと言うことができます。

若干古い情報になりますが、以降この (長い) 記事を読む以外に手早く情報を得るための方法として、下記を挙げておきます。

スマートフォン体験を一歩先へ – プログレッシブウェブアプリの作り方

講演動画

プレゼン資料

プログレッシブウェブアプリとは

プログレッシブウェブアプリとは、最新の標準ウェブ技術を用いることで、オフラインやプッシュ通知といったこれまでよりも一次元上のユーザー体験をもたらすウェブアプリのことです。必ずしもデスクトップのウェブアプリや、ページ遷移を使ったサーバーサイドでレンダリングされるアプリを除外するものではありません。

理屈で説明するよりも、実際に体験した方が早いかと思います。いくつか具体例を挙げましょう。

• Flipkart
• Washington Post
• AliExpress
• suumo

※ 他にも様々なプログレッシブウェブアプリが既に存在していますが、pwa.rocksというサイトにいくつかまとまっていますので、ぜひご覧頂下さい。

実際に使ってみるとわかりますが、これらのアプリケーションにおいてこれまでにない特徴的な点がいくつかあります。

• ホーム画面に追加してワンタップで起動
• キャッシュを使ってオフライン、もしくは高速に動作
• プッシュ通知を送信
• 自動でログイン

プログレッシブとは何か

「プログレッシブ」という言葉自体は直訳すると「進歩的な」といった意味がありますが、ピンとこない方は多いと思います。

プログレッシブウェブアプリの「プログレッシブ」のひとつの意味は、ウェブページとして使い始めたサービスが、ホーム画面に追加し、オフラインで動作し、プッシュ通知を送り始めるといった流れの中で、「徐々にアプリへと変化していく」様を指しています。

もう一つ意味があります。

フロントエンドエンジニアであれば、プログレッシブ・エンハンスメントという言葉を聞いたことがあると思います。プログレッシブ・エンハンスメントとは、HTML5 時代に続々と新しい機能が登場する中で、最新の標準技術をまだ盛り込んでいないブラウザでも、情報を届けるといった目的をゴールに、必要最低限の機能をベースとして、可能であれば最新技術を使うことでよりリッチな体験を提供する、という設計コンセプトのことを言いました。(逆に、リッチな体験を提供できるブラウザをベースに、最新の技術が使えないブラウザでも最低限の目的は達成できるように設計する手法をグレースフル・デグラデーションと呼びました)

プログレッシブウェブアプリも同様に捉えることができます。つまり、必要最低限の機能を提供できる状態をベースとし、オフラインやプッシュ通知などをプログレッシブな (進歩的な) 機能として提供する、というものです。

これは言い方を変えれば、対応していないブラウザがあるからといって対応を待つべきではなく、それを前提としてウェブを前に進めていこう、というメッセージでもあるのです。実際、プログレッシブウェブアプリ対応への副作用として、複数の機能に未対応のブラウザでもコンバージョンレートが改善したという事例も出ています。

アプリとウェブのギャップ

Web2.0の時代を経てコンピューターの世界はネイティブアプリケーションからウェブアプリケーションの時代へと変化を遂げました。地図アプリケーションを思い出して下さい。その昔CD-ROMからせっせとインストールする必要のあった地図が、URLひとつでブラウザから見られるようになったのです。他にも例を挙げればキリがありません。

ウェブはその後もHTML5やその周辺技術の発展により大きく進化していきました。しかしその恩恵を満足の行く形で受けられたのはデスクトップでの話。モバイル・スマートフォンの時代となり、ユースケースが変化していく中で、スマートフォン上で快適に目的を達成するためには、ウェブブラウザは力不足と言われるようになってしまいました。その象徴的な出来事の一つがFacebookのCEOマーク・ザッカーバーグによるこの発言でした。

Disrupt：ザッカーバーグ、「HTML5を過大評価したのは、われわれ最大の失敗」と認める | TechCrunch Japan

これはひとえに標準化を必要とするウェブという環境の特性ゆえと言わざるを得ません。標準化を進めつつ実装し、浸透を待たなければならなかったウェブと異なり、ネイティブアプリはモバイルに最適化した仕様や機能を次々と取り込み、技術革新を起こしていきました。

しかしウェブには、ネイティブアプリでは実現できない特性も持ち合わせています。それがSLICEと呼ばれるものです。

• Secure (安全)
• Linkable (リンク可能)
• Indexable (インデックス可能)
• Composable (再構成可能)
• Ephemeral (一時的な利用)

ウェブもネイティブも、お互いの短所を埋める進化を遂げていく中で、ウェブが着実に前進していることの現れが、プログレッシブウェブアプリと言えるでしょう。一度はHTML5化を断念したFacebookがプッシュ通知を採用したのはその最たる例です。

Facebook、Googleと協力してモバイルウェブユーザーにプッシュ通知を送信

プログレッシブウェブアプリはWeb 2.0、HTML5と続いてきた大きな流れの、次の一歩と捉えて間違いありません。

プログレッシブウェブアプリを構成する機能

プログレッシブウェブアプリはそれ自体が機能を表しているわけではなく、様々な先進的機能をまとめたひとつのムーブメントです。具体的にどんな機能があるのか、ひとつひとつ見ていきましょう。

• HTTPS
• Web App Manifest
• Service Worker
• Cache API
• Web Push / Push Notifications
• Background Sync
• Web Budget API
• Credential Management API
• Payment Request API

HTTPS

プログレッシブウェブアプリに対応する上で大前提になるのがサイトの完全なHTTPS対応です。ログイン画面や商品購入画面だけではなく、すべてのページをHTTPS化する必要があります。

一般的に、HTTPSに対応することでウェブサイトは

• ウェブサイトの一意性を守るアイデンティティ(Identity)
• サーバー・ブラウザ間の通信を秘匿するコンフィデンシャリティ(Confidentiality)
• 送受信されるデータを改ざんさせないインテグリティ(Integrity)

の3つを手に入れることができます。

プログレッシブウェブアプリ対応において重要なのが、以下でご紹介する機能のほとんどがHTTPS上でのみ動作 (セキュアコンテキスト)するという点です。こういった機能はPowerful Features と呼ばれ、以前はHTTP上でも動作したgetUserMediaやgeolocationといったAPIもそこに加えられ、最近HTTPSのみで動作する変更が加えられました。

HTTPSに対応することなしにプログレッシブウェブアプリを実現することは不可能ですので、対応を検討する方はここからスタートして下さい。(ちなみにChromeでは、localhostとfile://もセキュアコンテキストに含まれますので、開発時は少し役に立つかもしれません)

Web App Manifest

ネイティブアプリとウェブサイトを比較した時に、最も大きく異なるのがアクセスのしやすさです。もちろん、アプリのようにインストールしなくても、リンクを踏むだけでアクセスできるという意味で、ウェブは手に届きやすい存在です。しかしスマートフォンの場合、デスクトップのようにキーボードで手軽に検索ができるわけではありません。ホーム画面からタップひとつで起動できるだけで、ユーザーにとっての身近さは大きく改善します。

そこで登場するのがWeb App Manifestです。Web App Manifestを使うことで、該当ページに関する様々な情報を定義することができます。

Web App Manifest | MDN

最近はlangやscope、screenshotsといった項目も新しく追加されていますので、その辺りも注目して下さい。

これらの情報を踏まえ、「ホーム画面に追加」をすると、ウェブアプリはホーム画面に鎮座することができるようになります。しかし、この機能がiOSでも古くからあるmetaタグを使ったものに近いと思われた方もいるかもしれません。

Chromeの場合、このWeb App Manifestといくつかの条件が加わることで、ブラウザが自動的にホーム画面に追加を促してくれる、という点が大きく異なります。詳しくは下記の記事を参照して下さい。

Web App ManifestでWebアプリをインストール可能に – Qiita

Service Worker

Service Workerはプログレッシブウェブアプリを構成する機能の中でも、コンセプトを成立させた一番の立役者で、中核を成すものです。

従来のウェブにおいて、ページはサーバーから送られたHTMLとそれに付随するリソースで構成される機能がすべてであり、ページが閉じられると同時に忘れ去られる存在でした。Service Workerは、ページとは独立して動作するスクリプトを、ページを閉じた後でもブラウザ上で動かし続けることができる機能です。このService Workerを活用することで、様々な可能性が開かれます。

オフライン：Service Workerはページが送信するあらゆるリクエストを横取りすることができます。実質的なローカルプロキシーとなるため、強力なキャッシュを活用すれば、ネットワークに接続していない状態でもレスポンスを返すことができるようになります。詳しくはCache APIの項で説明します。

プッシュ通知：Service Workerはページが閉じた状態でも、また、ブラウザによっては起動してない状態であっても、イベントを検知することができます。そのため、外部サーバーが送信したプッシュリクエストをイベントとして受け取り、何かしらのアクションを起こすことができるのです。詳しくはWeb Push / Web Notificationsの項で説明します。

それでは、Service Workerの使い方を雰囲気だけ見てみましょう。

Service Workerは独立したJavaScriptとして動作するため、ファイルも分けて記述する必要があります。例えばページ上で動作するスクリプトapp.jsが、service-worker.jsというService Workerを使いたいとします。

navigator.serviceWorker.register('service-worker.js', {scope: './'});

これだけでService Workerが登録されます。簡単ですね。

service-worker.jsの中身はイベント・ドリブンのスクリプトになります。例えば下記のように記述しておけば、あらゆるリクエストをService Workerが拾い上げて、サーバーにリクエストを転送することなく”Hello World!”とレスポンスを返します。

self.addEventListener('fetch', function(event) {  
  event.respondWith('Hello World!');  
});

Service Workerは実際いつ動作を開始するのでしょう？影響範囲はどこまででしょう？こういった細かい話になるとセキュリティへの懸念も出てくるため、若干複雑な内容を理解する必要が出てきます。scopeとライフサイクルについては抑えておきましょう。

scope

Service Workerが登録されると、以後半永久的にスクリプトを動かし続けることになります。仮にService Workerがドメインの範囲内すべてに影響をおよぼすことができるとすると、ブログなどのユーザーの権限がパスで区切られたサービスでは、自分の預かり知らないスクリプトが埋め込まれてしまう可能性がでてきます。そこでService Workerでは、scopeという概念を使って影響範囲を制限します。詳しくはこちらの記事が参考になります。

ServiceWorkerのスコープとページコントロールについて – Qiita

ライフサイクル

Service Workerが登録されたあと、スクリプトを手動で更新したい場合もあります。新しいスクリプトはすぐに有効になるのでしょうか？その場合古いスクリプトはどうなってしまうのでしょうか？Service Workerは放っておいたら永久に更新されないのでしょうか？

Service Workerのライフサイクルを正しく理解することはとても重要です。下記の記事をぜひご覧ください。

• Service Workerの紹介: Service Workerの使い方 – HTML5 Rocks (一部古い内容が含まれます)
• 中級者向け Service Worker Tutorial | blog.jxck.io
• Service WorkerのRegistration

デバッグ

Chromeではプログレッシブウェブアプリのデバッグをしやすくするために、最近DevToolsにResourcesパネルの代わりに Applicationパネルが追加されました。Manifestや各種ストレージなどを、ひとつのパネルからまとめて確認することができます。中でもService Worker専用の項目では、現在起動中のスクリプトだけでなく

• Offline – オフラインのエミュレーションボタン
• Update on reload – リロードするだけでService Workerを更新
• Bypass for network – ネットワークリクエストの横取りを一時的に停止

といったオプションが利用できます。ここからService Workerの単独のDevToolsを開いてデバッグを行ってください。

少し未来の話

今後利用可能になるService Worker周辺の重要な機能についても少し触れておきましょう。

Link rel=serviceworker Chrome 54からOrigin Trial (特定のドメインに実験的にホワイトリストで機能を提供) ベースでService Workerの登録が linkタグやHTTPヘッダーで行えるようになりました。将来的にこれが利用できるようになれば、JavaScriptを記述することなく、linkタグやHTTPヘッダーのみでService Workerを登録できるようになります。

<link rel="serviceworker" href="/js/sw.js" scope="/">

https://www.chromestatus.com/feature/5682681044008960

Foreign fetch また、Web Fontsのような複数ドメインから共有されるリソースをCDN経由で提供するサーバーのリソースも、現在は利用する側のService Workerがハンドリングすることが可能ですが、これをCDN側のService Workerがハンドリングできれば効率が向上します。これを可能にする機能はForeign Fetchと呼ばれ、Chrome 54からOrigin Trialベースで提供が開始されています。

https://www.chromestatus.com/feature/5684130679357440

その他、Service Workerのさらに詳しい情報はHTML5 Conference 2016で行われたChromeエンジニアの保呂さんのスライドが参考になります。
Service Worker Deep Dive

Cache API

先程説明したように、Service Workerを使ってあらゆるリクエストを横取りすることで、オフラインの機能が実現可能になります。そこで強力なキャッシュ機能を提供するのがCache APIです。

Cache APIは取得されたリソースだけでなく、リクエストやレスポンスの内容も含めて保存されます。下記の例では、キャッシュが残っていればキャッシュされていたレスポンスを、なければサーバーにリクエストを送って、返ってきたレスポンスを返します (キャッシュに保存はしません)。

self.addEventListener('fetch', function(event) {
  event.respondWith(
    caches.match(event.request).then(function(response) {
      return response || fetch(event.request);
    })
  );
});

Cache APIを使った実例について、詳しくはこちらの記事が参考になります。

ServiceWorkerとCache APIを使ってオフラインでも動くWebアプリを作る – Qiita

なお、Cache APIを扱う上で fetch()も避けては通れませんが、ググらビリティの低さから、まとまった資料が見つかりにくいという問題があります。こちらのページがよくまっていたのでリンクしておきます。

お疲れさまXMLHttpRequest、こんにちはfetch – Qiita

ここまで述べてきたように便利なService Worker + Cache APIですが、多くの人が似たようなコードを書くであろうことは容易に想像ができます。そこで便利なライブラリがいくつかあります。

sw-toolbox

リソースをキャッシュする際に必要になるのが、リソースの優先順位の判定です。例えば共通で利用されるJavaScriptファイルは、更新がない限りネットワークにリクエストを送るまでもなく常にキャッシュから読み込むことでスピードを優先したいと思うはずです。逆に例えば、天気アプリであれば、開く度に最新の天気予報を見たいですが、オフラインだった場合はオフラインだと言われるよりは、キャッシュからでもその後の天気予報を見たいと思うはずです。

このように、同じキャッシュを活用するでも、場面によってキャッシュを優先したいのか、ネットワークを優先したいのかが異なってきます。そこで便利なのがsw-toolboxです。

toolbox.router.get('/myapp/index.html', toolbox.networkFirst);

sw-toolboxではネットワークを優先するnetworkFirst、キャッシュを優先するcacheFirstの他にもfastest、networkOnly、cacheOnlyといった様々なオプションが利用可能です。

https://googlechrome.github.io/sw-toolbox/docs/master/index.html

sw-precache

Service Workerを使ったキャッシュ機能以前にオフラインを実現する機能として登場したApplication Cacheは、ページを初めて開いた時点で、予め定義されたリソースをすべてキャッシュするものでした。Service Worker + Cache APIにおいても同様のニーズはあるでしょう。例えばアプリの外枠や必要最低限のCSSやJavaScriptファイルを予めロードしておくことで、コンテンツ部分のみをダイナミックにロードすればよいというApplication Shellというアーキテクチャを利用する場合です。

これを実現するのに便利なライブラリがsw-precacheです。Gulp やGruntといったタスクランナーを使うことで、リストされたリソースを最初のロード時点でキャッシュしてしまうJavaScript のコードを出力してくれます。あとはこれをService Workerとしてロードすればよいだけです。また、リソースの更新もハッシュを使って自動的に管理してくれるので、どのファイルを書き換えたからリストを変更しなければならない、といったようなマニュアル作業が不要になります。

gulp.task('generate-service-worker', function(callback) {
  var path = require('path');
  var swPrecache = require('sw-precache');
  var rootDir = 'app';

  swPrecache.write(path.join(rootDir, 'service-worker.js'), {
    staticFileGlobs: [rootDir + '/**/*.{js,html,css,png,jpg,gif,svg,eot,ttf,woff}'],
    stripPrefix: rootDir
  }, callback);
});

なお、最近追加されたruntimeCachingという機能を使うことで、sw-toolbox の便利な機能を宣言的に記述することもできます。

sw-appcache-behavior

もし既にApplication Cacheを使っていて、Service Workerに移行を検討している場合は、sw-helpersライブラリの一部であるsw-appcache-behaviorが便利です。既存の Manifestファイルをそのまま利用してService Workerによるオフラインを実現することができます。

sw-offline-google-analytics

オフラインのウェブサイトがうまく作れたとしても、ユーザーがどのアクセスページにアクセスし、どのように利用しているかが分からなければ、本当に役に立っているのかどうかを知ることはできません。これもsw-helpersの一部であるsw-offline-google-analyticsを使えば、オフライン中のアクセス解析をデータベース上に保存しておいて、オンラインになったタイミングでサーバーに送信してGoogle Analyticsでアクセス解析結果を閲覧することができるようになります。

Web Push / Web Notifications

プッシュ通知は、プログレッシブウェブアプリを語る際、これまでできなかったことの中で、技術者ではなくても効果が理解できるという意味では、最も分かりやすい機能です。実際に既に多くのサービスがこれを利用しています。例えば Facebook です。モバイルウェブ版のFacebookにアクセスしてみると、すぐにそのことに気付くでしょう。

navigator.serviceWorker.ready().then(function(sw) {
  sw.pushManager.subscribe({userVisibleOnly: true})
    .then(function(sub) {
      // パーミッション取得後
      sendSubToServer(sub);  // Send subscription to the server
  });
});

self.addEventListener('push', function(event) {
  event.waitUntil(
    self.registration.showNotification(title, {
      body: body, icon: icon, tag: tag,
      actions: [{action: 'remindMe', title: 'REMIND ME'}]
    }
  });
});

具体的な実装方法は若干複雑ですので、サードパーティーのサービスを使うのも手かもしれません。自分で実装する場合は、こちらのドキュメントがよくまとまっています。

Web Pushでブラウザにプッシュ通知を送ってみる – Qiita
Firefox (Developer Edition)でW3C Push APIを使ってみる – Qiita

Chromeの場合、以前はGCM (Google Cloud Messaging、もしくはFirebase Cloud Messaging)が必須でしたが、現在は標準の Web Pushが利用できます。詳しくは下記をご覧下さい。

ChromeでW3C Push APIを使ってみた – Qiita

Web Pushについては、node.js 向けのライブラリも提供されています。

Background Sync

妙なタイミングでネットワークがオフラインになってしまったために、リクエストが送れなかったという経験は誰しもあると思います。そんな時にリクエストをキューしておいて、オンラインになったタイミングで送ってくれるとありがたいですよね。それを実現してくれるのが、Background Syncです。

ServiceWorkerのBackground Syncでオンライン復帰時にデータ送信 – Qiita

Web Budget API

現状Service Workerはプッシュを受信すると、通知を出さなければなりません。これはブラウザリソースの無駄遣いを防ぐためです。しかし、例えばバックグラウンドで購読しているフィードを更新するといったユースケースは容易に思いつきます。

そこで検討されているのがWeb Budget APIという機能です。これを使うことで、ページは与えられたバジェットを適切に配分してバックグラウンドでの処理を行うことが可能になりますので、リソースの無駄遣いを防ぎつつ必要な機能を実現できるようになるはずです。

https://www.chromestatus.com/features/5691190548627456

Credential Management API

Credential Management APIはユーザーのクレデンシャル (認証情報) を制御するためのAPIです。

これを使うことにより

• id / passwordをブラウザに覚えさせる
• ソーシャルログインの選択肢をブラウザに覚えさせる
• ログイン時にアカウント選択ダイアログを提供する
• ユーザーを自動的にログインさせる

といったことが可能になります。

典型的なユースケースとしては、ニュースサイトやコマースサイトといった、必ずしもログインしなくてもよい、しかし提供者側としてはログインしてもらいたいサービスにおいて役立ちます。実際に利用されている例としてはAliExpressの実装が非常によくできていますので、是非一度お試し下さい。

実装は基本的にフロントエンド側だけですので、比較的気軽に導入することができます。

• デモアプリ (ソースコード)
• 翻訳済みのドキュメント
• 実際に実装を体験できるコードラボ
• 仕様
• MDN リファレンス

Payment Request API

Payment Request APIは支払い時のチェックアウトに必要なフォームを置き換えるUIを提供します。Chromeではバージョン 53から利用できるようになる予定です。

Payment Request APIが提供するのは、ユーザーインターフェースです。ブラウザのAutofill機能を活用することで、クレジットカードの情報や住所などを、すばやく簡単に入力できるようになります。

支払い方法は現状クレジットカードのみですが、まもなくAndroid Payも利用可能 (残念ながら当初日本は対象外) になる予定です。将来的には、さらに様々な支払い方法をオープンかつ柔軟に組み込めるようになっていく予定です。

• アナウンス・概要
• 実装ガイド
• Android Pay 実装ガイド
• 仕様
• MDN リファレンス

その他の機能

プログレッシブウェブアプリを語る上で数えるべき機能や考え方は他にもいくつかありますが、キリがありませんのでこの辺にしておきましょう。

• Web Bluetooth
• Web MIDI
• Web Animation

興味のある方は、この辺りもぜひ抑えておいていただければと思います。

Lighthouse

あるウェブアプリを指してそれがプログレッシブウェブアプリかどうかを議論するのはあまり意味のないことですが、それを示す指標を得ることはできます。それがLighthouseというChrome拡張機能です。ウェブサイトを開いた状態でこの拡張を起動すると、プログレッシブウェブアプリの対応度合いをスコアで示してくれます。

Chrome拡張機能としてだけではなく、node moduleとしても利用が可能です。

https://github.com/GoogleChrome/lighthouse

Lighthouseはまだアルファ版の段階のため、評価できない機能が多数ありますが、今後対応していく予定です。

リソース

プログレッシブウェブアプリに興味を持たれた方で、最新情報を追いかけたいという方は下記のページをご覧下さい。RSSフィードも配信しています。

https://developers.google.com/web/updates/

資料が英語で読めない？英語が分かる人はぜひ、翻訳にご協力下さい。

最後に

プログレッシブウェブアプリについて長々と書いてきましたが、重要なのは決してこれらの機能すべてに対応することではありません。自分が提供するサービスがユーザーに最大の価値を提供するために必要であれば、ネイティブアプリを提供するべき場合もあるでしょう。オフライン機能だけが必要な場合もあるかもしれません。これらの機能をうまく組み合わせて、ユーザーが本当に求めている価値を提供できるアプリを開発していただければと思います。