PWA 対応戦略と現実解 Bonfire_Frontend #2 Shogo Sensui (@1000ch)

Shogo Sensui (@1000ch) Software Engineer Merpay, Inc. / Mercari, Inc.

「信用を創造して、なめらかな社会を創る」

Progressive Web Apps 先進的な Web アプリを目指す標榜

みなさんどうやって PWA 対応していますか？ とりあえずの Service Worker? Workbox?

Progressive Web Apps Checklist Baseline ● HTTPS でホストされている ● レスポンシブである ● 全ての URL がオフラインでも動作する ● メタデータが配信されている ● 3G 環境でも高速にロードできる ● クロスブラウザで動作する ● 全てのページに URL がある ● etc… Advanced ● インストールを不当に要求しない ● キャッシュファーストである ● ロード時にページがガタつかない ● 戻ったときにスクロール位置も復帰する ● 全画面モードでもシェアしやすい ● オフライン時にそれを伝えている ● プッシュ通知を適切に配信している ● プッシュ通知の管理 UI を提供している ● etc...

HTTPS Service Worker High Performance Cache First Push Notification Works on offline Cross Browser Web App Manifest Installable Responsive Web PWA Dependency Tree

まずは基本となるこの3つ Secure, High Performance, Installable

何はともあれ、まずは HTTPS 化 ● Web の HTTPS 化は避けて通れない ○ ユーザーの意識に関わらず「安全である」ことは最も重要 ○ Service Worker をはじめ、Web の様々な機能が HTTPS 前提になりつつある ○ 「HTTP でも良い」という考えは、もはや牧歌的 ○ ブラウザ UI での警告、Google のページランクにおける不利、 etc ● PWA というコンテキストにおいて ○ 「安全な Web ページ」の達成はもちろんのこと ○ PWA の基盤となる Service Worker を使う上での前提条件 ● 既存の大規模 HTTP ページの場合は… ○ Yahoo! JAPAN、はてな、アメブロなどを見習う

パフォーマンスに関して ● まずはロードパフォーマンスを最適化する ○ ユーザーの体験順序・対コスト効果の両面 ○ ランタイムパフォーマンスは、 (比較的)問題になりにくい ● パフォーマンス最適化による恩恵 ○ コンバージョンの向上 ○ アクセシビリティの向上 ○ SEO における優位性 ● HTTPS 化が済んでいればやることは数手 ○ Service Worker で静的アセットをまるっとキャッシュする ○ 結合していたファイルをバラして HTTP/2 化する ○ 超速本の2章、3章、8章、9章を読む

Web App Manifest の導入 ● パフォーマンスを充分に最適化してからで良い（と、思っている） ○ パフォーマンスが悪い Web ページをインストールしたくない …よね ● HTTPS 化が済んでいれば、あとは簡単 ○ 規定サイズの Web ページのアイコンを用意する ○ manifest.json ファイルを用意して で参照する ○ PWACompat: the Web App Manifest for all browsers ● インストールバナーの表示は計画的に ○ Changes to Add to Home Screen Behavior

基本ができたらあと2つ Offline (Cache-First), Engaging

キャッシュファーストとオフライン ● 静的アセットは優先的にキャッシュを参照する ○ Service Worker の fetch イベント + Cache API ○ HTTP Header の Cache-Control: Immutable ○ ロードのパフォーマンスだけでなく、インフラへの負荷も減る ● 余力があればオフラインでも利用できるように ○ 適用できるかは Web アプリケーションそのものの性質に依存する

Web Push でエンゲージメント ● ユーザーにとって必要な情報を通知する ○ この前提がないと通知を送るどころか許可してもらえない ○ その情報がユーザーにとって価値があるかどうか ● Web Push もあくまで付加的な機能として捉える ○ 様々な不確定要素がつきまとう ■ ブラウザの実装状況、パーミッションの設定状況 ■ そもそも許可してもらえるかわからない ○ あると便利だけど、なくても価値を提供できる設計に ● FRESH! での導入例 ○ FRESH! における Web プッシュ通知機能 〜機能設計編〜 ○ FRESH! における Web プッシュ通知機能 〜実装編〜

ここまで出来たら たぶん(?)アプリと遜色ない あとは残りのチェック項目を実践していくだけ

まとめ ● 依存関係と対費用効果をよく考える ○ 技術要件において、どんな依存関係があるか ■ HTTPS → Service Worker + Web App Manifest ○ サービス要件おいて、何をやって何をやらないか ■ オフライン対応は必要なのか ■ プッシュ通知は適しているか ● 実装しておしまいではなく、運用をよく考える ○ PWA としてメンテナンスし続ける必要がある ■ 特にパフォーマンス、オフライン、 Web Push あたり ○ それぞれを配慮できる開発者知識と組織体制が必要