指標から理解する Web Performance
shin_k_2281Webサイトにおけるパフォーマンスの良し悪しは、そのWebサイトのユーザーの体験を決定づける非常に重要な要素となります。
高速かつ応答性の高いWebサイトはユーザーの満足度を高め、結果としてサイトの成功に大きく貢献します。反対に、ページロードが遅い / 要素をクリックした後の反応が遅い / スクロールが重たい ...などの症状が見られるWebサイトにおけるユーザーの離脱率は分析をする以前に明らかでしょう。
Googleの調査によると、サイトの読み込みに3秒以上かかると訪問者の53%がサイトを離れるそうです。
UXの父、Jakob Nielsenは以下のように言っています。
0.1 seconds (100 ms) creates the illusion of instantaneous response — that is, the outcome feels like it was caused by the user, not the computer. ...
1 second allows the user to maintain a seamless flow of thought. ...
10 seconds is the maximum delay before the user's attention drifts.
これほど重要であるウェブパフォーマンスを最適化するためには、まずはそのパフォーマンスをどのように測定するか、それぞれの測定指標が何を意味するのか理解することが不可欠です。
このスクラップでは、Webパフォーマンスの測定において中心的な役割を果たす「Core Web Vitals」とその他の重要なパフォーマンス指標に焦点を当て、それぞれがどのようにWebサイトのユーザーエクスペリエンスに影響を与えるかを読み解いていきたいと思います。
shin_k_2281Core Web Vitals とは何か
「Core Web Vitals」は、Googleが提唱するウェブページのパフォーマンスを測定するための3つの指標です。これらは、以下3つの指標によって構成されます。（それぞれの具体的な測定内容は後述します。）
- LCP(Largest Contentful Paint)
- FID(First Input Delay)
- CLS(Cumulative Layout Shift)
これらの指標は、ウェブサイトの実際のユーザーエクスペリエンスをより正確に反映するように設計されており、サイトのパフォーマンス改善において不可欠な役割を果たします。
また、冒頭のドキュメントにも示されている通りSEOにおいても重要な役割を担っています。
余談: INP について
近年のCore Web Vitalsを語る上で外せない指標として INP(Interaction Next Paint) というものがあります。
これは2024年の3月より、FIDに変わるCore Web Vitals指標として1年以上前からGoogleチームによって議論されてきたものです。
詳細はまた後述しますが、INPが代わりに導入される理由は、FIDを重要指標とした時に挙げられる問題点にあります。
FIDはブログにも書かれている通り、クリックイベントなどの「ユーザーインタラクションの最初の部分」に焦点が当てられています。
つまりFIDはインタラクションからそれに応じたイベントハンドラの処理の開始までの時間です。
一方INPはインタラクションから、イベントハンドラの発火まで + イベントハンドラの処理とUIへの結果の反映というところまでを含みます。
このような処理部分までを重要指標として含むようになった理由については
重要な点は、実際のユーザーによるページ操作方法により、ページの TBT や TTI が遅くてもレスポンシブであると認識される可能性があることです。
のようにある通り「結果的にインタラクション後のブロッキング処理が長く、見た目上ユーザーへの応答が遅いように見えていても、内部的にはイベントハンドラが発火しているため素早く応答を返している。」と判断されてしまうことにあるように感じました。
shin_k_2281Core Web Vitals が SEO に与える影響
Google のコア ランキング システムは、優れたページ エクスペリエンスを提供するコンテンツを高く評価するように設計されています。
つまり、Core Web Vitals評価が高いWebページがSEOにおいても優位に働き、検索結果の上位に検索されるようGoogleによって設計が行われているということです。（ただ、Core Web Vitalsだけでなく、SEOとしてのWebサイトの評価にはその他多くの状況や改善が影響します。）
プロダクトの運用においては、Google Search Consoleなどのツール使ってSEOを監視することが多いと思いますが、このコンソール上でもCore Web Vitalsの低下によって影響が出ている箇所を特定することができます。
shin_k_2281Largest Contentful Paint（LCP）⭐
視覚的な最大コンテンツの表示時間。
ページ内におけるブロック要素の中で最も読み込み容量が大きい箇所を評価対象とします。
初回描画後の読み込みに関する指標としては、First Contentful PaintやSpeed Indexなどが推奨されていましたが、これらの複雑な指標よりも、ページの最大の要素をメインコンテンツとして読み込まれたタイミングを補足するほうがよりシンプルで適切という判断になりました。
サイトのロード時間を示す指標として、Core Web Vitalsに入っています。
shin_k_2281First Input Delay（FID）⭐
ユーザーがページ内のコンテンツを操作（クリック、ホバー...etc）してから、のその操作に応じてブラウザが実際にイベント ハンドラの処理を開始するまでの時間。
サイトの応答性を示す指標として、Core Web Vitalsに入っていたが、先述したような理由により2024年3月からはINPに置き換わります。
shin_k_2281Interaction to Next Paint（INP）⭐
FIDと似ていて、ユーザーがページ内のコンテンツを操作（クリック、ホバー...etc）してから、それに対するフィードバックに関して測定する指標であるところは同じです。
違うのはイベントハンドラの発火までではなく、視覚的な変化までを含めた全体的な応答性を評価するものです。
最終的な INP 値は、検出された最も長いインタラクションで、外れ値は無視されます。
shin_k_2281Cumulative Layout Shift（CLS）⭐
ユーザーがページに滞在する間に発生する予期しないレイアウトシフトごとに、そのレイアウトシフトの最大移動量を測定するものです。
Lighthouseなどの計測においてCLSの低下は、他の指標よりもより大きくマイナスポイントとして影響します。
サイトの視覚的な安定性を示す指標としてCore Web Vitalsに入っています。
shin_k_2281(ここからはCore Web Vitalsには含まれないものの重要となる指標。)
First Contentful Paint（FCP）
LCPと一緒に考えるとわかりやすいです。
ページが全てロードされるまでにはポイントごとに指標の名前がついている。LCPはページ内の最大コンテンツが表示されるまでだったが、FCPは最初の何かが表示されるまでとなっています。
shin_k_2281Time To Interactive（TTI）
これもページロード時の流れの図を見るとわかりやすいですが、その図で言うと一番最後に書かれています。
これはページ内の何らかの要素がインタラクション可能になった（クリックだったり文字入力だったり）タイミングを指します。
これは主にSSRを行っているアプリケーションなどで、ページ自体は見えているもののハイドレーション処理がボトルネックになっていて操作が行えない、などのがTTIが影響を及ぼしているケースとして考えられます。
shin_k_2281Total Blocking Time（TBT）
ページロード時、最初の要素が表示されて(FCP)後から、入力に応答できる(TTI)までの間にメインスレッドをブロックしたトータルの時間を表します。
50msを超えて実行されたタスクがある場合、それをブロッキングタイムとしてTBTに加算する仕組みです。
shin_k_2281Time To First Byte（TTFB）
ページリソースをネットワークリクエストしてから、そのレスポンスの最初のデータ（byte）が到着するまでの時間を測定する指標です。
ナビゲーションだけでなく全てのリソースリクエストに適用されます。
これは主にネットワークレイテンシと関係していて、サーバーとの物理的な処理やバックエンド側でのDB処理等が影響している可能性があります。
shin_k_2281SI (Speed Index)
Speed IndexはATFの表示性能を数値化したもので、ページロードの経過時間に対するコンテンツのレンダリング量をプロットし、レンダリングされなかった領域面積をスコア化します。
これも値が小さいほど優れていることを表します。
ATF(Above the fold)スクロールせずに閲覧可能な画面領域を表す。
→BTF(Below the fold) はそれ以外の領域
例えば初期表示に不要なモジュールはDynamic Importなどを検討することで、SIの値の改善につながります。
shin_k_2281まとめ
バラバラと色々な指標を紹介してきましたが、これらの指標の捉え方については、URLを打ち込んでWebページが表示されるまでの一連の流れを意識するとわかりやすいです。
-
ネットワーク処理
a. サーバーから配信される各種リソースをブラウザがダウンロードする処理 -
レンダリング処理
b. HTMLとCSSに基づいて要素をレイアウトする一連の処理 -
スクリプト処理
c. 主にJavaScriptによるランタイム処理を指す
これらのタイミングごとに、関連する指標を以下の図のように分割して考えると計測や分析がしやすいと思います。
実際のWebアプリケーションにおけるパフォーマンス改善ではこのようなことを頭に入れておき、問題のある箇所が一体どのような処理によって引き起こされるのか仮説を立ててから改善に取り組むと良いと思いました。