$30 off During Our Annual Pro Sale. View Details »

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 対応戦略と現実解」のセッション資料です。

Shogo Sensui

August 23, 2018
Tweet

More Decks by Shogo Sensui

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide