このページの中身

速度の指標

速さは手元の1回で測るものではなく、実際の利用者の75パーセンタイルで測るものです。見る指標は3つです。

LCP・CLS・INPの3指標と、良好・要改善・不良のしきい値を示した図
図を大きく見る
図の中身を文字で読む
  • 3つとも「実際の利用者の75パーセンタイル」で判定する。手元の1回の計測ではない。
  • LCP　最大の要素が表示されるまで　＝ 読み込みの体感速度
  • 良好 2.5秒以下　要改善 4.0秒まで　不良　主犯はたいてい画像とWebフォント
  • CLS　表示のずれの累積量　＝ 押そうとした場所が動く不快さ
  • 良好 0.1以下　要改善 0.25まで　不良　主犯は width/height 未指定の画像と広告枠
  • INP　操作してから画面が応える時間　＝ 反応の速さ
  • 良好 200ms以下　要改善 500msまで　不良　主犯は長く走り続けるJavaScript
  • ずれ（CLS）はこうして起きる
  • 読み込み中　→　→　img に width と height を書くと、
  • 見出しが上にある　画像が後から入り　見出しが押し下げられる　ブラウザが場所を先に確保する。

ひと目で#

Core Web Vitals
LCP、CLS、INP の3つ。実際の利用者の75パーセンタイルで判定する
LCP
いちばん大きな要素が表示されるまで。読み込みの体感
CLS
表示のずれの累積。押そうとした場所が動く不快さ
INP
操作してから画面が応えるまで。反応の速さ
TTFB
サーバーの最初の1バイトが届くまで。LCP の一部

しきい値#

指標良好要改善主な原因
LCP2.5秒以下4.0秒まで画像、Webフォント、サーバーの応答
CLS0.1以下0.25まで寸法を書いていない画像、あとから差し込まれる要素
INP200ms以下500msまで長く走り続ける JavaScript

使い分け#

こういうとき見るもの
実際の利用者の状態を知りたいフィールドデータ。Chrome UX Report、実測ツール
原因を特定して直したいラボデータ。Lighthouse、開発者ツール
表示が遅いLCP。画像とフォントから
押そうとしたらずれるCLS。画像の width / height
押しても反応がないINP。JavaScript の実行時間

手元の1回と、利用者の分布#

手元で測ると、速い回線と新しい端末とキャッシュ済みの状態が重なります。その1点は分布のいちばん速い端にあり、判定に使われる線とは別の場所にあります。

手元の1回の計測値と、実際の利用者の分布および75パーセンタイルの位置を比べた図
図を大きく見る
図の中身を文字で読む
  • 同じページの LCP を、手元と実際の利用者で見比べる
  • 手元で1回（ラボ）　1.4秒　実際の利用者（フィールド）
  • 速い回線・新しい端末・キャッシュ済み。　75パーセンタイル 3.1秒
  • この1点だけを見て「速い」と判断してしまう。　遅い側に裾が伸びる。判定に使われるのはこの線。
  • 4人に1人はこれより遅い体験をしている。
  • ラボは原因を特定するための道具。合否を決めるのはフィールドの分布。
  • ラボで直したあと、フィールドの分布が動くまでには数週間かかる。

75パーセンタイルで判定するというのは、4人に1人はその数値より遅い体験をしているという意味です。平均でも中央値でもないので、少数の遅い端末を切り捨てられません。

左にLighthouseのラボ計測結果、右にSearch Consoleの実利用者の分布を並べた実画面
図を大きく見る

手元で開くのが Lighthouse（左）、実際の利用者の分布が見られるのが Search Console の「ウェブに関する主な指標」（右）です。同じページでも数値は揃いません。直すときはラボを見て、合否はフィールドで判断します。

間違えやすいところ#

開発者ツールで測る#

Lighthouse は点数を出すだけで、どの画像が LCP だったか、どの要素がずれたかまでは分かりません。原因を名指しするには Performance タブを使います。F12 で開発者ツールを開いて、3手順です。

手順やること分かること
1Performance タブの歯車で、回線を「低速4G」、CPU を「4×slowdown」にする手元の速さの下駄を外す
2再読み込みの矢印を押して記録し、止まったら停止するTimings の帯に LCP の印が立つ
3LCP の印を押し、下の Summary で「Related Node」を開く遅らせている要素そのものが画面上で光る

CLS はこの記録の中の Experience 行に赤い帯として出ます。その帯を押すと、ずれた要素と移動量が出ます。INP は読み込み中には出ないので、記録したまま実際に押したりスクロールしたりします。

手を入れたあと、同じ手順でもう一度測ります。 フィールドの分布が動くまでには数週間かかるので、直後の答え合わせはここで済ませます。

直す例#

架空の案件を1つ例にとります。どこを見て、何をどう直すかを書きます。

飲食店サイトの計測結果です。手元の Lighthouse は緑で、担当者は「速い」と報告していました。Search Console を開くと、スマートフォンの LCP が要改善に入っています。手元は光回線、来店客は移動中の電波です。

Performance タブで回線を「低速4G」、CPU を4倍遅くして記録し直します。LCP の印を押すと、犯人はヒーロー写真ではなく、その上に置いた 380KB のロゴ PNG でした。写真は fetchpriority="high" で先に取りに行かせてあり、ロゴだけが後回しになっていません。

同じ記録の Experience 行に赤い帯もありました。予約ボタンの下に、あとから読み込まれる営業時間の枠が入り、押そうとした瞬間にボタンが下がります。枠の高さを先に確保するだけで、この赤い帯は消えます。

コピーする#

ずれを作らない置き方です。中身が届く前に、場所だけ先に取ります。

このコードで動いている見本です

このコードで動いている見本です

確認する#

使えるパターン#

この話が要る場面#

このページが答えになる、現場の困り事です。困り事の側から探すと、同じ場所に着きます。

読み込み中に画面が飛ぶ

img に width と height を書く。ブラウザが場所を先に確保する。

このコードで動いている見本です

速度を測ったが数値が毎回違う

手元の1回は当てにならない。実際の利用者の75パーセンタイルで見る。

75パーセンタイル（p75）で見る

Lighthouseのスコアは上がったのに体感が変わらない

ラボの数値と実利用者の分布は別物。Search Console のウェブに関する主な指標を見る。

Search Console の Core Web Vitals を確認

操作しても反応がない時間がある

INPが悪い。長く走るJavaScriptを分割し、その画面で使わないコードを送らない。

このコードで動いている見本です

この場面のほかの困り事と、そのまま貼れる部品は速くするにまとめてある。逆引きには全188件。

出典#

関連#

この資料は、Webサイトを作るときに引くためのものです。 何のために作ったか。作っているのは AK²Lab。