「Webとモバイルのギャップを埋める」と謳う、グーグルのPWA（Progressive Web Apps）。しかしググってみてもさほど情報が出ないほど、あまり盛り上がっていないようです。メリット・デメリットと問題点とは？
この記事では、プログレッシブWebアプリ（PWA）とはなにか、またどのような場面で有効なのかを紹介します。
最近では多くの人が、どこにいてもインターネットに接続しています。しかし、まだほとんどのユーザーは接続が断続的で、インターネット回線をシェアするようなデータプランで契約しています。そのようなユーザーの要求を満たすには、これまでのデータフローを変える必要があります。
オフラインでも、すでに訪れたページを表示して、ブラウジングできるようにすれば、インターネット接続が切れていてもユーザーを逃さずに済みます。
それには、キャッシュデータとプログラムを使うことです。モバイルアプリのようなインタラクティブ性も持たせられることもできますし、ユーザーはアプリストアからダウンロードする必要はなく、ストアにアプリを登録する必要もありません。
PAWとはなにか？
プログレッシブWebアプリを正確に理解するとき、Webサイトとモバイルアプリとで比較すると分かりやすいでしょう。下の表は、Webサイト、PWA、モバイルアプリのギャップを比較したものです。
| 機能 | Webサイト | PWA | モバイルアプリ |
|---|---|---|---|
| オフライン | × | ○ | ○ |
| アプリストア | × | × | ○ |
| レスポンシブ対応 | ○ | ○ | ○ |
| 検索 | ○ | ○ | × |
| ローカル通知 | × | ○ | ○ |
| プッシュ通知 | × | ○ | ○ |
| ダウンロード | × | × | ○ |
| 素早いアップデート | ○ | ○ | × |
Web上でPWAについて検索をすると、さまざまな相反する情報や判断基準が表示されます。PWAを定義するには、テクニカルな面でこれから紹介する4つの基準があり、Google Chrome、Opera、Samsungのブラウザーが対応しています。
この4つの基準を満たせば、開発者は望み通り自由に機能をカスタマイズでき、オフラインでのエラーページやオフラインでのブラウジングが可能になります。
プログレッシブになるための条件
Webサイトが、サーバー上にPWAがあると認識されるためには、ユーザーに「Add To Home Screen（ホームスクリーンに追加）」と表示することも含めて、次の4つの条件がグーグルによって定められています。
- ユーザーが5分以上間隔を空けて2回訪れるか
- HTTPSをサポートしているか
- 有効なJSONのマニフェストが含まれているか
- Service Workerが含まれているか
ユーザーが5分以上間隔を空けて2回訪れるか
Google ChromeではPWAのインストールをうながす前に、ユーザーがPWAをホストしているサイトを2回訪れる必要があります。
これは信頼性のある形式とはいえないにもかかわらず、うまく機能しています。初回訪問ユーザーの携帯電話の画面が25%以上表示されてもPWAをインストールするようにはうながされず、2回目以降に訪れたユーザーにPWAのインストールをうながします。
ユーザーの関連性と興味を判断する単純な方法で、将来的には変わっていくでしょう。しかし、現在、グーグルの開発者は、この基準に満足しています。
HTTPSをサポートしているか
PWAでの安全な通信を実現することで、ユーザーは安心してPWAへの接続を許可しやすくなります。
ネットワークのリクエストがService Workerのスクリプト経由なので、httpsを追加すると、スヌーピングのような脆弱性を軽減できます。
この要求は乗っ取りに対する安全性を高めることにフォーカスしていますが、安全な通信を保つことはユーザーの信頼にもつながります。PWAは検索エンジンにインデックスされるため、TLS上で通信することはSEO的にもメリットがあります。
有効なJSONのマニフェストが含まれているか
JSONフォーマットでデータ抽出を準備することで、Service Workerの力を借りて情報をキャッシュし、オフラインでもCSSのロードを可能にして完全なUIを実現するApp Shellを使えます。
ユーザーが新しいページをロードするたびに、Service Workerは抽出されたJSONをキャッシュして、App Shellに物理的に保存します。App Shellは、自分自身でローディングなしで完全にページを再現できるように、必要なスタイル、スクリプト、画像、フォント、HTMLなどをすべてを含んでいます。
PWAはWebサイトと違い、ユーザーがインターネットに接続していないときでもデータを表示できます。
Service Workerが含まれているか
パンに対するバターのように、PWAにService Workerは不可欠なものです。Service Workerは全ファイルのキャッシュやプッシュ通知配信、コンテンツのアップデート、データ処理などさまざまな役割があります。
このスクリプトはWebサーバー上に既に存在しているどのようなアプリやWebサイトととも独立して動き、HTTPの「Get/Post/Set」コマンドに似た「フェッチ」コマンドやイベントリスナーと共に動くことを理解することが重要です。
ユーザーの端末上のjsファイルとして、サーバー上のさまざまなネットワークリクエストを受信することで、Service Workerは適切なレスポンスと一緒にイベントを処理し、インターネットに接続しているかどうかによってカスタマイズしたオフラインページを表示します。
さらに、ユーザーがオフラインだったとしても、既存のキャッシュデータを元にカスタマイズしたコンテンツを表示できます。データセットは、うまくすればキャッシュデータを変数やパラメーターとして扱って、コーディングできることを意味しています。もちろん、それぞれのプロジェクトで効果があればの話です。
最初にWebサイトをロードするときにService Workerがローカルにインストールされます、その後Service Workerは出力するページやJSON、CSS、画像、スクリプトなどのキャッシュを含んだApp Shellと呼ばれるものをインストールします。
最初のロードが数秒かかる一方で、あとのロードはService Workerを活用するようになり、Service Worker自身の実行スピードやコンテンツをキャッシュする仕組みのおかげで、とても早くなります。
一度、これら4つの条件が正確に満たされれば、ユーザーはAndroid端末やほかのPAWをサポートしている端末やブラウザーでPWAをホームスクリーンに追加できます。通常のアプリのようにアイコンがあり、ブラウザー内で開きます。
UIを既存のWebサイトやアプリに合わせるか、PWAのために新しくするかは、デベロッパー次第です。この点については、PWA自身が新しいトレンドなので決まっていません。
PWAのメリットとデメリット
PWAは以下のようなメリットがあります。
- Webサイトに比べてスピードやパフォーマンスが良い
- 安全性
- オフラインをサポートしている
- ホームスクリーンに追加できる
- プッシュ通知
- 直帰率が低い
- モバイルアプリとWebサイトのギャップを埋めてくれる
- アプリのような使い心地
- アプリストアへの申請が不要
一方で以下のようなデメリットもあります。
- サポートしているブラウザーが限られる
- ネイティブAPIへのアクセスが限られる
- アプリストアのような入り口がない
- 現在すべてのPWAがページ構造にリンクを使用しているわけではなく、タブを持つPWAはリンクを持たず検索エンジンから認識されない
PWAはどのような場面で有効か
特定のWebサイトやモバイルアプリケーションの種類によっては、PWAに対応することは理にかなっています。
ただし、ユーザーはオフラインモードでニュースを読めたり、カートに商品を追加したりできる一方で、新しいデータを取得したり、正確な情報にアップデートするためには、インターネットへのアクセスが必要なことを認識することが重要です。
PWAはユーザーがオフラインになったときのためにデータを保存できますが、有料のニュースサイトなどの特定の状況では、広告のクリックや定期購読の決済ができなければ、そのサイトの利益にはなりません。
現在Web上には、さまざまな種類のPWAがあります。Guardian’sのRioRunのようにまったくネイティブアプリと同じように作られているものもあります。
ほかには、既存のWebサイトにService Workerを実装してオフラインでの動作を実現しているものもあります。The Washington Postはオフラインになっても記事を読め、オンラインに戻るまでクロスワードパズルができるページを表示してくれます。
FlipKartは70％以上コンバージョンが上昇し、AliExpressはWebサイトとの比較で新規ユーザーのコンバージョンが104％上昇したと発表しました。
ナイジェリアのオンラインリテーラーKongaでは自社データ使用量が92％削減され、ページの表示速度が劇的に向上しました。彼らのユーザーのほとんどが2Gネットワークでブラウジングしているのです。このようにデータ通信にコストがかかり、スピードの遅い地域において、PWAには大き可能性があります。
PWAが直面する課題
すべての人がPAWに、ポジティブなわけではありません。Jeremy Keithは、ほとんどのPWAがネイティブアプリに似せるためにURLを隠す傾向があるため、PWAのメリット（主に検索エンジンにクロールされる）が無視されていることに懸念を示しています。
この批判に加え、グーグルのPWAの開発責任者であるAlex Russelは、次のように発言しています。
Jeremy Keithのように、私はPWAがより没入型でURLへのアクセスなしに動作していることに動揺しました。まるで、URLやシェアすることに不満を感じているように見えることも心配しています。そのためわれわれのチームでは今期中にこうした点を修正することにしました。
Jeremy Keithはまた、いくつかのPWAがデスクトップのWebブラウザーをまったくサポートせずに、モバイルだけで動作することについても懸念を示しています。しかし、それ自体はPWAとしては悪いことではありません。結局は、Webサイト、アプリ、PWAがどのように統合されるかは、Web管理者やアプリの所有者に任されています。彼は次のように語っています。
多くのPWAの事例を見てみると、「m. 」のサブドメインへリダイレクトすることよりも、心配になるトレンドがあります。PWAの多くは、「アプリ」に似せることを意識しすぎて「Web」であることを忘れているように見えることです。そうしたPWAは、最新のJavaScriptがどこでも動作するかのように作られています。
PWAの開発には時間がかかり、Webではなくモバイルだけでしかリリースできないことは悩ましいです。企業が一部のユーザーを故意に除外することは、おかしなことです。私が見た多くのサイトは、Webに適したデータの表示をしていませんでした。Web向けにコードを書く時間がかかる以外に、Webに適したデータの表示をしない理由が分かりませんでした。
まとめ
PWAは、コンバージョンレートや直帰率、パフォーマンスの向上において、すばらしい結果を出しています。Webサイトの管理者や企業が、ネイティブアプリを作らなくてもアプリ同等の体験を生み出せる点を考えると、明るい未来がPWAにはあるでしょう。
Service Workerの実装は、多くのタイプのビジネスでロード時間を劇的に改善するためだけでも価値はあります。すべてのWebサイトがオフライン機能を必要としているわけではありません。すべてのWebサイトがコンバージョンや直帰率を気にしなければいけないわけではありません。しかし、シンプルなシステムを導入する相対的な容易さを考えると、重要なWebサイトの責任者は、このテクノロジーを先送りすることなく、いま導入することをおすすめします。
（原文：Progressive Web Apps: Bridging the Gap Between Web and Mobile）
［翻訳：萩原伸悟／編集：Livit］
