この記事は Google I/O '19 のセッションの視聴メモです。
想定読者は自分なので正確性や網羅率には問題があるかもしれません。

References

Speaker(s): Mariko Kosaka

Abstract

"レスポンシブデザイン"というものが何であれ近頃のほとんどのWebアプリケーションは小さい画面でタッチパネルも持たないフィーチャーフォンで使い物になりません。このセッションでは計算資源に乏しいそういった端末でも素早くスムーズに動くWebアプリケーションを実装するための懸念事項とチップスを紹介します。

Contents

2019年から2021年の間に3億7000万台ものスマートフィーチャーフォンが販売されると見込まれている
スマートフィーチャーフォンとは？
- New Operation System - such as KaiOS
- 最新のブラウザ
- スクリーンは240px x 320 px
- D-padで操作
Proxx.app
- 2019年のマインスイーパ
- あらゆるデバイスで動くよ
- マウス・キーボード・タッチ・d-pad・スクリーンリーダーで操作できる
- 3Gでも5秒以下で表示され、60fpsのアニメーション
コードは次の3つに分かれる → Game Logic / UI & State Services / Rendering
- Game Logic は Web Worker で動いてる
- 通信は Comlink で行っている
ロードを早くするためにPuppeteerを用いて Build time Pre-render を行っている
- 普通に Puppeteer でレンダリングした結果をindex.htmlにまとめてサーブしているっぽい
- 結構簡単そう（下記のコード）

build-time-pre-render

const browser = puppeteer.launch();
ocnst page = browser.newPage();
await page.got(`http://localhost:${port}/?prerender`);

const markup = page.evaluate(() => document.documentElement.outerHTML);

fs.writeFileSync("index.html", `<!doctype html>${markup}`);

Graphics

はじめはDOMですべて解決しようとした
- テーブルにボタンを並べれば終わりでしょ？
- CSSアニメーションを入れまくったら一つのセルをアップデートするだけでテーブル全体が再描画されてしまいパフォーマンス上の問題が発生した
セルごとにレイヤーを分けた
- レイヤーが多くなりすぎてそれはそれで問題になった
Canvasで描画するようにした
- 2つのCanvasを使用し、1つはバックグラウンドアニメーションでもう1つはゲームのアニメーションを表示した
- requestAnimationFrame でブラウザの準備が整ったときに次のJSの処理を呼ぶ
詳しくはブログで
- https://developers.google.com/web/updates/2018/09/inside-browser-part1
アニメーションはSpriteイメージだが、生成はフロントで行っている
- 生成されたイメージはIndexed DBに保存されている
実はDOMは残っている
- ユーザーからの入力は見えないテーブルとボタンが取得している
- opacity=0だがフォーカスはできる
- ネイティブアクセシビリティをそのまま使えるので便利
- ボイスオーバー機能すらほぼそのままブラウザのものを使える
アクセシビリティに関しての詳細はこちら
- https://web.dev/accessible
デバイスがアニメーションに対応しているかどうかを見てWebGLアニメーションを使うかCanvasの静的な描画を使うかを分けている

Input devices

主な操作は次の2つ → Open or Add Flag
ダブルクリックはシングルクリックに遅れを生じさせるので採用しなかった
フィーチャーフォンでアクセスした場合は数字キーで操作できるようにした

Code splitting

index.html は 20KB しかない
- アニメーションは別ファイルで80KBほどある
- すべて読み込まれたらアニメーションが再生されるが、その前からユーザーは入力できる
Rollup を使ってファイルを分けている
Webpackを使った場合、comlink.jsが2つに分かれてしまう
index.htmlを小さくしたPR
- https://github.com/GoogleChromeLabs/proxx/pull/337
TravisCIでビルド後のファイルサイズを監視していた
とにかく、はじめにいらない情報以外はすべてなくすことが重要

Memo

Puppeteer で build time Pre-render を行うという発想はなかった
実はDOMを残していてAccesibilityはブラウザ標準のものをそのまま使える → すごい
全体的にAccesibilityに対する努力がすごい
なにげに19分30秒あたりのソースコードの行ハイライトするスライドのアニメーションがわかりやすい