光を超えるためのフロントエンドアーキテクチャ
16msの世界
Cache Awareな設計
設計パターン
光が遅い
国内：20ms〜
アメリカ西海岸：120ms〜
260ms〜
ハードウェアの性能
ディスプレイ
60 ~ 144Hz
VRゴーグル 90~Hz
人の知覚
70 ~ 100Hz
技術の目的
リッチクライアントの技術で60fpsを達成
通信を含めて、遅延・ペイロードを可能な限り抑える
遅延を分類する
300〜ms：遅く感じる
1000〜ms：遅い、不満
裏で先読みしておくと速い
この時あまりサーバーアーキテクチャは関与しない
なぜ既存のものは遅かったのか
Cache Awareな設計
https://gyazo.com/c98872f9591b35da6f3cb9e2b34a1694
参照系は単純なキャッシュルールで返す
更新系のフックでキャッシュを破棄
キャッシュにセッション依存情報をつかわない
キャッシュの組成は集合で考える
懸念：キャッシュ破棄が複雑では？
Varnish Surrogate Keys
動的なEdge
小規模開発者に意味があるのか？
規模はあまり関係ない
使うかも知れないデータを先読み
preload
resource-hints
HTTP/2 Server Push
単純に対象をfetch(endpoint)飛ばしておくだけでも効果あり
<link rel="preload"> をheadに挿入
prefetchでpreloadを挿入
大規模なデータがあるひとは試してみるといい
現実
賢い先読み範囲をコンテキストを考慮し、職人的に記述すること
アーキテクチャをしっかりしておく（コードをきれいに書こう）
16ms未満
途切れず連続していると感jる更新頻度
インメモリ or バックグランド処理
スクリプティング抑制
単純につかうライブラリの量を減らす
lodash
moment.js
貧弱なCPUで効果大
オフスレッド退避
スクリプティングを抑制させる
手段
Dynamic Import
Webpack
Code Spritting
Dead Code Elimination
静的解析して定数畳み込み
レイアウト抑制
要素幅を変更すると親方向を再計算
スケルトンスクリーン
CSSインライン化
画像
width height 必須
明示的な layout="responsive" 指定
マイクロチューニングの現実
実際にはこれらの複合で問題が発生
高頻度イベント＋レイアウト再計算
フレームワーク特有の事情
低遅延環境のための設計パターン
常にリクエスト成功したことにする
裏で失敗したらロールバック（前に戻る）
使い所
正常系にネットワーク上の分岐がない場合
ログインフロー
Like Button
記事やコメントの投稿
クライアントファースト設計
https://gyazo.com/e93da1d5c89fb9f4c3aca0004977f2f4
クライアントでのデータ処理を優先する
サーバーは単にsyncされるだけ
別途集約系APIを用意しておく
使い所
扱うデータが自己完結しているとき
ゲームとか
問題
チートなどのデータ改ざんに弱い
P2Pでの相互監視などが必要
off the main thred
UI Thread以外に処理を逃がそう