Zenn
Open9

mizchiさんのパフォーマンスチューニングイベントに関するメモ

shirasudshirasud

書籍では学べないノウハウがここにはあった…！
アーカイブもあるので全Webエンジニア、インフラエンジニア見た方がいい内容だと思う

たまにNetworkタブを見るくらいしかしてない自分のふわっと知識レベルでは正直、初見ですべては理解できなかったけどポイントを押さえ実際に分析をしてみて少しでもモノにしたい

shirasudshirasud

LAPRASさんの事前勉強会

https://www.youtube.com/watch?v=rZmbnNn79LE

この動画を知ったのは当日なので、アーカイブ見たのは事後になる

  • CoreWebVitals
  • Lighthouseスコア
  • ブラウザレンダリングの流れ
  • 頻出（かも）ワード

Figjamまで公開してくれている…！

CoreWebVitals

Googleがユーザー体験を評価するために定めた重要なパフォーマンス指標



  • 初期ロード時
    • LCP (Largest Contentful Paint)
      • ユーザーがページにアクセスしてから、ビューポートに表示される最大のコンテンツ（画像やテキストやブロックなど）が描画されるまでの時間
    • CLS (Cumulative Layout Shift)
      • ページの表示中に発生する予期しないレイアウトの移動を影響度で数値化したもの
  • ユーザー操作時
    • INP (Interaction to Next Paint) … ※ これはlighthouseでは計測できない
      • ユーザーによるページアクセスの全期間中に発生するすべてのクリック、タップ、キーボード操作などのインタラクションに対する応答性。FIDの後続（First Input Delay）

補足

  • 現時点でCoreWebVitalsがSEOにどういう影響を与えてるかAIに聞いてみた

結論としては、影響度は小。CoreWebVitalsのようなラボデータよりも、従来のSEO対策のようなフィールドデータの方が強いらしい（どんなに高速なページでもユーザーニーズがないとスコア上がらないはそれはそう）

ただ、フィールドデータを元にCoreWebVitalsが定められているので決して軽視していいものではない

Lighthouseスコア

ラボデータなので、通信環境などでスコアが全くことなるので注意

  • LCP (Largest Contentful Paint)
  • CLS (Cumulative Layout Shift)
  • FCP (First Contentful Pain)
    • ユーザーがページにアクセスしてから最初の要素が画面に表示されるまでの時間
  • TBT (Total Blocking Time) … 200ms以内が良好な値
    • https://web.dev/articles/tbt?hl=ja
    • メインスレッドがブロックされて、ユーザーがページを操作できない合計時間。FCPからTTI（Time To Interactive）までに発生する50ms以上の長いタスクによってメインスレッドがどれだけ長くブロックされているかを示す
  • Speed Index … 3.4s以内が良好な値

ブラウザレンダリングの流れ

ざっくりブラウザがページをレンダリングするまでの流れ

https://speakerdeck.com/recruitengineers/browser-9b5a2b70-4b6a-4108-a1f5-0876a3ceb8d0
https://web.dev/articles/howbrowserswork?hl=ja

Rendering Engineは今はBlink

レンダリングプロセス

レンダリングエンジンによって若干プロセスが異なる

頻出（かも）ワード

勉強会当日に出そうなワードを確認する

shirasudshirasud

mizchiさんのjsconfの資料より頭に入れとくと良さそうなもの

前提として頭に入れとくとよさそうな内容を抜粋
自分で分析試してみる時もこの辺を改めてみながら進める

https://mizchi-20241123-jsconfjp.pages.dev

以下、スライド

shirasudshirasud

mizchiさんによる「LAPRAS 公開パフォーマンスチューニング」~調査編~

https://www.youtube.com/watch?v=j0MtGpJX81E

おおまかな流れ

  • 本日の期待値と事前知識
  • 実践・パフォーマンス計測
  • Network request blocking を使用した調査
  • Override Content でAPIの応答やcssを書き換える
  • Webpack chunk / bundle analyzer 周りのお話
  • 答え合わせ-事前に行った調査の結果の共有
  • まとめTALK
  • 番外編 - フロントエンドの計測においてソースコードはノイズにもなり得る

本日の期待値と事前知識

https://web.dev/articles/preload-scanner?hl=ja

メインスレッドで行われているHTML Parserとは別に、全体をガーッと見にいくプリロードスキャナというものが存在する。SPAでは初回ロードで含まれてないソースがあるけど、Viteとかがプリロードヘッダーを挿入してくれてるから、バンドル解析の結果ここ絶対先にくるみたいなものを読んでくれている（へぇー）

実践・パフォーマンス計測

どういう手順で分析していくか

  • Lighthouse
  • Performance
  • network

Lighthouse

デフォルト設定でまずはぶん回す

できれば分析用のChrome拡張すら入ってない状態で回した方が良い
プライベートブラウザでの検証がおすすめだけど、localStorageが使えないなど特有の差分には注意

Treemapを見てアセットの実行比率を確認する

Webpackのバンドルアナライザーのようなものは「View Treemap」から見ることができる

DIANOSTICSを確認する

一般的に言えそうなことが重要度が高いものから順に列挙されている

フッターがCLSのスコアを下げている要因になっていることが一例として紹介されている

メインコンテンツが遅延読み込みな都合上、ファーストビューでチラッとフッターが見えるが故にこっちを優先して読み込むような処理が走ってしまっている

全部をみる必要はないけど、LCPの要素は確認しておいた方がいい
（ただ、ここを最適化すれば良いというわけではない）

shirasudshirasud

Performanceタブを見る

日本だと以下のスロットリングで見ると良いらしい
あまりにも遅い場合は検証に支障が出るのでスロットリングを外す

詳細なデータがたくさんあるけど、問題がどの辺にありそうかの仮説をもって読まないと読めない

LCPが1番大事。LCPに至るまでに何が起きているか前後を探る

例ではバナーのところでレイアウトシフト起きてるねとか

Networkも大事。Networkタブと違ってタイミングも見ている

縦軸がラウンドトリップ。これを減らすことが高速化のポイント
下図の青いやつなど、リクエストが折り返されているものも見ることができる

MainはCPUに起因するもの

赤いものがロングタスク（CPU処理は1タスクあたり16msになるのが理想？）
初期化はどうしてもCPUバウンドになるけどその後のロングタスクはよろしくない
レイアウトジャンクといってスクロールしている時に止まるみたいな体験の悪化につながる

SPAのページとかはParseHTMLを見ておいた方が良い
HTMLがレンダリングされるまでに何が起きているか内訳が見れる

ソースマップを注入することで、(anonymouse)の内部が見れたりするけどそこまで優先度は高くない

shirasudshirasud

Networkタブをみる

右クリックで「waterfall」が表示できる。おそらく赤い線がLCP？

TBTが重い時、Sizeでソートする
Service Workerでキャッシュしてると見えないことがあるかも

次にTimeで見る。APIレスポンスが重いやつが見れる
Queueingは他のリクエストが多いから待ち時間が発生しているやつ

Fetch/XHRはTimeで見て他は、Sizeで見ることが多い

shirasudshirasud

Network request blocking を使用した調査

サードパーティJSなどをブロッキングして純粋なページパフォーマンスを見る

APIをブロッキングしてエラーハンドリング実際にできてるかのチェックも良さそう
パス指定でもいけるしドメイン自体をブロックすることもできる

shirasudshirasud

Override Content でAPIの応答やcssを書き換える

Networkタブなどコンテキストメニューから「Override Content」で使える

ここで作ったファイルはローカルに保存されるので検証中に間違えてブラウザ閉じちゃったとかでも再開できるのが地味にありがたそう

ユースケースとしてはAPIモック、CSSを上書きしてCLSが解消されるかチェックする時など
JSも上書きできるから開発環境だと検証しづらいちょっとしたやつを差し込むとかもあり？
HTMLタグを上書きしてdeferやasyncつけたり、重そうな特定の要素外してみたりもできる

動画の中で注意点としてあったのは

  • リクエストしたものを上書きしてるだけだからリクエスト自体は発生してる
  • 普通に見たい時に設定切るの忘れるとおま環になる
shirasudshirasud

Webpack chunk / bundle analyzer 周りのお話

Webpack chunk

チャンクが細かすぎるかも？という指摘。Webpack Chunk Sizeの設定がそうなっちゃってるかも
細かすぎると逆に悪化しちゃう可能性もありえる

Bundle Analyzer

lodashがでかい、重複している。依存経路を見ておいた方がいいらしい

# 依存経路の確認
yarn why lodash/npm explain lodash

ツリーシェイクをしてくれるライブラリとそうじゃないものがある？
マイナーなライブラリだとこの辺りやってくれないものもあるそう

package.jsonメンテできてるかとか普段どれだけいいコード書いてこれたかがTBTに現れる

補足：それぞれについてPerplexityに聞いてみた