DevTools でパフォーマンスチューニング入門 / Introduction to Performance Tuning with DevTools

今と昔のWebサイトパフォーマンスの違いと Chrome DevTools を利用したフロントエンドのパフォーマンスチューニング入門

1. DevTools でパフォーマンス チューニング入門 ~ Webサイトのボトルネック、今と昔 ~ 1 株式会社ラクーンホールディングス 技術戦略部 羽山純
2. 自己紹介 • 名前 ◦ 羽山 純（Jun Hayama） • 所属 ◦ 株式会社ラクーンホールディングス 技術戦略部 • 技術領域 ◦ バックエンド・インフラ ◦ パフォーマンス改善 ◦ AI（企業審査AI） • 個人活動 ◦ アプリ開発 2
3. アジェンダ • 今と昔のWebサイト表示パフォーマンスの違い • DevTools を利用したボトルネックの探し方 3
4. 今と昔のWebサイト表示パフォーマンスの違い 4
5. バックエンド 処理 今と昔ではボトルネックが変化 5 TLS ハンド シェイク TCP 接続 TCP 接続 データフェッチ リソース転送 リソース転送 ブラウザ メインスレッド ブラウザ メインスレッド 昔のWebサイト（2010年代 前半くらいまで） 今のWebサイト（2023年 現在） バックエンド処理 データフェッチ 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% • 時代の中央値を表した模式図で、厳密ではありません ◦ 今と昔でボトルネックの違いを比較します • どちらが速いという趣旨ではありません
6. バックエンド 処理 TCP接続とTLSハンドシェイク 6 TLS ハンド シェイク TCP 接続 TCP 接続 データフェッチ リソース転送 リソース転送 ブラウザ メインスレッド ブラウザ メインスレッド (昔) (今) バックエンド処理 データフェッチ 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% • TCP接続は今も昔も変わらず（※一部サイトを除く） • 今後 HTTP/3.0 の普及で変化の兆し（UDP化） • TLSハンドシェイクの時間分が純増 ◦ 昔は http が主流、ログインのみ https を利用 ◦ セッションIDは保護されない問題
7. バックエンド 処理 バックエンド処理の変化 7 TLS ハンド シェイク TCP 接続 TCP 接続 データフェッチ リソース転送 リソース転送 ブラウザ メインスレッド ブラウザ メインスレッド (昔) (今) バックエンド処理 データフェッチ 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% • 昔はバックエンドがデータフェッチ（DB）を実行 ◦ HTML生成はバックエンドの仕事（SSR） • 今はバックエンドの役割が大幅縮小 ◦ CSR によりバックエンド処理の簡易化
8. バックエンド 処理 リソース転送の変化 8 TLS ハンド シェイク TCP 接続 TCP 接続 データフェッチ リソース転送 リソース転送 ブラウザ メインスレッド ブラウザ メインスレッド (昔) (今) バックエンド処理 データフェッチ 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% • 昔はリソースが少なめ、しかし転送効率は低い ◦ HTTP/1.1 による同時転送数の制限（6接続/ホスト） • 今はリソースが肥大化、しかし転送効率はUP ◦ CSS/JS/画像 の巨大化、Webフォントの利用 ◦ バックエンド軽量化のため、転送が早期に開始 ◦ HTTP/2.0 による効率的な転送
9. バックエンド 処理 ブラウザのメインスレッドの役割拡大 9 TLS ハンド シェイク TCP 接続 TCP 接続 データフェッチ リソース転送 リソース転送 ブラウザ メインスレッド ブラウザ メインスレッド (昔) (今) バックエンド処理 データフェッチ 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% • 昔は転送されたHTMLをパースして表示するだけ ◦ JavaScript は軽微な利用のみ、DOM生成をほとんどしない • 今はブラウザのメインスレッドの役割が拡大 ◦ CSR（クライアントサイドレンダリング） ◦ データフェッチ後にDOM生成
10. ボトルネックはブラウザのメインスレッド メインスレッドでしかできない処理が多数あります • HTMLのパース（DOM構築） • スタイルシートのパース（CSSOM構築） ◦ UI表現の高度化 • JavaScript の実行 ◦ CSR（クライアントサイドレンダリング） ◦ 外部 SaaS ツールのスクリプト埋め込みによる機能拡張 結果、今はほぼブラウザのメインスレッドがボトルネックです そこで Chrome DevTools が登場します 10
11. DevTools を利用したボトルネックの探し方 11
12. DevTools でパフォーマンスの計測 12 1. 計測対象ページで DevTools > Performance を開きます 2. Start profiling and reload page を押して計測スタート ※ Disable JavaScript samples をチェックすると情報は減りますが、全体の見通 しは良くなります ① ※ ②
13. Performance 分析結果の概要 13 Main に着目します これらはメイン以外の 処理スレッド等です メイン以外で実行可能な 処理を担当します
14. HTMLのパース 14 HTMLドキュメントが約80ms で転送されています 青色はHTMLパース処理です マウスで選択すると処理時間や 処理対象が表示されます 158~1470行目の解析を 36.78ms かけて実行してます Total Time を参照します
15. JavaScriptの実行（同期/インライン/非同期） 15 HTMLパースを停止して実行 HTMLパース中に実行 HTMLパースとは独立して実行 同期/インライン/非同期にかかわらず、メインスレッドで実行さ れます インライン スクリプト 同期スクリプト 非同期スクリプト
16. メインスレッドを俯瞰する 16 JavaScript の実行（オレンジ色）が 259ms で、 最もメインスレッドを占有しています Load イベントは 259ms 分だけ遅延します Loadイベント
17. 表示を遅延させる犯人捜し Evaluate Script のうち、横幅の長いものを選択します それがメインスレッドを占有する犯人です 17 横幅を広げて見やすくしましょう
18. 表示を遅延させる犯人捜し 18 マウスで選択すると Summary に 詳細が表示されます マウスでホバー/クリックすると、 なんのスクリプトか分かります メインスレッドを 50ms 占有するのはページ表示が 50ms 遅延す るのと同じ意味です Google Analytics のスクリプトに 47.51ms かかっています
19. ブラウザの拡張機能はメインスレッドで動作します 拡張機能を無効化したシークレットウインドウ(Ctrl-Shift-N)を 利用しましょう ブラウザの拡張機能に注意！！ 19 55.90 ms 実行しているスクリプト の正体はブラウザの拡張機能
20. 実際にチューニングした例 ①で 50ms の処理が5回実行されていました 外部サービスのスクリプト だったので、調整して削除したところ 50ms × 5 = 250ms のパフォーマンス改善しました 20 1
21. 実際にチューニングした例 それ以外のスクリプトも整理したところ ページ表示速度が 約1.5秒 → 約1.0秒 に改善しました （※RUM で Loadイベント発火までの時間を計測） 参考: Raccoon TechBlog 広告タグを整理してWebサイトのパフォーマンスを改善した話 21 元々は約1.5秒 約1.0秒まで改善
22. サイト速度の計測は？ サイト速度の計測にはタグマネージャと GA4 を利用しています 無料で RUM（Real User Monitoring）ができるのでオススメです 参考: Raccoon TechBlog [GA4] Google Analytics 4 でサイト速度を計測する方法 22
23. まとめ 今はブラウザ側のパフォーマンスを見ないとダメですよ 慣れが大切なのでまずは DevTools を触ってみましょう！ 23
24. 24 ご清聴ありがとうございました