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