Cloudflareの実ユーザー計測が、LCPを4段階・INPを3段階に分けて見せるようになった。直す前に、いちばん長い段階を決める ── 自社の遅さがどの段階で起きているかを確認する13項目（2026年10月時点）

目次

1. 01 何が起きたか — Cloudflareの実ユーザー計測が、LCPを4つの段階に、INPを3つの段階に分けて見せるようになった
   1. Cloudflareの更新履歴が、2026年10月13日に知らせた
   2. LCPは4つの段階、INPは3つの段階
   3. 接続の時間も、TCPとTLSに分かれた
   4. 見られる場所と、数字の約束事
2. 02 なぜ・背景 — 「遅い」と分かっても、直す場所は段階を見るまで決まらない
   1. 良い・悪いの判定は、すでに別の記事にある
   2. 段階の分け方は、web.devに先に書かれていた
   3. 段階は重ならず、足すと全体になる
   4. 1か所を速くしても、時間が別の段階に移るだけのことがある
   5. 目安の割合は、時間ではなく、段階どうしの比べ方
3. 03 用語 — 段階の話で出てくる言葉を、先にそろえる
   1. 実ユーザー計測と、手元の計測
   2. LCPの要素と、LCPの資源
   3. パーセンタイルと、メインスレッド
4. 04 型別 — 自社がどれに当たり、何を、どの順で確かめるか
   1. 🅰 型A — すでにCloudflareのWeb Analyticsを使っているサイト
   2. 🅱 型B — Cloudflareを通していないサイト
   3. 🅲 型C — 訪問が少ないサイト
   4. 🅳 型D — 制作会社・代理店で、顧客のサイトの遅さを報告する担当
   5. 手順1 — 遅いと言われたページと端末を1つに決め、数字の出どころを書く
   6. 手順2 — LCPの4つの段階を出して、いちばん長いものに丸を付ける
   7. 手順3 — 長い段階ごとに、最初に見る場所を決める
   8. 読み込み開始の遅れ：LCPの画像は、最初のHTMLに書いてあるか
   9. 描画の遅れ：画面を描くのを止めているものを数える
   10. 最初のバイトまで：転送と、キャッシュと、サーバーの時間
   11. 手順4 — INPの3つの段階を出して、いちばん長いものに丸を付ける
   12. 手順5 — 直したあとに、縮んだ段階と、増えた段階を比べる
   13. 手順6 — 数字を、実ユーザーと手元に分けて、報告に書く
   14. 手順7 — 日付・ページ・端末・段階の数字を1行にして、次の確認日を決める
   15. 公式が書いていないこと
5. 05 自分のサイトで確認するチェックリスト
6. 06 代替・他の選択肢 — 段階を出す道具を、使い分ける
   1. 4つの道具の比較
   2. web-vitalsライブラリの「attribution版」で、自分で集める
   3. PageSpeed Insightsは、数字の出どころを分けて見る入口
   4. いまは段階を読まない、という選択
7. 07 当サイトで確かめたこと
   1. 読んだ公式の文章と、その日付
   2. 当サイトでは、Cloudflareの画面を見ていない
   3. 当サイトで測ったのは、最初のバイトまでの目安だけ
8. 08 このテーマの、これまで
   1. 日付つきの記録
9. 09 この記事のまとめ

01 何が起きたか — Cloudflareの実ユーザー計測が、LCPを4つの段階に、INPを3つの段階に分けて見せるようになった

Cloudflareの更新履歴が、2026年10月13日に知らせた

Cloudflareの開発者向け文書の更新履歴に、「Deeper Core Web Vitals Diagnostics: LCP & INP Sub-Part Metrics in Real User Monitoring」（訳: より深いCore Web Vitalsの診断：実ユーザー計測でのLCPとINPのサブパートの指標）という記事がある。ページには「October 13, 2026」と表示されている。2026年10月15日に開いて読んだ。中心になる文は、次のとおりである。

"To help you with this, Real User Monitoring (RUM) in Web Analytics now breaks Largest Contentful Paint (LCP) and Interaction to Next Paint (INP) into their respective sub-parts."

（訳: これを助けるために、Web Analyticsの実ユーザー計測（RUM）は、Largest Contentful Paint（LCP）とInteraction to Next Paint（INP）を、それぞれのサブパートに分けて見せるようになった。）

「これ」とは、直前の文によると、Core Web Vitalsが「遅い」とは教えても、問題のある場所までは直接示さないことである。つまり、「遅い」を、原因の段階に分けて見られるようになった。この記事は、画面を見て書いたものではなく、公式の文書を読んで書いている。当サイトはCloudflareを使っていないため、この機能の画面も見ていない（07章に分けて書いた）。

LCPは4つの段階、INPは3つの段階

段階の名前と、公式の説明の要旨、データを取り出すときの項目名（GraphQLの項目名）を、表にした。

段階（公式の名前）	公式の説明の要旨	GraphQLの項目名
LCP：Time to First Byte	ブラウザがHTMLの文書を待つ時間	timeToFirstByte
LCP：Resource load delay	文書が届き始めてから、LCPの資源（画像など）をブラウザが見つけるまでの時間	lcpResourceLoadDelay
LCP：Resource load duration	その資源をダウンロードするのにかかる時間	lcpResourceLoadTime
LCP：Element render delay	資源が届いてから、要素が画面に現れるまでのすき間	lcpElementRenderDelay
INP：Input delay	クリック・タップ・キー入力が、処理される前に止められている時間	inpInputDelay
INP：Processing duration	イベントの処理（ハンドラ）が走る時間	inpProcessingDuration
INP：Presentation delay	処理が終わってから、ブラウザが次の画面を描くまでの時間	inpPresentationDelay

この記事では、LCPの4つを「最初のバイトまで」「読み込み開始の遅れ」「読み込みの所要時間」「描画の遅れ」、INPの3つを「入力の遅れ」「処理の時間」「表示の遅れ」と呼ぶ。上から順に、英語の名前と対応している。

接続の時間も、TCPとTLSに分かれた

更新履歴は、ページ読み込みの内訳も変えたと書いている。接続を始める時間（TLSを除く）と、暗号化の取り決めの時間が、別の項目になった。両方を足した従来の項目も、APIには残してある。

見られる場所と、数字の約束事

更新履歴によると、ダッシュボードの「Real user monitoring」で「Core Web Vitals」の節に進み、下へスクロールすると、段階が見える。GraphQLのAnalytics APIでも取れ、値はP25・P50・P75・P90・P95・P99・P999の各パーセンタイルで出る。数字の約束事は、次の2文である。

"All values are in microseconds. A negative value means the data is not available."

（訳: すべての値の単位はマイクロ秒である。負の値は、データが無いことを意味する。）

1秒は1,000,000マイクロ秒なので、APIで取った数字は、画面の時間と単位が違うと考えておく。負の数字は「とても速い」ではなく、「データが無い」と読む。

02 なぜ・背景 — 「遅い」と分かっても、直す場所は段階を見るまで決まらない

良い・悪いの判定は、すでに別の記事にある

LCP・INP・CLSが「良好」「改善が必要」「不良」のどれに入るかは、当サイトの記事「Core Web VitalsのLCP・INP・CLSは「良好・改善が必要・不良」の3段階で判定される ── 自分のサイトで確認する14項目（2026年9月時点）」で扱った。INPの悪化が全体の傾向か自社だけかの切り分けは、記事「CrUXの2026年8月分でもINPの悪化が続き、原因は公式にも分かっていない ── 自社の悪化を全体の傾向と切り分けて確認する13項目（2026年10月時点）」にある。この記事は判定を繰り返さず、遅いと分かったあとに、どの段階が長いのかを読む話だけを書く。

段階の分け方は、web.devに先に書かれていた

Googleのweb.devには、LCPを直す手順の記事「Optimize Largest Contentful Paint」（ページには「Published: April 30, 2020, Last updated: March 31, 2025」と表示）と、INPの記事「Optimize Interaction to Next Paint」（「Published: May 19, 2023, Last updated: September 2, 2025」）がある。2026年10月15日に開いて読んだ。2つの記事の段階の名前は、Cloudflareの更新履歴の7つの名前と同じである。Googleの文書にあった分け方を、Cloudflareが実ユーザーの数字に当てたものと読める。

Chrome DevToolsの「Performance insights」にも、同じ分け方の「LCP breakdown」と「INP breakdown」がある（どちらも「Published: Oct 8, 2025」と表示）。手元のブラウザでも、実ユーザーの計測でも、同じ名前で話せる。

段階は重ならず、足すと全体になる

LCPの段階について、web.devは次のように書いている。

"There is no overlap or gap between them. Collectively, they add up to the full LCP time."

（訳: それらの間に、重なりもすき間も無い。まとめると、LCP全体の時間になる。）

INPも同じで、web.devは次のように書いている。

"The sum of these three subparts is the total interaction latency."

（訳: この3つのサブパートの合計が、操作への反応の時間の全体である。）

足すと全体になるので、どれか1つの段階が長ければ、全体が長くなる。逆に、短くした段階があっても、別の段階が長いままなら、全体はあまり縮まない。

1か所を速くしても、時間が別の段階に移るだけのことがある

web.devは、LCPの直し方の難しさを、次のように書いている。

"In some cases, an optimization applied to one part won't improve LCP, it will just shift the time saved to another part."

（訳: 場合によっては、1つの部分に施した最適化がLCPを改善せず、節約できた時間が別の部分に移るだけになる。）

web.devの例では、画像を圧縮して読み込みの所要時間が縮んだのに、LCPの要素がJavaScriptの読み込みが終わるまで隠されていたため、縮んだ分が描画の遅れに移った。段階別に見ておかないと、直したのに変わらない理由が分からない。

目安の割合は、時間ではなく、段階どうしの比べ方

web.devは、良く整ったページでの、4つの段階の割合の目安を示している。最初のバイトまでが約40%、読み込み開始の遅れが10%未満、読み込みの所要時間が約40%、描画の遅れが10%未満である。ただし、web.devは、この割合を時間の目標に変えないよう求めている。

"These subparts are only meaningful relative to each other, so it's best to always measure them that way."

（訳: これらのサブパートは、お互いに比べたときにだけ意味がある。だから、常にその形で測るのが最善である。）

この記事も、絶対値の基準は作らない。段階は割合で読み、同じページの前後で比べる。

03 用語 — 段階の話で出てくる言葉を、先にそろえる

実ユーザー計測と、手元の計測

LCPの要素と、LCPの資源

パーセンタイルと、メインスレッド

04 型別 — 自社がどれに当たり、何を、どの順で確かめるか

🅰 型A — すでにCloudflareのWeb Analyticsを使っているサイト

Cloudflareの文書の概要ページには、「Available on all plans」（訳: すべてのプランで使える）と書かれている。使っているサイトは、ダッシュボードの「Core Web Vitals」の節で、段階の数字を見る。まず長い段階を探す。手順2と手順4から始める。

🅱 型B — Cloudflareを通していないサイト

Cloudflareの文書は、Cloudflareを通していないサイトにも、JavaScriptのスニペットを入れて使う手順を書いている。外部のスクリプトを読み込むため、サイトのコンテンツセキュリティポリシーの変更が要ることもある、と別のページにある。入れるかは、プライバシーポリシーと合わせて決める。入れない場合でも、Chrome DevToolsとPageSpeed Insightsで、同じ段階の名前で確かめられる。

🅲 型C — 訪問が少ないサイト

web.devによると、PageSpeed Insightsは、ページ単位のデータが足りないとき、サイト全体のデータを出す。ChromeのCrUX（Chrome User Experience Report）にデータが無いページは、JavaScriptで集める実ユーザーの計測で補うよう勧めている。数字が出ないときは、手元の計測で段階を見る。

🅳 型D — 制作会社・代理店で、顧客のサイトの遅さを報告する担当

「LCPが3秒でした」だけでは、顧客は何を頼めばよいか分からない。段階の数字を添えて、頼む相手を分ける。最初のバイトまでが長ければサーバーの担当、描画の遅れが長ければCSSやJavaScriptの担当になる。

手順1 — 遅いと言われたページと端末を1つに決め、数字の出どころを書く

PageSpeed Insightsは、上の部分にChromeの実ユーザーのデータを、下の部分に手元の計測を出す。web.devは、実ユーザーのデータがあるなら先にそちらを見るよう書いている。見るページ、端末、期間、数字の出どころを、最初にメモする。見る期間で数字が変わる罠は、当サイトの記事「その数字、本当に"今日"の数字か — WEB運営で見落とされる"期間"の罠」にも書いた。

手順2 — LCPの4つの段階を出して、いちばん長いものに丸を付ける

Chrome DevToolsのPerformanceパネルで読み込みを記録すると、「LCP breakdown」に4つの時間が出る。PageSpeed Insightsの下の部分にも、「Largest Contentful Paint element」という診断があり、LCPを構成する時間の内訳が出る、とweb.devは書いている。4つの時間を書き写し、いちばん長いものに丸を付け、LCP全体に対する割合を出す。前の章の目安の割合と並べる。

手順3 — 長い段階ごとに、最初に見る場所を決める

web.devは、LCPの4つの直し方を、効果が大きいと見込まれる順に、読み込み開始の遅れ、描画の遅れ、読み込みの所要時間、最初のバイトまで、と並べている。下の表は、段階ごとに、web.devが挙げる原因から、最初に見る場所を選んだものである。

長い段階	web.devが挙げる主な原因	最初に見る場所
最初のバイトまで	転送（リダイレクト）が何回もある。キャッシュが使えず、毎回大元のサーバーに届く。訪問者ごとに違うURLのパラメータが付く	転送の回数、HTMLがキャッシュから返っているか
読み込み開始の遅れ	LCPの画像が最初のHTMLに書かれていない。JavaScriptで足している。読み込みの優先度が低い。遅延読み込みが付いている	ページのソースにLCPの画像のimgがあるか、loading属性
読み込みの所要時間	画像が大きい。置き場が遠い。同時に多くのものを読み込んでいる	画像の大きさと形式、置き場
描画の遅れ	描画を止めるCSSや同期のJavaScript。要素がまだ文書に無い。A/Bテストの仕組みが隠している。ロングタスク	headの中のCSSとJavaScript
入力の遅れ	他の処理がメインスレッドを占有している。ページの読み込み中に操作している	操作した時点で動いていた処理
処理の時間	イベントの処理が重い	クリックなどの処理の中身
表示の遅れ	DOMが大きい。レイアウトの計算が重い。JavaScriptで大量のHTMLを描いている	DOMの大きさ、操作のあとのレイアウト

読み込み開始の遅れ：LCPの画像は、最初のHTMLに書いてあるか

web.devは、LCPの資源は、ページが最初に読み込む資源と同じ時刻に読み込みが始まるのが望ましい、と書いている。見つけにくくなる例は、JavaScriptで足した画像、遅延読み込みの仕組みがsrcを隠すもの、CSSの背景画像である。遅延読み込みについては、次のように書かれている。

"Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay, and will have a negative impact on LCP."

（訳: LCPの画像を、遅延読み込みにしてはならない。それは必ず余計な読み込み開始の遅れを生み、LCPに悪い影響を与える。）

遅延読み込みそのものは、当サイトの記事「画像SEOの基本 ── alt属性・次世代フォーマット・遅延読み込みを、公式ガイドで確認する14項目（2026年9月時点）」で扱った。ここで確かめるのは、LCPの画像だけは遅延読み込みにしていないかの1点である。

描画の遅れ：画面を描くのを止めているものを数える

web.devは、描画の遅れの原因として、headの中のCSSと同期のJavaScript、まだ文書に無いLCPの要素、A/Bテストによる非表示、ロングタスクを挙げている。headの中に、CSSとJavaScriptが何本あるかを数えるのが最初の確認である。CSSを小さくする方法は、使っていない分を消す、後回しにできる分を分ける、圧縮する、の3つである。圧縮には、当サイトの無料ツール🔧 CSS・JSファイルの圧縮（minify）ツールが使える。

最初のバイトまで：転送と、キャッシュと、サーバーの時間

web.devは、広告や短縮URLからの転送が何回もあること、キャッシュが使えず毎回大元のサーバーまで届くことを、原因に挙げている。後者の例は、訪問者ごとに違うURLのパラメータを付けた場合である。パラメータの扱いは、当サイトの記事「URLパラメータとは？ SEOへの影響と、重複コンテンツを防ぐ設定の基本（2026年8月時点）」にある。時間がどこで使われたかを追う仕組みは、記事「Cloudflare Tracesは、1つのリクエストが規則・書き換え・キャッシュ・オリジンのどこで時間を使ったかを追える ── 12月1日からの新料金の前に、使うかを決めて確認する14項目（2026年10月時点）」で扱った。

手順4 — INPの3つの段階を出して、いちばん長いものに丸を付ける

Chrome DevToolsのPerformanceパネルで、記録しながらボタンやメニューを操作すると、「INP breakdown」に、いちばん長い操作の3つの時間が出る。この文書は、記録中に操作が必要なこと、処理能力を絞る設定（CPU throttling）で力の弱い端末に近づけると原因が見えやすいことを書いている。入力の遅れの読み方は、次のとおりである。

"High input delay: the interaction was delayed by other main thread work and may not have been the direct cause of slow INP."

（訳: 入力の遅れが長い：操作が、メインスレッドの他の作業に遅らされた。遅いINPの直接の原因ではないかもしれない。）

処理の時間が長ければ、操作のイベントの処理が直接の原因である。表示の遅れが長ければ、処理のあとに画面を表示するまでの描画に遅れがある。入力の遅れが長いときは、操作の原因を探す前に、そのとき裏で動いていた処理を探す。直し方の方向は、web.devによると、処理の時間にはイベントの仕事を減らすこと、表示の遅れにはDOMを小さくすることで、どれも長かった段階にだけ効く。

手順5 — 直したあとに、縮んだ段階と、増えた段階を比べる

直したら、同じページ、同じ端末で、段階の数字を取り直す。縮んだ段階と、増えた段階を、両方書く。所要時間は縮んだのに描画の遅れが増えたなら、web.devの例と同じ型である。次は描画の遅れに進む。

手順6 — 数字を、実ユーザーと手元に分けて、報告に書く

2つの数字が食い違うときは、実ユーザーのデータのほうが体験に近い、とweb.devは書いている。報告には、数字ごとに「実ユーザー」か「手元」かを書き添える。他人が測った数字を自分のサイトに当てはめる前の注意は、記事「「+28%」と「+9%」は、同じ調査の、同じプラットフォームの数字だった ── 他人が測った数字を自分のサイトに当てはめる前に確かめる3点」にある。

手順7 — 日付・ページ・端末・段階の数字を1行にして、次の確認日を決める

確認した日、ページ、端末、7つの段階の数字を、1行にまとめて残し、次の確認日をカレンダーに入れる。1回の数字ではなく、日付つきの並びで見ると、変わった日が分かる。

公式が書いていないこと

更新履歴には、段階ごとの良い・悪いの基準値、データが集まるまでの時間、必要な訪問の数が、書かれていなかった。見つからなかったことは、「無い」ことの証明ではない。確かめた範囲は、読んだ本文までである。

05 自分のサイトで確認するチェックリスト

下の13項目は、1項目5分ほどでできる作業である。チェックの状態はブラウザの中にだけ保存され、サーバーには送られない。

• 遅いと言われたページのURLを1つ選び、端末（スマホかパソコン）と、見る期間を、メモに1行で書く
• PageSpeed Insightsにそのページを入れ、上の部分に実ユーザーのLCPとINPの数字が出るかを確かめ、「このURL」か「サイト全体」かを書き留める
• Chrome DevToolsのPerformanceパネルで、そのページの読み込みを1回記録し、「LCP breakdown」の4つの時間を、書き写す
• 書き写した4つの時間のうち、いちばん長いものに丸を付け、LCP全体に対する割合を、計算して書く
• LCPの要素が画像か文字かを確かめ、画像なら、ページのソースを開いて、imgタグのsrcが最初のHTMLにあるかを、検索で確かめる
• LCPの画像のimgタグに、loading="lazy"が付いていないかを、ソースの検索で確かめ、付いていれば「有り」と書く
• headの中のCSSとJavaScriptのファイルの本数を、数えて書く
• 同じページのHTMLが返るまでの時間（最初のバイトまで）を、curlのtime_starttransferで5回測り、いちばん遅い値と速い値を、書く
• DevToolsでページを記録しながら、ボタン・メニュー・入力欄を1つずつ操作し、「INP breakdown」の3つの時間を、書き写す
• INPの3つの時間のうち、いちばん長いものに丸を付け、入力の遅れが長いなら、ページを開いてすぐに操作したかを、書き添える
• 実ユーザーの段階別の数字を取る手段（CloudflareのWeb Analyticsか、web-vitalsライブラリのattribution版）が、自社にあるかを確かめ、無ければ導入を決める日を1つ書く
• 何か1つを直したら、同じページと同じ端末で項目3と項目9をやり直し、縮んだ段階と、増えた段階を、両方書く
• 社内や顧客への報告に載せる数字ごとに、「実ユーザー」か「手元」かを、1語ずつ書き添える

時間が限られているときは、項目1・3・4・9の4つだけでも、遅い段階の見当が付く。

06 代替・他の選択肢 — 段階を出す道具を、使い分ける

4つの道具の比較

段階の数字を出す方法は、Cloudflareのダッシュボードだけではない。公式の文書に書かれた範囲で、表にした。

道具	数字の出どころ	段階の内訳（文書の記述）	向くとき
Cloudflare Web Analytics	実際の訪問者	LCPが4つ、INPが3つ。画面とGraphQL API	継続して見たいとき
web-vitalsライブラリ（attribution版）	実際の訪問者（自分で集める）	LCPの4つ、INPの3つの時間が、attributionの値に入る	集計の仕組みを自社で持ちたいとき
Chrome DevTools	手元のブラウザ	「LCP breakdown」と「INP breakdown」の2つの診断	原因を1ページずつ追うとき
PageSpeed Insights	上は実際のChromeの利用者、下は手元の計測	下の部分の「LCP要素」の診断に内訳。web.devはCrUXにも内訳があると書くが、PageSpeed Insightsのどこに出るかは確かめていない	入口として、数字の出どころを分けて見るとき

web-vitalsライブラリの「attribution版」で、自分で集める

GitHubのweb-vitalsライブラリには、標準版のほかに、診断の情報を加えたattribution版がある。READMEによると、標準版より約1.5KB（brotli圧縮後）大きい。値には、LCPの4つ（timeToFirstByte・resourceLoadDelay・resourceLoadDuration・elementRenderDelay）と、INPの3つ（inputDelay・processingDuration・presentationDelay）が入る。Cloudflareと同じ分け方である。送り先と保存期間は、プライバシーポリシーと合わせて決める。

PageSpeed Insightsは、数字の出どころを分けて見る入口

上の数字で「遅い」と出たあとに、下の診断で段階を見る、という順番が無理が少ない。ブラウザの記録の道具は、当サイトの記事「Chrome DevToolsのPerformanceパネルがソフトナビゲーションの測定に全面で対応し、Applicationパネルに広告の画面が加わった ── 1画面で切り替わるページと広告タグを自分の手で測る13項目（2026年10月時点）」で扱った。CloudflareのBEACONの公開データで他社と比べるときの注意は、記事「CloudflareのBEACONは、大手1万サイトをドメインを外して集計した公開データで、自社の数字は引けない ── 「他社より遅い」と言われたとき、比べる相手を確かめる13項目（2026年10月時点）」にある。手元の計測を定期的に取りたいときは、当サイトの無料ツール🔧 WEBサイトの最大3ページ Lighthouse監査・チェックツールが使える（会員登録とログインが要る）。

いまは段階を読まない、という選択

LCPもINPも良好な範囲なら、段階まで見る必要は、いまはない。数字が悪くなった日に、手順2と手順4に進めばよい。

07 当サイトで確かめたこと

読んだ公式の文章と、その日付

2026年10月15日に、Cloudflareの更新履歴の1ページ、Cloudflare Web Analyticsの文書の4ページ、web.devの2つの記事、Chrome DevToolsの2つの診断の文書、web-vitalsライブラリのREADMEを、本文を取得して読んだ。英文の引用は、すべて、取得した本文から1文字ずつ照らして書いた。照らせなかった文は、要旨で書いている。

当サイトでは、Cloudflareの画面を見ていない

当サイトは、Cloudflareを通していない。そのため、ダッシュボードの画面とGraphQLのAPIの数字は、当サイトでは見ていない。表の項目名は、更新履歴の本文から写したものである。

当サイトで測ったのは、最初のバイトまでの目安だけ

2026年10月15日の10時台に、この記事を書いたパソコンのcurlで、当サイトの公開ページ3つを、各5回ずつ取得した。最初のバイトが届くまでの時間（接続と暗号化の時間を含む）は、トップページが0.10〜0.15秒、AI Ronブログの記事1本が0.20〜0.22秒、解説記事1本が0.10〜0.12秒だった。これはLCPの最初の段階の目安であって、LCPそのものではない。ブラウザでの読み込みと、実際の訪問者の数字は、まだ測っていない。当サイトも13項目の順で確かめ、結果を書き足す。

サーバー側でページを作る処理に時間がかかっていた当サイトの例は、記事「警告1,440件の中に、本物は2件だけだった ── 「報告は大げさ」は正しかったのに、記事ページは本当に遅かった」にまとめた。他人が出した大きな数字を、自社のログ1週間分で数え直した例は、記事「Cloudflareが通信の半分以上は人間ではないと書いた週、当サイトのログで自動と分かるものは36.2%だった ── 他人の大きな数字を、自社のログ1週間分で数え直す」にある。

08 このテーマの、これまで

日付つきの記録

• 2020年4月30日：web.devの「Optimize Largest Contentful Paint」が公開された（最終更新は2025年3月31日）。
• 2023年5月19日：web.devの「Optimize Interaction to Next Paint」が公開された（最終更新は2025年9月2日）。
• 2025年10月8日：Chrome DevToolsの「Performance insights」に、「LCP breakdown」と「INP breakdown」の文書が載った。
• 2026年10月13日：CloudflareのWeb Analyticsの実ユーザー計測が、LCPを4つ、INPを3つの段階に分けて見せるようになった。