フロントエンドの
パフォーマンス改善
フロントエンドエンジニア@大阪
今日するお話
Agenda
フロントエンドのパフォーマンス
パフォーマンス is 何
フロントエンドのパフォーマンス
- ファーストビュー
- アクセスしてから実際に表示されるまでの時間
- ランタイム
- UI操作やアニメーションの実行パフォーマンス
フロントエンドのパフォーマンス
- ファーストビュー
- アクセスしてから実際に表示されるまでの時間
-
ランタイム
- UI操作やアニメーションの実行パフォーマンス
今日はこっちの話
ファーストビュー
アクセス
開始
完了
ほとんどのサイトは遅い
-
モバイルサイトの平均読み込み時間は15秒（Google, 2018）
- 3秒超えると諦めて戻るモバイルユーザが53%（Google）
- 1秒ごとにユーザが10%減少（BBC）
- 読み込み時間は検索エンジンのランキングなどにも使われる
- 減点方式
- 遅いと表示順位下げられる
→ 速度改善を目指していこう！
計測する
パフォーマンスの測り方
- Lighthouse
- Googleの速度改善提案ツール
- 細かいメトリクスと具体的提案
- ChromeのDevTool → Auditタブ
- 最初はこれで十分すぎる
- 極めるならより高度なツールへ
Lighthouseは便利
- スコア化してくれる
- わかりやすい
- 改善提案をしてくれる
- 参考程度だが…
- 方向性は見える
よく出てくるメトリクス
- First Contentful Paint
- テキストなどのコンテンツ表示開始タイミング
- Largest Contentful Paint
- 一番大きなコンテンツが表示されたタイミング
-
First Meaningful Paint（deprecated）
- ユーザにとって意味ある表示になったタイミング
- Time To Interactive
- ユーザが操作できるようになったタイミング
メトリクス
Time To Interactive
Largest Contentful Paint
First Contentful Paint
First Contentful Paint
パフォーマンス改善
だいたい酷いスコアになる
がんばって改善する
パフォーマンス改善の勘所
-
秒単位で最適化する
- 大きなボトルネックから潰す
-
必要最低限しか読み込まない
- 遅延読み込み、Tree Shakingなどを活用
-
先に実行を済ませる or あとで実行する
- SSRする、タスクキューに積むなどする
改善箇所の明確化
- どこを改善したいかで使う技術が違ってくる
- First Paint
- ファイル圧縮や遅延読み込み系など
- First Meaningful Paint / Largest Contentful Paint
- Server Side Renderingなど
- Time To Interactive
- off-the-main-threadなど
クリティカルレンダリングパス
- データを受信からピクセルの描画までの工程のこと
- データの読み込み
- パース
- スクリプトの実行
- CSSの適用
- ……
- 描画
- これを妨害しないように作ると表示が速くなる
パフォーマンス改善の例
例えばこれらで改善する場合がある（しないことも…）
- <script defer>
- <img loading="lazy">
- Intersection Observer
- dynamic import
- Server Side Rendering
- Static Site Generator
さいごに
まずは測るだけでいい
- Lighthouseで測って、意識しよう
- ただ意識するだけで物事の見方はだいぶ違ってくる
- 意識が違ってくれば改善にも目がいくようになる
- ボタンを押すだけなので、とりあえず測ろう！
まとめ
- ファーストビューのパフォーマンス大事
- Lighthouseで簡単に測れる
- いろんなメトリクスがある
- 改善したいメトリクスに応じた適切な技術選択
- まずは測って、考えるのはその後にしよう
参考資料
- パフォーマンスが重要なのはなぜか | Web Fundamentals | Google Developers
-
Performance audits