最近、プログレッシブ ウェブアプリについて多くの議論が交わされています。まだ比較的新しいモデルですが、その原則は、Vanilla JS、React、Polymer、Angular などのフレームワークで構築されたアプリを同様に強化できます。この投稿では、今すぐ独自のプログレッシブ ウェブアプリを使い始めるための選択肢とリファレンス アプリをご紹介します。
プログレッシブ ウェブアプリとは
プログレッシブ ウェブアプリはどこでも動作しますが、最新のブラウザではさらに強力に機能します。段階的な機能向上はモデルのバックボーンです。
Aaron Gustafson は、段階的な拡張を M&M のピーナッツに例えています。ピーナッツがコンテンツ、チョコレート コーティングがプレゼンテーション レイヤ、JavaScript がハードキャンディのシェルです。このレイヤの色は、使用するブラウザの機能によって異なる場合があります。また、エクスペリエンスも異なる場合があります。
キャンディーのシェルは、多くの Progressive Web App 機能を実装できる場所と考えてください。ウェブとアプリの両方の利点を兼ね備えたアプリです。ユーザーがブラウザタブを初めて開いたときから利用できます。インストールは必要ありません。
ユーザーがこれらのアプリを繰り返し使用することで関係を築くと、キャンディーシェルがさらに魅力的になります。たとえば、（サービス ワーカーのおかげで）低速なネットワーク接続でも非常に高速に読み込まれ、関連性の高いプッシュ通知を送信し、全画面表示のアプリ エクスペリエンスとして読み込むことができるファーストクラスのアイコンがユーザーのホーム画面に表示されます。また、スマートなウェブアプリ インストール バナーを利用することもできます。
Progressive Web App には以下の特徴があります。
- プログレッシブ - プログレッシブ エンハンスメントをコアテナントとして構築しているため、ブラウザの種類に関係なく、すべてのユーザーが利用できます。
- レスポンシブ - PC でもモバイルでもタブレットでも、次世代の端末でも、あらゆるフォーム ファクタに適合します。
- 接続に依存しない - Service Worker により、オフラインまたは低品質のネットワークで動作するように強化されます。
- アプリ感覚 - App Shell モデルを使用して、アプリスタイルのナビゲーションと操作を提供します。
- 常に最新 - Service Worker の更新プロセスにより、常に最新の状態に保たれます。
- 安全 - スヌーピングやコンテンツの改ざんを防ぐために TLS を介して配信されます。
- 発見しやすい - W3C のマニフェストと Service Worker の登録スコープにより、「アプリケーション」として認識されつつ、検索エンジンからも発見することができます。
- 再エンゲージメント可能 - プッシュ通知などの機能を通じて、簡単に再エンゲージメントを促すことができます。
- インストール可能 - ユーザーが気に入ればアプリのリンクをホーム画面に残しておくことができ、アプリストアで探し回る必要はありません。
- リンク可能 - URL で簡単に共有できます。複雑なインストールは必要ありません。
プログレッシブ ウェブアプリは Android 版 Chrome に固有のものではありません。以下は、Firefox for Android（ベータ版）で動作している Pokedex プログレッシブ ウェブアプリです。初期の [ホーム画面に追加] 機能と Service Worker のキャッシュ機能が正常に動作しています。
このモデルの「プログレッシブ」な性質の良い点の一つは、ブラウザ ベンダーがより優れたサポートをリリースするにつれて、機能を段階的に利用可能にできることです。Pokedex などのプログレッシブ ウェブアプリも Android の Opera ではもちろんうまく機能しますが、実装には顕著な違いがいくつかあります。
プログレッシブ ウェブアプリについて詳しくは、Alex Russell によるオリジナルのブログ投稿をご覧ください。Paul Kinlan は、Progressive Web App に関する非常に便利な Stack Overflow タグも作成しています。
原則
ウェブアプリ マニフェスト
マニフェストを使用すると、ウェブアプリをユーザーのホーム画面にネイティブ アプリのように表示できます。これにより、アプリを（URL バーなしで）全画面表示モードで起動できます。また、画面の向きを制御できます。Android 版 Chrome の最新バージョンでは、スプラッシュ画面とアドレスバーのテーマカラーの定義もサポートされています。また、前述のスプラッシュ画面とホーム画面アイコンに使用するサイズと密度によって、アイコンのセットを定義するのにも使用されます。
マニフェスト ファイルのサンプルは、ウェブ スターター キットと Google Chrome のサンプルで入手できます。Bruce Lawson 氏が作成した マニフェスト ジェネレータや、Mounir Lamouri 氏が作成した便利な ウェブ マニフェスト バリデータもぜひご覧ください。
個人的なプロジェクトでは、realfavicongenerator を使用して、ウェブアプリ マニフェストと iOS、デスクトップなどで使用する両方のアイコンのサイズを正しく生成しています。favicons Node モジュールも、ビルドプロセスの一環として同様の出力を生成できます。
現在、Chromium ベースのブラウザ（Chrome、Opera など）ではウェブアプリ マニフェストがサポートされています。Firefox ではサポートを積極的に開発しており、Edge ではこれらのマニフェストを検討中として掲載しています。WebKit/Safari は、この機能を実装する意向について、まだ公開情報を提供していません。
詳しくは、ウェブの基礎のAndroid 版 Chrome のウェブアプリ マニフェストを使用したインストール可能なウェブアプリをご覧ください。
[ホーム画面に追加] バナー
Android 版 Chrome では、サイトをホーム画面に追加する機能が長い間サポートされていますが、最近のバージョンでは、ネイティブのウェブアプリのインストール バナーを使用して、サイトを事前に追加することを提案することもできます。
アプリ インストール プロンプトを表示するには、アプリが次の条件を満たしている必要があります。
- 有効なウェブアプリ マニフェストがある
- HTTPS 経由で配信されている（無料の証明書については letsencrypt をご覧ください）
- 有効な Service Worker が登録されている
- 2 回アクセスし、アクセスの間隔が 5 分以上ある
アプリ インストール バナーのサンプルが多数用意されています。基本的なバナーから、関連アプリの表示など、より複雑なユースケースまでカバーしています。
オフライン キャッシュ用の Service Worker
Service Worker とは、ウェブページとは別のバックグラウンドで実行されるスクリプトです。イベント（サービングするページから送信されたネットワーク リクエストなど）に応答します。Service Worker の存続期間は意図的に短く設定されています。
イベントを受信すると起動し、イベントの処理に必要な時間だけ実行されます。Service Worker を使用すると、Cache API を使用してリソースをキャッシュに保存し、ユーザーにオフライン エクスペリエンスを提供できます。
Service Worker はオフライン キャッシュに適していますが、サイトやウェブアプリへの再アクセス時に瞬時に読み込みが行われ、パフォーマンスを大幅に向上させることができます。App Shell をキャッシュすることでオフラインでの稼働が可能になり、コンテンツは JavaScript を使用して追加できます。
包括的な Service Worker のサンプルは、Google Chrome のサンプルで入手できます。Jake Archibald のオフライン クックブックは必読です。Service Worker を初めて使用する場合は、Paul Kinlan による初めてのオフライン ウェブアプリのチュートリアルを試すことを強くおすすめします。
また、Service Worker 設定のオーバーヘッドを削減するために役立つ Service Worker ヘルパー ユーティリティやビルドツールも数多く管理しています。Service Worker ライブラリにリストされています。主なものは次の 2 つです。
- sw-precache: ウェブアプリ シェルのプリキャッシュに役立つ Service Worker スクリプトを生成するビルド時ツール
- sw-toolbox: 使用頻度の低いリソースにランタイム キャッシュを提供するライブラリ
Jeff Posnick 氏は、sw-precache に関するクイック ガイド「オフライン ファースト、高速、sw-precache モジュール」と、同じツールに関するCodelab を作成しています。
Chrome、Opera、Firefox はすべて Service Worker のサポートを実装しており、Edge は、この機能への関心について肯定的な公開シグナルを示しています。Safari では、1 人のエンジニアが提案した5 年計画で、この機能に関心があることを簡単に言及しています。
再エンゲージメントのためのプッシュ通知
つまり、ユーザーがタブの外部で操作できるウェブアプリを作成できます。ブラウザを閉じていても、ウェブ アプリを実際に使用していなくても、ユーザーはエクスペリエンスを利用できます。この機能を使用するには、前述の機能の一部をベースに、Service Worker とウェブアプリ マニフェストの両方が必要です。
Push API は Chrome で実装されており、Firefox では開発中、Edge では検討中です。現時点では、この機能の実装の意向に関する Safari からの公開シグナルはありません。
Open Web でのプッシュ通知は、Matt Gaunt によるプッシュの設定に関する包括的な入門書です。また、ウェブの基礎知識では、プッシュ通知の Codelab も利用できます。
Chrome チームの Michael van Ouwerkerk が、動画で Push について説明している6 分間の紹介動画も公開しています。
高度な機能のレイヤリング
ウェブアプリの表示に使用されているブラウザによって、ユーザー エクスペリエンスの甘さのレベルが異なる場合があります。ハードキャンディのシェルは、ご自身でコントロールできます。
ウェブ プラットフォームに追加される機能（バックグラウンド同期（ウェブアプリが閉じている場合でもサーバーとの間でデータを同期）やウェブ Bluetooth（ウェブアプリから Bluetooth デバイスと通信）など）も、この方法でプログレッシブ ウェブアプリに重ねて追加できます。
ワンショット バックグラウンド同期は Chrome で有効になりました。Jake Archibald は、オフラインの Wikipedia アプリの動画と、その動作を示す記事を公開しています。François Beaufort は、この API を試すための Web Bluetooth のサンプルも提供しています。
フレームワークに適している
上記の原則を、現在構築している既存のアプリケーションやフレームワークに適用することは可能です。Progressive Web App の構築時に考慮すべきその他の原則として、ユーザー中心のパフォーマンス モデルである RAIL と FLIP ベースのアニメーションがあります。
2016 年には、プログレッシブ ウェブ アプリケーションのサポートをコア機能として有機的に組み込んだボイラプレートとシード プロジェクトが増えることを期待しています。それまでは、これらの機能を独自のアプリに追加するハードルはそれほど高くなく、私見では、努力する価値があります。
アーキテクチャ
Progressive Web App モデルを「オールイン」で採用する方法にはさまざまなレベルがありますが、一般的なアプローチの 1 つは、App Shell を中心に構築することです。これは必須ではありませんが、いくつかのメリットがあります。
App Shell アーキテクチャでは、App Shell（ユーザー インターフェース）をキャッシュに保存してオフラインで動作させ、コンテンツは JavaScript を使用して追加することを推奨しています。結局はネットワークからコンテンツを取得しているにしても、再アクセスの際は、オフライン状態でも画面上に有効なピクセルをすばやく描画することができます。これにより、パフォーマンスが大幅に向上します。
Jeremy Keith 氏は最近、このようなモデルでは、サーバーサイド レンダリングをフォールバックではなく、クライアントサイド レンダリングを拡張機能として捉えるべきだとコメントしています。これは妥当なフィードバックです。
Application Shell モデルでは、Service Worker がサポートされたときにエクスペリエンスを「強化」するのと同様に、サーバーサイド レンダリングを可能な限り使用し、拡張機能としてクライアントサイド プログレッシブ レンダリングを使用する必要があります。最終的にこの問題に取り組む方法は数多くあります。
アーキテクチャに関する Google の記事を読み、類似の原則を独自のアプリケーションとスタックにどのように適用するのが最適かを評価することをおすすめします。
スタートガイドのボイラープレート
アプリケーション シェル
app-shell リポジトリには、Application Shell アーキテクチャのほぼ完全な実装が含まれています。バックエンドは Express.js で記述され、フロントエンドは ES2015 で記述されています。
モデルのクライアント側とサーバー側の両方をカバーしており、かなり複雑なため、コードベースに慣れるまでに時間がかかります。現時点では、最も包括的な Progressive Web App のスタートガイドです。このプロジェクトの次のステップはドキュメントの作成です。
Polymer Starter Kit
Polymer ウェブアプリの公式出発点は、次の Progressive Web App 機能をサポートしています。
- ウェブ アプリケーション マニフェスト
- Chrome for Android のスプラッシュ画面
- Platinum SW 要素を使用した Service Worker のオフライン キャッシュ
- プラチナ プッシュ要素を使用したプッシュ通知（手動設定が必要）
現在のバージョンの PSK では、一部のプログレッシブ ポリマー ウェブアプリで使用されている高度なパフォーマンス パターン（アプリケーション シェルモデル、非同期読み込みなど）がサポートされていません。
Google は、2016 年にこれらのパターンを PSK に組み込むことを目標としていますが、この点に関する初期のテストは、Rob Dodson による Polymer の Zuperkulblog アプリと、Eric Bidelman による優れた Polymer のパフォーマンス パターンに関する講演で確認できます。
ウェブ スターター キット
新しいバニラ プロジェクトの開始点として、次の Progressive Web App 機能が含まれています。
- ウェブ アプリケーション マニフェスト
- Chrome for Android スプラッシュ画面
- sw-precache による Service Worker の事前キャッシュ
標準の JS/ES2015 の使用を希望し、Polymer を使用できない場合は、Web Starter Kit を参照してコード スニペットを再利用または盗用できます。
フレームワークありとフレームワークなしのプログレッシブ ウェブアプリ
多くのオープンソースのプログレッシブ ウェブアプリが、JS ライブラリとフレームワークの有無にかかわらず、すでにコミュニティのメンバーによって構築されています。ヒントを得たい場合は、以下のリポジトリを参考にしてください。アプリ自体も非常に優れています。
標準の JavaScript
- Paul Lewis の ボイスメモは、
app-shellに似たアーキテクチャを使用して構築されています（詳細）。 - Jake Archibald による オフライン ウィキペディア（動画）
- Paul Kinlan による Air Horner
- ギター チューナー（Paul Lewis 氏）（記事）
Polymer
- Zuperkulblog（Rob Dodson）（スライド）
対応
仮想 DOM
Angular.js
- Kenneth Auchenberg の Timey.in - リソースの事前キャッシュに
sw-precacheも使用
おわりに
前述したように、プログレッシブ ウェブアプリはまだ初期段階にありますが、その背後にある方法論を試し、自分のウェブアプリにどれほどうまく応用できるのかを見てみるのはいかがでしょうか。
Paul Kinlan は現在、プログレッシブ ウェブアプリに関するウェブ ファンダメンタルズのガイダンスの計画を進めています。取り上げてほしい分野についてご意見がありましたら、このスレッドにコメントをお寄せください。