第1章 本書の概要
第2章 PWAの概要やツールの紹介
第3章 PWAの実装方法解説
第4章 Web Pushの実装解説
第5章 Service Worker
第6章 おわりに
本書を手にとっていただきありがとうございます。本書はProgressive Web Apps(以降、PWA)に関する情報や実装方法についての解説書です。
まず2章で、PWAに関する概要から関連技術、ツールについて紹介します。3章では簡単なPWAを実装し、4章ではWeb Pushをサーバーも含めて実装する方法を解説します。そして、最終的にはサーバーレスプッシュ通知サーバーとして、AWS Lambdaへのデプロイの仕方も紹介します。5章にはService Workerの概要やどのように扱うのか、注意点などをまとめています。
次のような方々を対象としています。
・PWAの作り方を知りたい
・Web Pushを体験したい
・サーバーにちょっと触れてみたいフロントエンドエンジニア
・サーバーレスとはどんなものかというのを知りたい
・yarnやnpmを扱える
本書はとても広い範囲を取り扱っています。Webのフロントエンドから始まり、プッシュ通知を送るためにFirebaseを使い、AWS Lambdaで通知を送るためのサーバーレスのPIサーバーを構築します。そのため、個別のサービスなどにいての記述は省略しています。たとえば、AWSのアカウント登録などについては紹介していません。
どうしてこんなに広くなったか?それは筆者自身がWebでプッシュ通知をやってみたかったからです。完全に趣味といってもいいでしょう。本書では、その過程で出てきたtipsやノウハウをまとめています。
またライブラリーやフレームワーク、サービスは次のものを使っています。Vue.jsは使い慣れてるので使いましたが、他のフレームワークないし生のJavaScriptでも使えることを意識しています。
・Vue.js
・Workbox
・Firebase
・AWS
・Serverless Framework
そして使用するブラウザーはGoogle Chromeを想定しています。
・Vue.js - v2.6.6
・Vue CLI - v3.4.1
・Workbox - v4.0.0
・Firebase - v5.8.5
・Serverless Framework - 1.38.0
本書のTwitterのハッシュタグは「#try_pwa_np」です。感想や疑問などありましたら、ハッシュタグ付きでツイートしていただけるとキャッチアップします。感想をいただけると次の執筆のモチベーションにつながるので、もしよければツイートしてくれると嬉しいです!
また内容の誤植などありましたら、お手数ですが次のリポジトリーにissueを作っていただけますと助かります。もちろんハッシュタグ付きでツイートしていただいてもかまいません。
https://github.com/mya-ake/try-pwa-apis/issues
サンプルコードの修正した内容はこちらに記載しています。
https://github.com/mya-ake/try-pwa-apis/blob/master/UPDATE.md
本書のサンプルコードは次のリポジトリーで管理されています。
https://github.com/mya-ake/try-pwa-apis
書籍中に出てくるコードは基本的にESLintで整形されています。ESLintは基本prettier + 次のシングルクォーテーション、末尾カンマの設定です。ただし、Vue CLIで作成して、そのまま解説に移っている箇所では次の設定はしていないので、ダブルクォーテーションのままコードが記載されています。フォーマットの関係上そうなっているので、表記ゆれではありません。
'prettier/prettier': [
'error',
{
singleQuote: true,
trailingComma: 'all',
},
],
本書に記載された内容は、情報の提供のみを目的としています。したがって、本書を用いた開発、製作、運用は、必ずご自身の責任と判断によって行ってください。これらの情報による開発、製作、運用の結果について、著者はいかなる責任も負いません。
本書に記載されている会社名、製品名などは、一般に各社の登録商標または商標、商品名です。会社名、製品名については、本文中では©、®、™マークなどは表示していません。
本書籍は、技術系同人誌即売会「技術書典5」で頒布されたものを底本としています。
まずはPWAとはどういうものかを解説します。PWAとは「Progressive Web Apps」の略称です。PWAはGoogleが提唱した、Webアプリケーションのひとつの姿です。
PWAとはなにかをざっくりと説明すると、「ネイティブアプリとWebのいいとこ取りをしたもの」です。次の図は「Progressive Web Apps - PWA Roadshow」という動画のスクリーンショットです。これはYouTubeで公開されています。
出典:Progressive Web Apps - PWA Roadshow(https://youtu.be/z2JgN6Ae-Bo?t=166)
オレンジ色(左上)がネイティブアプリで青色(右下)がWebです。また縦軸のCapabilityはできること、Reachはどれだけの人に届くかという指標です。見ていただければわかるのですが、ネイティブはできることが多く、リーチ力が弱い。Webはリーチ力が強く、できることが少ない。PWAはこのふたつの指標をどちらも満たす可能性があります。
PWAはWebにおけるUXの目指す姿でもあります。
すでにご存知の方もいらっしゃるかもしれませんが、FIREという指標が存在します。これは、「Fast、Integrated、Reliable、Engaging」の頭文字を取ったものです。今ではFIREはWebについての指標という扱いになっていますが、以前はPWAの指標でした(PWAのときはIntegratedを除く3つ)。筆者はこの扱いの変化から、GoogleはPWAで目指していたことをWebの当たり前にしたいのではないのかと考えます。
ではFIREについて軽く解説します。まずFIREを構成する4単語を筆者は次のように訳しています。
・Fast:速さ
・Integrated:デバイスへの統合
・Reliable:動作の信頼性
・Engaging:魅力的であること
それぞれ少し紹介します。
Fastは文字通り速さです。これは読み込みのスピードやスムーズに操作できるという速さを表しています。
IntegratedはWebアプリケーションの体験をデバイスに合わせることです。たとえば、PWAの特徴とも言えるホーム画面からの起動です。ホーム画面にWebアプリケーションを追加することで、ユーザーはブラウザーを起動しなくてもホーム画面にいるアイコンをタップし、Webアプリケーションを利用できます。ホーム画面に配置されていることでネイティブアプリケーション同様の起動体験を提供できます。
Reliableは動作の信頼性です。これは主にネットワーク接続についての信頼性を示しています。ネットワークに接続していないと起動できないアプリケーションをユーザーはどう思うでしょうか?せっかくホーム画面に追加しているのに起動できないアプリケーションを、アプリケーションと認めてもらえるでしょうか?少し言い過ぎかもしれませんが、Reliableはこのように「アプリケーションが常に開ける」という信頼性に関する指標になります。
Engagingはアプリケーションの体験が魅力的であることです。どのようなアプリケーションが魅力的であると言えるでしょうか?サイトにアクセスた時、いきなりプッシュ通知を許可しますか?と聞いてくるサイトは魅力的でしょうか?答えはもちろん違います。これはユーザーが意図していない動作です。このような意図していない動作・機能ではなく、ユーザーの意図通りに動かせる快適なアプリケーションを作ろうという指標になります。
この4つを突き詰めるとWebアプリケーションとしてのUXが高まります。FIREを意識して開発することはユーザーへの思いやりとも言えるかもしれません。
PWAのチェックリストをGoogleが公開しています。
https://developers.google.com/web/progressive-web-apps/checklist
このチェックリストはベースラインとその他の気にすべき項目が列挙されています。またテスト方法とその項目を満たすための方法も書かれています。このベースラインを満たすことがPWAとしての第一歩となります。ベースラインを翻訳すると次の内容になっています。
・HTTPSで配信されている
・レスポンシブ対応
・すべてのURLがオフラインで読み込み可能
・ホーム画面に追加するためのメタデータ(Web App Manifest)が用意されている
・3G環境だったとしても最初のアクセスは高速に読み込まれる
・クロスブラウザーで動作する
・ネットワークに依存しないページ遷移
・すべてのページに一意のURLが存在する
これらの一部のテストはLighthouse(https://github.com/GoogleChrome/lighthouse)というツールで機械的にテストすることができます。このLighthouseは、Chrome Developer Toolsに組み込まれています。次の画像はChrome Developer Toolsのスクリーンショットです。Lighthouseは右上のAuditsパネルから使うことができます。
真ん中のProgressive Web Appにチェックを付けて下部の「Run audits」というボタンを押すとテストが実行されます。このテストを実行すると次の画像のように100点満点で点数をつけてくれます。
本書のサンプルコードのサイトの結果(https://try-pwa.mya-ake.org/)
画像の「Passed audits」がLighthouseが機械的にテストする項目です。ベースラインのチェックリストの項目に加えて、HTTPからHTTPSへのリダイレクトテストなども行います。その上の「Additional items to manually check」はベースラインのチェックリストに存在してますが、Lighthouseで機械的にテストできない項目です。「クロスブラウザーで動作する」「ネットワークに依存しないページ遷移」「すべてのページにURLが存在する」の3つがテストできていません。これらのテストは別のツールを使うか、手動でテストを行う必要があります。
筆者の場合は次のようにテストしています。
・クロスブラウザーでの動作は手動でテスト
─Brwosersyncを使い、開発しながら同時にチェック(レイアウト崩れもチェック)
・ネットワークに依存しないページ遷移も手動でテスト
─オフライン周りの処理を作成した時にチェック
・すべてのページにURLが存在するかは手動でテスト
─そもそもURLがいないサイト設計にしないことが重要
つまりほぼ手動ですね。この辺りも自動化したいところですが、よい方法があれば情報をいただければ嬉しいです。
このように、ベースラインについてはLighthouseを使い手軽にチェックできます。LighthouseのPWAの項目で緑(75〜100点)になっていればPWAと言えるでしょう。
ベースラインのより細かなチェック項目は大きく分けて次の6つです。
・Googleインデックスされやすいか
・UX
・パフォーマンス
・キャッシュ
・プッシュ通知
・その他
─Credential Management API
─Payment Request API
これらについては、PWAをより極めたいときに参照してみると、よりよい体験をユーザーに提供できるかもしれません。
Google DevelopersのPWAのサイト(https://developers.google.com/web/progressive
-web-apps/)には、PWAは「Web上で驚くべきユーザーUXを提供する新しい方法」と書かれています。またFIREやPWAのチェックリストなどは、いずれもUXに行き着くものです。つまり、PWAはWebにおけるUXを向上するための取り組みのひとつです。
また、PWAはスマートフォンに限った話ではなくなりつつあります。Chromeのバージョン73からPCでもPWAとしてWebアプリケーションをインストールできます。筆者自身もTwitter LiteをmacOSにインストールして利用しています。今後業務アプリケーションなどデスクトップ向けのアプリケーションをPWAとして提供する事例が出てくるかもしれません。
本章の冒頭で、PWAはネイティブアプリとWebのいいとこ取りをしたものと表現しました。これだけを見ると、ネイティブアプリがいらないように見えるかもしれませんが、そんなことはありません。PWAはあくまでもブラウザーにできる以上のことはできません。最近はブラウザーでできることも増えてきましたが、それでもできることは限られています。
たとえば、デバイスに近い機能はブラウザーで提供されている範囲でしか使えません。デスクトップPWAの場合は、ファイルアクセス(書き込み)ができません。ファイルアクセスをするにはElectronなどのデスクトップアプリケーションを作るためのフレームワークなどを利用するのがよいでしょう。
※Google ChromeではFileSystem APIの実装が進んでおり、Google Chromeでは将来的にファイルシステムが扱えるようになります。
このように、PWAがあれば既存のアプリケーションを代替できるわけではありません。あくまでアプリケーションを作る上での選択肢のひとつと捉えてください。
ページ数の都合上、PWAの活用の仕方やメリット・デメリットといったテーマは割愛します。ただ活用の仕方などについては、筆者が以前登壇した際の資料に記載しています。次のURLで公開されているのでご興味のある方はそちらをご覧ください。
https://mya-ake.com/slides/pwa-will-provide-future-web