はじめに

ずーっと寝かしてたブログを思い出して少し書こうかと思います。
テーマは「 PWA 」: Progressive Web Apps。
最近にわかに話題になりはじめたキーワードです。
僕も3月から PWA の集中勉強会を主催して、自分でもリサーチしたり実践した結果をフィードバックする講演活動をしています。
ここでは、エンジニア以外の人にもわかるように、まずは PWA というのがどんなものなのかを説明します。

本題に入る前に、少しこれまでのイベントの映像や資料などをご紹介しておきます。
僕の資料はご自由に活用いただいて結構ですので、よかったらご覧ください。
また、5月以降にもイベントや講演を予定していますので、ぜひご来場ください。


日本 Android の会定例会

日本 Android の会 3月定例会「クロスプラットフォーム最前線2018」(2018/3/14)
イベントページ:https://japan-android-group.connpass.com/event/81275/
「PWA がたぶんくる」
動画:https://www.youtube.com/watch?v=dHpgXDzzMeY
資料:https://www.slideshare.net/RyuShindo/pwa-91916100


日本 Android の会 Web Working Group 「PWAに備える3ヶ月」

PWA に備える3ヶ月 vol.1(2018/3/26)
イベントページ:https://japan-android-group.connpass.com/event/82299/
「Service Worker とは何者か」
動画:https://www.youtube.com/watch?v=mSOdB5HFbAA
資料:https://www.slideshare.net/RyuShindo/service-worker-91918661

PWA に備える3ヶ月 vol.2 (2018/4/23)
イベントページ:https://japan-android-group.connpass.com/event/85039/
動画:https://www.youtube.com/watch?v=aUQs-KHqkIs

PWA に備える3ヶ月 vol.3 (2018/5/31 予定)
イベントページ:https://japan-android-group.connpass.com/event/87237/


日本 Android の会 Android Bazaar and Conference 2018 Spring

Android Bazaar and Conference 2018 Spring (2018/6/9 予定)
カンファレンス「PWA トラック」開催予定
特設サイト:https://abc.android-group.jp/2018s/
イベントページ:https://japan-android-group.connpass.com/event/84318/


 

そしてここでは、何度か PWA について講演をしてきて、時間の都合などで全部話しきれなかったところをゆっくり書いていこうと思います。

技術的な細かい話はさておき、まずは PWA そのものについてお話しします。


What’s PWA?

PWAという言葉の意味

PWA : Progressive Web Apps という言葉の示す意味はいろんな捉え方、考え方がされていて、コレ!というものが決まっているというわけではありません。
Progressive という言葉から連想されるのは・・・ハードロックやメタルを聞いてきた人には「 Progressive Rock 」、いわゆるプログレっていう音楽ジャンルが思い浮かびますね。
そこでは革新的、先鋭的みたいな感じで印象づけられているかと思います。
辞書をひくと非常にたくさんの意味が出てきてちょっと混乱しますが、おおまかに、「進歩」「革新」「前進」「段階」「累進」「進行」といったキーワードが出てきます。
PWA の Progressive には、目新しいイメージの「進歩」「革新」だけではない、「段階」「進行」というキーワードの意識も大きく関与しています。
あんまり言葉の意味や捉え方ばかりつらつらと語っても退屈になってしまいますが、最初の前提として、できるだけ簡潔に触れておきます。

PWA は Web Apps 、つまり Web アプリであり、これはブラウザ上で動くわけですが、Web アプリの動作には環境によって使える機能や使えない機能などの差異が多く存在します。
例えば古いブラウザでは動かない機能や、Chrome では使えるけど Internet Explorer では使えない機能など、やっかいで面倒なことが多くあります。
こうした環境の差異を理解した上で、機能が使える環境ではフルに機能を活用したリッチな見栄えや UI ( User Interface ) 、UX(User eXperience : ユーザー体験)を提供する一方で、使えない環境でも遜色ない情報をきちんと表示して提供する、という Web サイトの実装を心がけるアプローチがあります。
これは「 Progressive Enhancement 」(プログレッシブ・エンハンスメント)という考え方です。
元々は解像度の差異や CSS や Javascript そのものが動作する、動作しない、という古い時代からある考え方で、Progressive Enhancement はプアな環境から足し算していくような考え方ですが、その反対に、リッチなコンテンツから、表示環境が対応しきれないものを差し引いていっても遜色ない情報を提供できるようにしよう、という引き算のような考え方で「 Graceful Degradation 」(グレースフル・デグラデーション)という考え方もあります。

つまり、PWA の Progressive には、Web アプリの表現力を拡充していく上で、「段階的」に発展させていくという意味も込められている、ということが大切です。
この考え方の根幹にある大事なことは、そもそもの Web サイトの役割である情報を伝えることを忘れずに、その上で表現を豊かにしたり機能を便利にしていこうとする、ということです。
便利な機能の実装に伴って、環境によっては何も情報が得られない、あるいはエラーが出たりして不便になる、というようなことが起こらないようにしていくことは Web コンテンツを作っていく上でもとても大切なことですね。

また、そうやって作られた機能にはもうひとつ利点があります。
機能を追加、実装することによって既存の環境に影響が出にくい、という点です。
いままでの機能、表現、表示を損なうことなく、新しい機能に対応した環境では新しい機能の恩恵を受けられるような実装ができる。
まさにこれが Progressive と言えると思います。

PWAってどんなものなのか

さて、言葉の意味はこのへんにして、では実際に PWA とはどのようなものなのか、ということに触れていきたいと思います。

PWA は簡単に言うと、Web サイトのコンテンツをアプリとしてスマートフォンやPCにインストール可能にしたものです。
アプリと同じようにホーム画面にアイコンができて、これをタップ(クリック)すると、アプリのように画面が立ち上がってくる。
表示される画面の中身は Web アプリです。

なーんだ。

そう思われるかもしれません。
ブラウザで見るんじゃダメなの?
とも思われるかもしれません。
ブラウザで見ても内容は同じです。
ブラウザとの見た目上の違いは、アドレスバーが出ない、ということぐらいです。

ブラウザでの表示

PWA の画面

PWA の画面

左側がブラウザ、右側がPWAです。
アドレスバー以外は同じですね。
ちょっとだけ画面が広く使える!これが PWA のメリットですね!とか言わないでください(笑)

では PWA にどんなメリットがあるのでしょうか?

PWA のいいところ

PWA 導入のメリットには、おおよそ以下のようなところがあります。

  • ホーム画面にアイコンが持てる
  • Push通知が利用できる(今のところ Chrome + Android のみ)
  • キャッシュを利用して、オフラインでも機能する
  • 動作が速い
  • コンテンツが検索に載る
  • 更新が容易
  • コンパクト
  • 通信量の節約
  • Web とアプリを別々に作るよりもコストがかからない
  • 既存の Web 資源を活用できる
  • 導入によって発生する既存サイトへの制約、悪影響がない

なんだかいいことづくめですね。
それぞれの項目を少し解説しておきます。

ホーム画面にアイコンが持てる

これはとても大きなメリットです。
ブラウザにはブックマーク機能がありますが、みなさんはブックマーク活用されてますか?
僕はPCでは頻繁にアクセスするサイト(SNS とか Gmail とかカレンダーとか)はブラウザ上部のブックマークバーみたいなところにブックマークして利用してますが、普通のブックマークはあまり利用率が高いとは言えません。
調べ物していて見つけた記事とかは、だいたい URL をコピペしてリサーチ用のメモに残したり、Evernote などのクリップ機能を使ったり、という感じです。
また、ブックマークに入れておいたサイトも、メンテナンスしていないと古くなったり無くなってしまっていたりしています。
スマホで使うときはほとんどの Web サイトに検索から入ります。
“オッケーグーグル”の音声検索なんかも便利ですよね。

そう考えると、自身が運営する Web サイトの再訪を促すのは「ブックマーク」では不足だと感じます。

それに対し、ホーム画面のアイコンは強力です。
ぼーっとスマホを眺めてても目に入ります。
そこで目について起動してもらえればそれで再訪が叶います。
これは今までアプリの特権でしたが、これを Web で実現できるのはとてもありがたいことです。

目につくアイコン=エンゲージメントUP

とも言えると思います。
まあその前に、PWA をインストールしてもらう、というエンゲージメントの確立が必要なのですが、それは魅力的なコンテンツ作りの話になったり、PWA 自体と別の話になってくるのでここでは置いておきます。

ホーム画面のアイコン

ホーム画面に追加されたアイコン。普通のアプリと変わらない。

Push 通知が利用できる

今のところ Chrome + Android の環境に限られてしまいますが、Push 通知はユーザーの再訪を促す非常に強力なツールです。
Push 通知とは、みなさんのスマホでも普段見られているかと思いますが、SNSの通知やニュース、天気の情報などが通知バーにリアルタイムに通知されてくる、あれです。
アプリを起動していない状態でも通知されてきますよね。
そしてそれを開くとアプリが起動して、配信側からお知らせしたかった情報にアクセスしてもらえる、というものです。
コンテンツ提供者側から Push してくるので、Push 通知と言います。
PWA は普通のアプリとなんら変わらない「アプリ」としてインストールされますので、Push 通知を受けてアプリ( PWA )を起動して サイトを再訪してもらう、ということが可能になります。
他のユーザーとのコミュニケーションで利用する SNS や、新着をいち早く知らせるニュースサイトなど、Push 通知を利用することができればもはやネイティブアプリ(※)ではなく PWA で事足りるのはないか?というような事例も多くあると思います。
Push 通知が Android 以外のプラットフォームでも使えるようになってくれば、こうしたアプリの PWA 化はこれからさらに進んでいくのではないかとも思われます。
※ネイティブアプリ:Android や iOS などの個々の環境に特化した専用のアプリをネイティブアプリといいます。App Store などからダウンロードしてインストールするタイプのアプリです。

キャッシュを利用してオフラインでも機能する

PWA は任意の Web コンテンツをキャッシュ(※)して、オフラインでもこれを表示することで機能することができます。
もちろんメッセージの送信だったり、EC サイトの決済だったり、オンラインでなければ機能することができないものもありますが、通信が可能かどうかを判定して自身のアプリの挙動をコントロールできるので、オフラインでまったく何も表示されない、という状況を避けることができます。
※キャッシュ:Web コンテンツを先にダウンロードしておいたり、一度見た(ダウンロードした)コンテンツを保存しておいて、閲覧するときに保存したコンテンツを表示する機能。

オフライン時に表示するページを用意して「キャッシュ」しておく

動作が速い

上述したキャッシュはオフラインの利点の他に、動作が速くなるという利点があります。
キャッシュしたデータを利用すれば、一度アクセスしたコンテンツは通信なしで表示可能ですので、どんなに高速な Web サイトよりも早いレスポンスでコンテンツを表示することができます。
このキャッシュのコントロールこそが PWA の醍醐味とも言える機能です。
余談ですが、アイコンを持つ「アプリ」としての実装をしないまでも、キャッシュの機能だけは活用する、という高速化のアプローチも可能です。
後日、技術的な解説の回で触れたいと思いますが、PWA の中心的技術となるキャッシュのコントロールは「アプリ化」だけじゃない、キャッシュのコントロールによるサイトの高速化という活用の方法があります。

コンテンツが検索に載る

通常のネイティブアプリは主に各プラットフォームのストア、iOS なら App Store 、Android なら Google Play からインストールされますが、PWA は Web サイトから直接インストールされます。
Android ではサイトを閲覧していると、「ホーム画面に追加」というポップアップが出ます。

インストールダイアログの表示

つまり、アプリをインストールする流入口は Web サイトそのものです。
PWA のコンテンツはそのまま Web サイトのコンテンツですので、Web 検索の結果にそのまま反映されます。
そのため、アプリそのものが検索結果に載るという利点があります。
また、ユーザーにインストールを促すのにストアにリンクしてダウンロードさせるというステップも必要なくなります。

更新が容易

Web サイトの内容がそのままアプリの内容ですので、サイトのコンテンツを更新すればそのまま PWA のコンテンツに反映することが可能です。
「反映することが可能」なんてちょっとまわりくどい書き方をしているのは、コンテンツの更新と PWA への反映は完全にイコールではないという点があるからです。
そこはキャッシュをコントロールして、適切に変更を反映させるように構成することが肝要です。
しかしながら、自分の Web サイトの更新にはアプリストアのように審査の足止めもありませんし、普段慣れたサイトの更新作業で済みますので、更新がとても容易です。

コンパクト

PWA のアプリはとてもコンパクトです。
アプリによっては単純な機能のものでもいろいろなライブラリ(アプリの部品)などを使用しているために非常に大きな容量となってしまっているものも散見されます。
PWA 本体は少しの Javascript やデータファイルで構成されているだけですので、とてもコンパクトで、ダウンロードが負担になりにくくなっています。

PWA はわずか 201 KB

通信量の節約

PWA アプリ本体の他に、コンテンツをダウンロードしてキャッシュしますが、それも通常の Web サイトと同等のサイズで、しかも一度キャッシュすれば次回からその分だけダウンロード量が節約できますので、通信量を減らすことができます。
これは、通信速度の遅い地域や国でのサービスにもとても有効ですし、サーバーへのリクエスト数を減らすことでインフラコストの低減も期待できます。

Web とアプリを別々に作るよりもコストがかからない

これは当然のことですが、PWA は Web アプリ(Web サイト)にひと手間加えるだけで実現可能な技術です。
新規作成する場合にしても、アプリを別に作るよりもはすかに簡単に、低いコストで導入が可能です。
また、一般的にネイティブアプリの開発費は Web に比べて高額になる傾向があります。
Android、iOS、その他いろいろなプラットフォームに向けたアプリを複数種類開発する、などとなるとWeb の何倍も費用がかかることが多くなります。
ネイティブアプリは PWA に比べて高性能で、実現できることが多いのですが、PWA である程度欲しい機能が実現できるようであれば、ひとまず PWA で導入してみて、その後様子を見ながらネイティブアプリを作り込んでいく、というのも今後とりうるひとつのアプローチかもしれません。

既存の Web 資源を活用できる

新規の開発だけでなく、既存の Web サイトを持っているのであれば、それを活用しない手はありません。
既存の Web サイトをそのまま PWA としてアプリ化することもできますし、既存のサイトを「データ」として活用するように PWA を構成することもできます。
PWA の構成手法もまた、技術的な内容となってくるので後日別の記事で触れられたらと思います。

導入によって発生する既存サイトへの制約、悪影響がない

先述した「 Progressive Enhancement 」の考え方に従って、正しく実装された PWA は、PWA に対応できない既存の環境にまったく影響を及ぼしません。
少ないリスクで導入できることは大きなメリットです。


なぜ今 PWA なのか

なぜ今 PWA がバズってるのでしょうか。
日本のモバイル市場は iOS のシェアが高く、iOS で利用できない PWA はこれまであまり注目を集めることはありませんでした。
しかしながら、昨秋に Apple は iOS の Safari に PWA の中核となる機能「ServiceWorker」の搭載を発表しました。
そして今年3月29日、アップデートのダウンロードが開始された iOS 11.3 についに ServiceWorker が搭載されました。

ServiceWorker とは前述したキャッシュ機能をコントロールする部分にあたり、ServiceWorker については後日詳しく書く予定ですが、こちらの資料にもまとめていますのでご一読いただければと思います。
「 ServiceWorker とは何者か」
https://www.slideshare.net/RyuShindo/service-worker-91918661

さて、iOS の対応による影響ですが、どれぐらいのインパクトがあるのでしょうか。

3月上旬時点での ServiceWorker への各ブラウザの対応状況。 https://caniuse.com/#search=Service%20Worker

「caniuse.com」というサイトで各ブラウザの環境で使える機能の比較をすることができます。
国別のブラウザシェアに基づいた比較も可能です。
そこで ServiceWorker への対応状況を検索した結果、この時点では日本では約43%のブラウザで ServiceWorker が使用可能でした。
世界シェアで見ると 75%を超えていることから比較すると、日本のシェアが世界とは違うということが見て取れます。

そして今回の iOS のアップデートです。
アップデートがリリースされてすぐにすべてのユーザーの iPhone がアップデートされるわけではありませんが、徐々にアップデートが普及していき、いずれは多くの iPhone で ServiceWorker が動くようになることが期待できます。

その期待値を計算したのがこちらのグラフになります。

日本と世界の ServiceWorker 対応状況

日本ではこれまで43%だった対応ブラウザのシェアが、新バージョンの対応で将来的に80%を超えてくることが期待できます。
世界では88%になる予測です。
世界での対応の増加に対して日本での iOS のアップデートのインパクトがいかに大きいか、見て取れると思います。

また、これは PC を含むすべてのブラウザの統計ですので、モバイル(スマホ)に限定すると、日本もグローバルも実に99%以上が ServiceWorker に対応するという計算になります。

PC においても、Microsoft は 次期 Windows 10 より Edge の PWA 対応をアナウンスしていて、なんとストアにもパッケージ化した PWA が登録可能になるということです。

ますます PWA への対応プラットフォームは広がっていきます。
これはアプリ化できるのならするしかないですよね!


Let’s get ready for PWA !!

そんなわけで、PWA は Web コンテンツがアプリとしてユーザーにより近づける、新しい扉を開く期待のもてる技術です。
多くの人が利用することでより認知度も上がっていけばいろいろなプラットフォームの対応も進んで、もっと便利になっていくのではないかと思います。

また、アプリ化を検討することは、運営する Web サイトのコンテンツの価値を見直すいい機会にもなるのではないかと思います。
魅力的なコンテンツの掘り起こし、ユーザーが頻繁に再訪するようなしくみ作り、などなど、コンテンツの発掘のチャンスでもあるはずです。

PWA の実装は難しいものではありませんので、みなさんご自身のサイトで実装を検討されてみてはいかがでしょうか。

ずいぶんな長文になってしまいましたが、PWA がどんなものかおわかりいただけたでしょうか。
なるべくエンジニアではない方にもわかりやすいように心がけて書いたつもりですが、わからないところなどあればご一報ください。

次回からは PWA の動作の仕組みや構成についてなど、少しずつ技術的な内容に入っていこうと思います。