最近、プログレッシブ ウェブアプリが話題になっています。このモデルは比較的新しいモデルですが、その原理により、標準の 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 のキャッシュ機能が問題なく動作していることがわかります。
このモデルの「プログレッシブ」な性質の長所の 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 ノード モジュールでも、ビルドプロセスの一環として同様の出力を生成できます。
現在、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 は、ユーザーにオフライン エクスペリエンスを提供するために使用できます。
Service Worker はオフライン キャッシュ保存に優れていますが、サイトやウェブアプリに繰り返しアクセスする際に瞬時に読み込むという形でパフォーマンスを大きく向上させることができます。アプリケーション シェルをキャッシュに保存すると、オフラインで動作し、JavaScript を使用してコンテンツを入力できます。
包括的な Service Worker サンプルが Google Chrome のサンプルで入手できます。Jake Archibald のオフライン クックブックは必見です。Service Worker を初めて使用する場合は、Paul Kinlan 氏の初めてのオフライン ウェブアプリのチュートリアルを試すことを強くおすすめします。
また、Google のチームは、Service Worker のセットアップにかかるオーバーヘッドを削減するのに役立ついくつかの Service Worker ヘルパー ユーティリティやビルドツールも管理しています。これらのライブラリについては、Service Worker ライブラリをご覧ください。主な目標は次の 2 つです。
- sw-precache: ウェブ App Shell のプレキャッシュに役立つ 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 では、現在のところ、この機能を実装する意図に関する公開シグナルはありません。
オープンウェブでのプッシュ通知は、Matt Gaunt 氏によるプッシュ設定に関する包括的な入門編です。また、「Web Fundamentals」ではプッシュ通知の Codelab も受講できます。
動画をもっと見たい場合は、Chrome チームの Michael van Ouwerkerk が Push の 6 分間の概要説明を用意しています。
高度な機能のレイヤ化
なお、ユーザー エクスペリエンスは、ウェブアプリの表示に使用しているブラウザに応じて異なる程度に変化します。ユーザーはハード キャンディー シェルを制御できます。
プログレッシブ ウェブアプリには、バックグラウンド同期（ウェブアプリを閉じた状態でもサーバーとのデータ同期）やウェブ Bluetooth（ウェブアプリから Bluetooth デバイスと通信）といった、ウェブ プラットフォームに導入予定の追加機能も組み込まれます。
Chrome では、ワンショットのバックグラウンド同期が有効になっています。Jake Archibald さんは、自身のオフライン Wikipedia アプリの動画と、その動作を実演する記事を公開しています。Francois Beaufort の API を試してみる場合は、ウェブ Bluetooth のサンプルも多数用意しています。
フレームワーク フレンドリー
構築に使用している既存のアプリケーションまたはフレームワークに上記の原則のいずれかを適用することを止めるものではありません。プログレッシブ ウェブアプリを作成する際に留意すべきその他の原則として、ユーザー中心のパフォーマンス モデルである RAIL と FLIP ベースのアニメーションがあります。
2016 年には、プログレッシブ ウェブアプリのコア機能として、ボイラープレートとシード プロジェクトが有機的に増えてくることでしょう。それまで、これらの機能を独自のアプリに追加することへのハードルはそれほど高くなく、私見でもある。その労力に見合うだけの価値がある。
アーキテクチャ
プログレッシブ ウェブアプリ モデルの「オールイン」化にはさまざまなレベルがありますが、一般的なアプローチの一つはアプリケーション シェルを中心に設計することです。これは厳格な要件ではありませんが、いくつかのメリットがあります。
Application Shell アーキテクチャでは、アプリケーション シェル（ユーザー インターフェース）をキャッシュに保存することが推奨されています。これにより、アプリケーション シェルがオフラインでも動作し、JavaScript を使用して内容が自動的に入力されます。これにより、再アクセス時には、たとえ最終的にコンテンツがそこから仕入れる場合でも、ネットワークがなくても非常に短時間で重要なピクセルを画面に表示できます。これにより、パフォーマンスが大幅に向上します。
Jeremy Keith 氏は最近、このタイプのモデルでは、おそらくサーバーサイド レンダリングを代替とはみなすべきではなく、クライアントサイド レンダリングは機能強化と見なすべきだとコメントしました。フィードバックは妥当です。
Application Shell モデルでは、Service Worker がサポートされる場合にエクスペリエンスを「強化」するのと同じ方法で、サーバーサイド レンダリングをできるだけ使用し、クライアントサイドのプログレッシブ レンダリングを強化する必要があります。最終的にはこれに対処する方法はたくさんあります。
このアーキテクチャに関する記事を読んで、同様の原則をお客様のアプリケーションやスタックに最適に適用する方法を評価することをおすすめします。
ボイラープレート スタートガイド
アプリケーション シェル
app-shell リポジトリには、Application Shell アーキテクチャのほぼ完全な実装が含まれています。Express.js で記述されたバックエンドと ES2015 で記述されたフロントエンドがあります。
このコースではモデルのクライアント サイドとサーバーサイドの両方を扱い、さまざまな処理が行われていることを考えると、コードベースに慣れるまで少し時間がかかります。それ以外は、現時点で最も包括的なプログレッシブ ウェブアプリの出発点となります。このプロジェクトの次の焦点は Google ドキュメントです。
ポリマー スターター キット
Polymer ウェブアプリの正式な出発点として、次のプログレッシブ ウェブアプリの機能がサポートされています。
- ウェブ アプリケーション マニフェスト
- Chrome for Android のスプラッシュ画面
- プラチナ SW 要素を使用した Service Worker のオフライン キャッシュ保存
- プラチナのプッシュ要素を使用したプッシュ通知（手動設定が必要）
現在のバージョンの PSK では、一部のプログレッシブ ポリマー ウェブアプリで見られるようなより高度なパフォーマンス パターン（Application Shell モデル、非同期読み込みなど）の一部はサポートされていません。
2016 年にこれらのパターンを PSK に組み込むことを目指していますが、Rob Dodson 氏による Polymer Zuperkulblog アプリや、Eric Bidelman 氏による優れた Polymer Perf Patterns の講演で、この試みに関する初期の実験が行われています。
Web Starter Kit
Google 独自の新しい標準プロジェクトの出発点として、次のプログレッシブ ウェブアプリの機能が用意されています。
- ウェブ アプリケーション マニフェスト
- Chrome for Android のスプラッシュ画面
- sw-precache による Service Worker の事前キャッシュ
標準の JS や ES2015 を使ったり、Polymer を使用したくない場合は、Web Starter Kit が、コード スニペットを再利用したり盗んだりできる基準点として役立つことがあります。
フレームワークの有無にかかわらずプログレッシブ ウェブアプリ
コミュニティのメンバーによって、JS ライブラリとフレームワークの有無にかかわらず、数多くのオープンソースのプログレッシブ ウェブアプリがすでに構築されています。アイデアをお探しの場合は、以下のリポジトリが参考になります。また、それらはとても優れたアプリです。
簡単な JavaScript
- Paul Lewis 氏のボイスメモは、
app-shellと同様のアーキテクチャを使用して作成されています（作成）。 - オフライン ウィキペディア: Jake Archibald（動画）
- Air Horner（Paul Kinlan）
- Guitar Tuner: Paul Lewis（文書作成）
Polymer
- Zuperkulblog: Rob Dodson（スライド）
対応
仮想 DOM
- Pokedex（Nolan Lawson 作成） - 「do all in a web Worker」アプローチを適用してプログレッシブ レンダリングを行う優れたプログレッシブ ウェブアプリ。（説明）
Angular.js
- Timey.in（Keneth Auchenberg 作成）- リソースのプレキャッシュにも
sw-precacheを使用
おわりに
先ほどお話ししたように、プログレッシブ ウェブアプリはまだ黎明期にありますが、その背後にある手法を試して、ご自身のウェブアプリにどれほど適用できるかを試すには絶好の機会です。
Paul Kinlan 氏は現在、プログレッシブ ウェブアプリに関する「ウェブの基礎」ガイダンスを策定することを計画しています。取り上げてほしい分野についてご意見がありましたら、スレッドでコメントしてください。