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