Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

forrep
December 11, 2023
210

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

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

forrep

December 11, 2023
Tweet

Transcript

  1. 自己紹介 • 名前 ◦ 羽山 純(Jun Hayama) • 所属 ◦

    株式会社ラクーンホールディングス 技術戦略部 • 技術領域 ◦ バックエンド・インフラ ◦ パフォーマンス改善 ◦ AI(企業審査AI) • 個人活動 ◦ アプリ開発 2
  2. バックエンド 処理 今と昔ではボトルネックが変化 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% • 時代の中央値を表した模式図で、厳密ではありません ◦ 今と昔でボトルネックの違いを比較します • どちらが速いという趣旨ではありません
  3. バックエンド 処理 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は保護されない問題
  4. バックエンド 処理 バックエンド処理の変化 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 によりバックエンド処理の簡易化
  5. バックエンド 処理 リソース転送の変化 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 による効率的な転送
  6. バックエンド 処理 ブラウザのメインスレッドの役割拡大 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生成
  7. ボトルネックはブラウザのメインスレッド メインスレッドでしかできない処理が多数あります • HTMLのパース(DOM構築) • スタイルシートのパース(CSSOM構築) ◦ UI表現の高度化 • JavaScript

    の実行 ◦ CSR(クライアントサイドレンダリング) ◦ 外部 SaaS ツールのスクリプト埋め込みによる機能拡張 結果、今はほぼブラウザのメインスレッドがボトルネックです そこで Chrome DevTools が登場します 10
  8. DevTools でパフォーマンスの計測 12 1. 計測対象ページで DevTools > Performance を開きます 2.

    Start profiling and reload page を押して計測スタート ※ Disable JavaScript samples をチェックすると情報は減りますが、全体の見通 しは良くなります ① ※ ②
  9. 実際にチューニングした例 それ以外のスクリプトも整理したところ ページ表示速度が 約1.5秒 → 約1.0秒 に改善しました (※RUM で Loadイベント発火までの時間を計測)

    参考: Raccoon TechBlog 広告タグを整理してWebサイトのパフォーマンスを改善した話 21 元々は約1.5秒 約1.0秒まで改善