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