DevTools でパフォーマンス チューニング入門 ~ Webサイトのボトルネック、今と昔 ~ 1 株式会社ラクーンホールディングス 技術戦略部 羽山純

自己紹介 ● 名前 ○ 羽山 純（Jun Hayama） ● 所属 ○ 株式会社ラクーンホールディングス 技術戦略部 ● 技術領域 ○ バックエンド・インフラ ○ パフォーマンス改善 ○ AI（企業審査AI） ● 個人活動 ○ アプリ開発 2

アジェンダ ● 今と昔のWebサイト表示パフォーマンスの違い ● DevTools を利用したボトルネックの探し方 3

今と昔のWebサイト表示パフォーマンスの違い 4

バックエンド 処理 今と昔ではボトルネックが変化 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% ● 時代の中央値を表した模式図で、厳密ではありません ○ 今と昔でボトルネックの違いを比較します ● どちらが速いという趣旨ではありません

バックエンド 処理 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 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 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 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生成

ボトルネックはブラウザのメインスレッド メインスレッドでしかできない処理が多数あります ● HTMLのパース（DOM構築） ● スタイルシートのパース（CSSOM構築） ○ UI表現の高度化 ● JavaScript の実行 ○ CSR（クライアントサイドレンダリング） ○ 外部 SaaS ツールのスクリプト埋め込みによる機能拡張 結果、今はほぼブラウザのメインスレッドがボトルネックです そこで Chrome DevTools が登場します 10

DevTools を利用したボトルネックの探し方 11

DevTools でパフォーマンスの計測 12 1. 計測対象ページで DevTools > Performance を開きます 2. Start profiling and reload page を押して計測スタート ※ Disable JavaScript samples をチェックすると情報は減りますが、全体の見通 しは良くなります ① ※ ②

Performance 分析結果の概要 13 Main に着目します これらはメイン以外の 処理スレッド等です メイン以外で実行可能な 処理を担当します

HTMLのパース 14 HTMLドキュメントが約80ms で転送されています 青色はHTMLパース処理です マウスで選択すると処理時間や 処理対象が表示されます 158~1470行目の解析を 36.78ms かけて実行してます Total Time を参照します

JavaScriptの実行（同期/インライン/非同期） 15 HTMLパースを停止して実行 HTMLパース中に実行 HTMLパースとは独立して実行 同期/インライン/非同期にかかわらず、メインスレッドで実行さ れます インライン スクリプト 同期スクリプト 非同期スクリプト

メインスレッドを俯瞰する 16 JavaScript の実行（オレンジ色）が 259ms で、 最もメインスレッドを占有しています Load イベントは 259ms 分だけ遅延します Loadイベント

表示を遅延させる犯人捜し Evaluate Script のうち、横幅の長いものを選択します それがメインスレッドを占有する犯人です 17 横幅を広げて見やすくしましょう

表示を遅延させる犯人捜し 18 マウスで選択すると Summary に 詳細が表示されます マウスでホバー/クリックすると、 なんのスクリプトか分かります メインスレッドを 50ms 占有するのはページ表示が 50ms 遅延す るのと同じ意味です Google Analytics のスクリプトに 47.51ms かかっています

ブラウザの拡張機能はメインスレッドで動作します 拡張機能を無効化したシークレットウインドウ(Ctrl-Shift-N)を 利用しましょう ブラウザの拡張機能に注意！！ 19 55.90 ms 実行しているスクリプト の正体はブラウザの拡張機能

実際にチューニングした例 ①で 50ms の処理が5回実行されていました 外部サービスのスクリプト だったので、調整して削除したところ 50ms × 5 = 250ms のパフォーマンス改善しました 20 1

実際にチューニングした例 それ以外のスクリプトも整理したところ ページ表示速度が 約1.5秒 → 約1.0秒 に改善しました （※RUM で Loadイベント発火までの時間を計測） 参考: Raccoon TechBlog 広告タグを整理してWebサイトのパフォーマンスを改善した話 21 元々は約1.5秒 約1.0秒まで改善

サイト速度の計測は？ サイト速度の計測にはタグマネージャと GA4 を利用しています 無料で RUM（Real User Monitoring）ができるのでオススメです 参考: Raccoon TechBlog [GA4] Google Analytics 4 でサイト速度を計測する方法 22

まとめ 今はブラウザ側のパフォーマンスを見ないとダメですよ 慣れが大切なのでまずは DevTools を触ってみましょう！ 23

24 ご清聴ありがとうございました