PWAは来る!絶対来る! (自分がアプリ作れないからwebの技術でやりたいだけ)

ということでgoogle主催のPWA勉強会に参加してきましたー。

https://events.withgoogle.com/pwa-roadshow-tokyo-2017/

内容としては、前半のPWAセッションでたくさん知識を詰め込まれ、後半のコードラボで実際に書いて触って復習して身につけるといった感じのステキな勉強会でした。

SERVICE WORKERのサの字も知らなかった私としては非常に勉強になりました。(PEACE WALKERじゃないよ)

会場が映画館みたいw

f:id:aoma23:20170923134814j:plain

以下はいつものメモと写真です。

9:30am キーノート: Progressive Web Apps: What, Why and How

スピーカー:ロバート

f:id:aoma23:20170923132712j:plain

ajaxの革命。google mapsなどが可能となった。

ネイティブアプリがwebを上回った。使用時間。

  • 13% mobile web
  • 87% native app

PWA

素晴らしいユーザーエクスペリエンス

4つのポイント。FIREと呼ばれている。

  • Fast
  • Integrate
  • Reliable
  • Engaging

Fast

  • 3秒以上かかるサイトはユーザーの53%が離脱する
  • ページが読み込まれていないので離脱したことも計測できない

Integrate

  • webで支払いもできるようになった
  • 再生もホーム画面でできる

Reliable

  • webはネットにつながっていないといけない
    • chrome恐竜が出てきてはダメ
  • Lie-Fi
    • 繋がってると思ってるけどデータが入ってこないのがLie-Fi

Engaging

  • webからPUSH通知ができるようになった

PWAの例

  • Twitter lite
    • PUSH通知
    • 写真撮影して投稿
    • アプリに比べサイズ

Servise Workers

  • js。ネット接続する前にキャッシュを使用する
  • クライアントサイドのプロキシ
  • PUSH通知など、さまざまなことができる

PWAをはじめるアプローチ

3つのおすすめ

  • from the ground up
    • ゼロからデザイン
  • a simple version
    • 一部の機能、ページ
  • a single feature
    • 重要な部分のみ。PUSH通知のみとか

10:00am セッション 1: Integrated Experiences

スピーカー:Eiji

f:id:aoma23:20170923132808j:plain ※写真撮り忘れたのでピートの時のでw

ホーム画面に追加

  • 80%

    • ホーム画面のアプリを意図的に移動したユーザー
  • Web App Manifest

    • home画面にどう見せるか
    • 起動画面がどうなのか
    • といったことを定義できる
  • ホーム画面に追加するよう促す仕様はブラウザごとに異なる

    • chromeの場合
      • Web App Manifest
      • Offline support(with servise worker)
      • Engaged User
        • 何度もユーザーが訪れたときに促す。たまたま来た時は出さないようになっている

Web Payment(お金を支払う)

  • 66%がwebで行われている。(ネイティブアプリではない)

    • ただしデスクトップとスマホで、スマホのコンバージョン率は1/3ほど。
  • スマホでユーザー情報を入力するのが手間。なので家に帰ってデスクトップでやる。改善すべき。

    • Autofill
    • autocomplete属性
      • inputタグに属性追加するだけ。非常に手軽にできる
  • でも結局はフォームとユーザーの戦い。これを劇的に改善したい。
    • PaymentRequest API
      • フォーム不要。全てのサイトで同じUX
      • 注意!あくまでフォームの代わりとなるもの。お金のやりとりをするところまでを解決するわけではない
      • jsで書く。上記のこともあり金額は文字列。計算する場合はjsでガリガリ書く必要あり
      • promissでPaymentResponseでユーザー情報が帰ってくる。この情報をサーバーやpaymentゲートウェイに渡して処理する(支払い可能か)

10:25am セッション 2: Reliable Experiences

スピーカー:ピート

f:id:aoma23:20170923133008j:plain

必要なときにネットに繋がらないとユーザーの信頼性を失う

Service Worker

  • サービスワーカーは2回目から働く
  • 1回目はたたずんでいる。idle。
  • 非同期のリクエストでアップデートバージョンがあるか聞きに行く

実装

  • register
  • install
  • activate
    • 古くなった情報は消したい。キャッシュキーにマッチしないものは削除
    • fetch event handler
      • キャッシュにリクエストがあればそれを返す
    • Scope
      • サービスワーカーがどのページを管理するか。
      • 1ページや複数指定など高度な指定もできるが、まずはルートから指定がおすすめ
      • sevice-worker.jsを指定することになる。script/ディレクトリに入っているとindex.htmlやimageがキャッシュされないのでsevice-worker.jsはルートに置くとよさげ。

キャッシュとネットワークの関係性

  • コントロールすることができる。サービスによって判断する必要がある
    • キャッシュとネットワーク同時に行く
    • まずキャッシュのデータをユーザーに見せる
    • その後ネットワークで更新があれば新しい情報を準備
    • ユーザーのアクションを待って最新情報を表示

Tool

  • chrome dev tools
    • 何か問題が起きたらストレージなど全てにチェックを入れてリフレッシュする
  • Workbox

11:00am 休憩

11:15am セッション 3: Engaging Experiences

スピーカー:Alex

f:id:aoma23:20170923133540j:plain

ユーザーに再びアプリを使ってもらうために。

Web Push Notifications

通知を見て、時間の無駄となるのはサイテー

重要な3つのポイント

  • timely
  • precise(中断して見ても良いものであるべき)
  • personal(パーソナル化している)

通知許可をユーザーが拒否したら2度とチャンスはない

そのためまず独自に通知必要かを確認し、実際の通知許可を出す。

12:00pm セッション 4: Secure Experience

スピーカー:kosamari

f:id:aoma23:20170923132917j:plain

httpsであるメリット

  • Identity
  • Confidentiality
  • Integrity

httpsにする上での懸念

  • そもそもhttpsにする必要ある?

    • Man-in-the-Middle Attacks
      • フィッシング攻撃を防げる
  • パフォーマンス問題

    • httpsを確率するために3往復必要。工夫すれば削減できる
    • HTTP/2

コスト

  • 証明書

    • let’s encrypt
      • 無料
  • search ranking

    • 同じサイトで別URLあると良くない
      • httpは301でhttpsにリダイレクトするように
      • canonicalタグ

Maintenance

12:30pm ランチ

f:id:aoma23:20170923133638j:plain

選べる喜び。

f:id:aoma23:20170923133651j:plain

1:30pm セッション 5: Tooling - Lighthouse and Beyond

スピーカー:ケース

f:id:aoma23:20170923133751j:plain

Lighthouse

  • PWAページのパフォーマンス解析

Service Workerとchrome dev tools

networkパネル

from service-worker となっていればキャッシュから取って来ている

Applicationパネル

  • Service Workersの操作ができる

    • Offlineにしたり最新のService Workerにアップデートしたりできる
    • サービスワーカーをOFF(常にネットワークを見る)ようにしたり
    • どのファイルがいつキャッシュされたかといったことも確認できる
  • Manifestのテストもできる

2:00pm コードラボ

f:id:aoma23:20170923133845j:plain

4:30pm セッション 6: AMP

スピーカー:Yoshi

f:id:aoma23:20170923134432j:plain

PWAは2回目以降を早くしたい

1回目から早くするためにAMP

77%のサイトが10秒以上かかっている(リクエストが200超えてたり、、Adとか)

AMP

Start fast, Stay fast

スクロールできないとか、ページ読み込んだあと画面上部に広告挿入されたりとかをなくしたいというモチベーションがある

  • AMP HTML
    • タグの中にイナズマの絵文字</li> </ul> </li>
    • AMP JS
      • ビューポートを計算しファーストビューの表示を第一に考える
      • 画像の遅延ロードとかもよしなにやる。そのためのamp-img
      • amp-imgにwidthとheight必須なのは画面全体のレイアウトを把握するため
    • AMP Cache
      • HTTP2とか裏側でやってる?から早くなったり。(一般的に普及してないから対応した的な)
    • </ul>

      AMPとService Worker

      <amp-install-serviceworker>

      AMPページでサービスワーカーをインストール。 AMPページからリンク押した時にすでにServiceWorkerがページをキャッシュしておく。だから高速。

      3つのパターン

      • AMP as PWA
        • AMPそのものをPWAに
      • AMP to PWA
        • AMPからPWAのページへ遷移させる。
      • AMP in PWA
        • PWAの中の要素をAMPで。(AMPをコンテンツとして使う)
          • iframe
            • 遅くなる(AMPを複数読み込んだ際、jsとかも重複して読まれるため)
          • Shadow DOM
            • こちらがおすすめ

      5:00pm クロージング

      f:id:aoma23:20170923134521j:plain

      Future Web APIs

      • Credential Management API

        • サインインを改善
          • ID,passを入力するのをやめる
          • 別のデバイスでも解決
          • One-tap
          • Auto
      • WebVR

      • Web Assembly
      • and more…

      5:10pm オープン Q&A

      • 通知はユーザーが設定拒否したら次はないが、ホームに追加はどうか。

        • 2度目ある。ユーザーが、
          • ウィンドウの×を押すと14日後
          • 拒否を洗濯すると90日後
        • 今後変わる必要あり
      • PWAはアプリと同じようにアンインストールが可能。ストレージも消える。

      • PWAはアナリティクスで解析できますか?

        • 可能。workbox.jsにライブラリがある。オフライン時のアクションを取っておいてオンライン時に送信。
      • service worker v2で熱い機能

        • バックグラウンド
          • オフラインで書いたメールをオンラインになった時に送信
        • サイレント通知
          • ファイルのダウンロードとか?

      5:45pm 閉会

      お疲れ様でした。ありがとうございました!

Updated: