PWA(Progressive Web Apps:プログレッシブウェブアプリ)とは?
2015年頃から取り上げられるようになったGoogleが提唱しているウェブ開発のアーキテクチャの一種です。また、ウェブだけでなく、ネイティブアプリや、スマホアプリ等でも汎用的に使える技術として昨今注目されています。
PWAの特徴
アプリのようにインストールでき、ホーム画面にアイコンを表示できる。
「共有ボタン」みたいなものを作っておいてホーム画面にWebサイトのアイコンを追加できる。
「オフラインで動作」するためアプリの速度が速いこと
PWAアプリは、一番最初にオンラインで接続したら、それ以降はオフラインで動作するため、それ以前でのアプリでは得られない機能性、操作性、動作速度を得ることができます。
HTML,CSS,JavaScript、画像等のWebサイトのリソースは、インストール時に全てローカルにキャッシュをして、キャッシュから読み込んで立ち上げるような設計になっています。
また、アプリの構成要素に変化があった場合は、必要なファイルを読み込んで、バックグラウンドで読み込んで更新して、最新版のアプリとして動作します。
主なターゲット端末は「モバイル端末」
タブレットや、スマホ等のPCに比べると通信回線が遅くなりがちなモバイル端末が昨今で主なターゲットになっています。
PWAでは、モバイル端末の弱点をカバーするような機能が多く組み込まれています。
Webアプリだが、ネイティブアプリのように、独立したウインドウで動く
PWAは、ブラウザで他のサイトと同じように動くのではなく、独立したウインドウを確保して、その中で動きます。
このような動作は、ユーザーに端末にインストールしてもらうことで実現することが可能です。
プッシュ通知もできる。
サーバーサイドで、プッシュしたい内容があれば、それをモバイル端末に通知することが可能です。
PWAの利点
アプリの良いところとWebの良いところのいいとこ取りができる。
ホーム画面にアイコン(アプリの利点)
Webとかだとブラウザ立ち上げてブックマークしてとか色々な手間が発生するのに比べてアイコンがあればすぐにアクセスできる。
バックグラウンド(アプリの利点)
Androidのみだが。
検索に載る(Webの利点)
更新が容易(Webの利点)
アプリの場合は更新したい場合色々Appストアにあげて審査するなどの手間が発生する。
一つのコードで多くのプラットフォームに対応できる(Webの利点)
アプリだと、iOS向けにSwift、Android向けにKotolinなど複数言語覚えてないといけない。
安い
導入コストが安い
- すでにサイトがあればそのままアプリ化できる。
- アプリとWebを別個に開発しなくて良い。
通信量が抑えられる
- サーバー負荷を抑えられる。
- 通信量を抑えて利用者に優しい。
- PWA自体はとてもコンパクト
要件
HTTPSに対応しているWebサーバ
基本的には、PWAはフロントエンドの技術なので、Webサーバは関係ありません。
ただ、HTTPSプロトコルをサポートしているWebサーバーと言うことは必要条件になってくるので、念のため確認しておきましょう。
PWAは、ローカルにキャッシュしますが、そもそもローカルにキャッシュしたデータが第三者によって、改ざんされないようにすることが、かなり重視されているためです。
個人の開発者でも、「Firebase」等のHTTPSによるホスティング機能に対応したホスティングサービスが出てきているので、楽にはなってきています。
ただし、例外はあり。
ただ、開発中はHTTPSプロトコルは逆に不便なので、HTTPSでなくても許されるような仕様になっています。
Manifest(マニフェスト)
PWAにおいては、ウェブアプリをネイティブアプリと同様の形で操作できるようにするための仕様書のような働きをするJSON形式で記述したファイルです。
PWAのアプリの中身というよりは、下記のようなPWAの概観部分の動きを定義します。
- ホーム画面にインストールする仕様
- ホーム画面からアプリが起動する際の仕様
このファイルは、ブラウザにインストールされるわけではなく、アプリの操作の際に参照されます。
Service Worker(サービスワーカー)
これがPWAでの最も重要なコア要素になり、PWAがオフラインで動作するための基本機能を提供してくれます。キャッシュとオンラインコンテンツをService Workerが仲立ちします。
PWAのイベント処理をするファンクションで構成されています。
Service Workerの動作の流れ
- ウェブアプリの一部としてサーバーからロードされる。
- Service Workerは、自動でブラウザにインストールされて、常駐プログラムとして動作する。
- それ以降は、オフラインでもService Workerのみが動作して、ネットワークの様々な環境に対応できます。
Events
install
インストール時のイベントを拾って何かします。
activate
アクティベート時のイベントを拾って何かします。
message
ページとservice workerの通信に使われます。
fetch
「Functional events」です。HTTPSでデータを取りに行ってキャッシュから返すか、実際に取りに行くか決めます。
sync
「Functional events」です。オフラインの時の通信を覚えておいてオンラインになったら再度通知します。
push
「Functional events」です。プッシュ通知を司る機能になります。
アイコン
アプリのアイコンが必要になります。アプリのようなもの。
導入事例
SUUMO
ブラウザ
ブラウザがPWAをサポートしている必要があります。主要なブラウザで言えば、下記のような感じでしょう。
ブラウザ | 説明 |
---|---|
Chrome | 完全にサポートしている。(バージョン40以降なら確実) |
FireFox | 完全にサポートしている。(バージョン44以降なら確実) |
Safari | 公式では、PWAサポートは「開発中」と明言しています。 |
Microsoft Edge | 公式では、PWAサポートは「開発中」と明言しています。 |
キャッシュ
Service Worker自体が記憶してくれるわけではなく、ウェブブラウザが管理する記憶域に保存することになります。
Service Wokerでは定型的なプログラムで記述することが可能です。
ウェブブラウザが管理する記憶域
ブラウザが提供するAPIを使ってアクセスができる記憶域には、下記の種類があります。
- Local Storage
- Session Storage
- IndexedDB
- Web SQL
利用するデータの種類によっては、Cookieまで考慮してもよいでしょう。
簡単な構造であれば、「Local Storage」を使うだけで問題ないことが多いでしょうし、複雑であれば、「IndexedDB」や「Web SQL」等を使うことも検討しましょう。
設計のポイント
購入などどうしてもオンラインとの通信が必要な場合
「現在オフラインのため表示できません。オンラインの状態で再度お試しください。」などと表示したりする。
関連APIの環境差異は把握すること
どの環境でもまず動く
- IndexedDB
- Cache
使えない環境がある
Background Sync
Push
Payment
Web Auth
認証のAPI
実装方法
フレームワークを使う。
ほぼ何もコードを書かずにPWA化ができる。シンプルで簡単。ただ、この方法だとfetchとかpush、sync、messageの機能がブラックボックス化されてしまっている。
Next.js
next-pwaというライブラリがある。なお、next-pwaは内部的に後述するgoogleのworkboxを使っているようです。
Nuxt.js
nuxt/pwaというプラグインがある。
自分でserviceworkerを実装する。
ブラックボックス化されているfetchとかpush、sync、messageの機能を実装する。ただ、すごくめんどくさい。
workboxを利用する。
googleが提供しているPWAを実装するためのライブラリ。自分でserviceworkerを使うよりは簡単に実装ができる。
この記事へのコメントはありません。