Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
DevTools でパフォーマンスチューニング入門 / Introduction to Per...
Search
forrep
December 11, 2023
2
360
DevTools でパフォーマンスチューニング入門 / Introduction to Performance Tuning with DevTools
今と昔のWebサイトパフォーマンスの違いと Chrome DevTools を利用したフロントエンドのパフォーマンスチューニング入門
forrep
December 11, 2023
Tweet
Share
More Decks by forrep
See All by forrep
Linux && Docker 研修/Linux && Docker training
forrep
24
4.5k
RAGにベクトルDBは必要ない!DBも不要で運用めちゃ楽な RAG Chatbot を作った話
forrep
35
14k
Google Analytics でサイト速度を計測する / Measure site speed with Google Analytics
forrep
2
260
最近コードレビューで指摘したこと
forrep
3
440
「プログラマーのためのCPU入門」は入り口として丁度よい!
forrep
47
31k
技術的負債に対する視力を得る / How to View Technical Debt
forrep
0
630
しくじり先生 - NFS+sqliteで苦労した話から学ぶ、問題解決の考え方 / problem-solving approach
forrep
1
1.1k
理屈で考える、データベースのチューニング / Database tuning How-To
forrep
28
8.8k
ブラウザの制約条件から考えるフロントエンドのリソース設計/Frontend Performance How to
forrep
2
750
Featured
See All Featured
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
4
330
Git: the NoSQL Database
bkeepers
PRO
427
64k
Building Applications with DynamoDB
mza
93
6.2k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
27
1.9k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
193
16k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
How GitHub (no longer) Works
holman
314
140k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Transcript
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 ご清聴ありがとうございました