PWA 対応戦略と現実解 / PWA strategy and realistic solution

PWA 対応戦略と現実解 / PWA strategy and realistic solution

2018年8月23日に開催された Bonfire Frontend #2 https://yj-meetup.connpass.com/event/97695/ の「PWA 対応戦略と現実解」のセッション資料です。

0d605a3350dd7e91b8136aecffd5ceeb?s=128

Shogo Sensui

August 23, 2018
Tweet

Transcript

  1. 6.

    Progressive Web Apps Checklist Baseline • HTTPS でホストされている • レスポンシブである

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

    HTTPS Service Worker High Performance Cache First Push Notification Works

    on offline Cross Browser Web App Manifest Installable Responsive Web PWA Dependency Tree
  3. 9.

    何はともあれ、まずは HTTPS 化 • Web の HTTPS 化は避けて通れない ◦ ユーザーの意識に関わらず「安全である」ことは最も重要

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

    パフォーマンスに関して • まずはロードパフォーマンスを最適化する ◦ ユーザーの体験順序・対コスト効果の両面 ◦ ランタイムパフォーマンスは、 (比較的)問題になりにくい • パフォーマンス最適化による恩恵

    ◦ コンバージョンの向上 ◦ アクセシビリティの向上 ◦ SEO における優位性 • HTTPS 化が済んでいればやることは数手 ◦ Service Worker で静的アセットをまるっとキャッシュする ◦ 結合していたファイルをバラして HTTP/2 化する ◦ 超速本の2章、3章、8章、9章を読む
  5. 11.

    Web App Manifest の導入 • パフォーマンスを充分に最適化してからで良い(と、思っている) ◦ パフォーマンスが悪い Web ページをインストールしたくない

    …よね • HTTPS 化が済んでいれば、あとは簡単 ◦ 規定サイズの Web ページのアイコンを用意する ◦ manifest.json ファイルを用意して <link rel=”manifest”> で参照する ◦ PWACompat: the Web App Manifest for all browsers • インストールバナーの表示は計画的に ◦ Changes to Add to Home Screen Behavior
  6. 13.

    キャッシュファーストとオフライン • 静的アセットは優先的にキャッシュを参照する ◦ Service Worker の fetch イベント +

    Cache API ◦ HTTP Header の Cache-Control: Immutable ◦ ロードのパフォーマンスだけでなく、インフラへの負荷も減る • 余力があればオフラインでも利用できるように ◦ 適用できるかは Web アプリケーションそのものの性質に依存する
  7. 14.

    Web Push でエンゲージメント • ユーザーにとって必要な情報を通知する ◦ この前提がないと通知を送るどころか許可してもらえない ◦ その情報がユーザーにとって価値があるかどうか •

    Web Push もあくまで付加的な機能として捉える ◦ 様々な不確定要素がつきまとう ▪ ブラウザの実装状況、パーミッションの設定状況 ▪ そもそも許可してもらえるかわからない ◦ あると便利だけど、なくても価値を提供できる設計に • FRESH! での導入例 ◦ FRESH! における Web プッシュ通知機能 〜機能設計編〜 ◦ FRESH! における Web プッシュ通知機能 〜実装編〜
  8. 16.

    まとめ • 依存関係と対費用効果をよく考える ◦ 技術要件において、どんな依存関係があるか ▪ HTTPS → Service Worker

    + Web App Manifest ◦ サービス要件おいて、何をやって何をやらないか ▪ オフライン対応は必要なのか ▪ プッシュ通知は適しているか • 実装しておしまいではなく、運用をよく考える ◦ PWA としてメンテナンスし続ける必要がある ▪ 特にパフォーマンス、オフライン、 Web Push あたり ◦ それぞれを配慮できる開発者知識と組織体制が必要