「スマホでLCPが遅いと出ています」と報告を受けても、それだけでは画像を軽くすべきか、サーバーを見直すべきか、CSSやJavaScriptを減らすべきかが決まりません。LCP（Largest Contentful Paint、ページの主要な画像や文字が表示されるまでの時間）は1つの数字ですが、遅れの原因は段階ごとに違うからです。
CloudflareのWeb Analyticsは、2026年10月13日の更新で、実際の訪問者から集めたLCPとINP（Interaction to Next Paint、クリックなどの操作から次の画面が描かれるまでの時間）を、それぞれの内訳（サブパート）に分けて表示するようになりました。この記事では、内訳ごとに疑う場所と対策の対応を公式資料で整理し、編集部の検証環境で内訳が実際にどう動くかを確かめた結果を示します。CloudflareのダッシュボードやAPIは、アカウントを使った確認をしていません。
Web Analyticsで増えた表示
Cloudflareの変更履歴（Deeper Core Web Vitals Diagnostics、2026年10月13日）によると、追加されたのは次の3つです。
- LCPの4つの内訳：Time to First Byte（HTMLの最初の1バイトが届くまで）、Resource load delay（HTMLが届き始めてからLCPの画像などの読み込みが始まるまで）、Resource load duration（その画像などのダウンロード）、Element render delay（ダウンロードが終わってから画面に表示されるまで）
- INPの3つの内訳：Input delay（操作から処理が始まるまでの待ち）、Processing duration（イベント処理のコードの実行）、Presentation delay（処理が終わってから次の画面が描かれるまで）
- 接続時間の分離：TCPの接続とTLSのハンドシェイク（暗号化の準備）を別々に表示
ダッシュボードでは、Web Analyticsでサイトを選び、Core Web Vitalsのレポートを下へ進むと内訳があり、TCPとTLSはPage Loadの欄にあると案内されています。Web Analytics自体は、公式ドキュメントで全プランの対象とされています。
なお、ドキュメントのPage load timeのページ（2026年10月22日に確認。最終更新は2026年4月16日）は、まだ「HTTPSの場合、TCPの時間にはTLSのネゴシエーションを含む」と書いたままです。変更履歴とドキュメントで記述がそろっていないため、TCPの数字を見るときは、どちらの表示かを画面上の項目名で確かめてください。
内訳ごとに、疑う場所が違う
内訳と対策の対応は、Googleの「Optimize Largest Contentful Paint」（web.devの記事。2025年3月31日更新）に詳しく書かれています。要点を表にまとめます。
| 内訳 | 長いときに疑う場所 | 記事に書かれた対策の例 |
|---|---|---|
| Time to First Byte | サーバーの応答、リダイレクトの多さ、CDNのキャッシュが効いていない | リダイレクトを減らす、URLのパラメーターでキャッシュが外れないようにする |
| Resource load delay | LCPの画像がHTMLから見つけられない（CSSやJavaScriptの中で指定している）、優先度が低い、loading="lazy" | HTMLに書く、<link rel="preload">、fetchpriority="high"、同じオリジンから配信 |
| Resource load duration | 画像のファイルサイズ、配信元までの距離、ほかの読み込みとの競合 | 画像を小さくする、CDN（画像CDN）を使う、キャッシュを効かせる |
| Element render delay | <head> の読み込み待ちのCSSや同期のJavaScript、JavaScriptで要素を後から差し込む構成、長いタスク | 描画を止めるCSS・JavaScriptを減らす、サーバー側で描画する、長いタスクを分ける |
同じ記事は、よく最適化されたページの目安として、Time to First Byteと読み込みがそれぞれ約40%、名前に「delay」が付く2つはそれぞれ10%未満という比率を挙げています。あわせて、この比率を秒数に換算せず、内訳どうしの比で見るように注意しています。
INPも同様で、「Optimize Interaction to Next Paint」（2025年9月2日更新）は、Input delayにはスクリプトの読み込み・解析やタイマーの処理などメインスレッドの別の作業、Processing durationにはイベント処理そのものの重さ、Presentation delayにはDOMの大きさや描画の負荷を、それぞれ見直す場所として挙げています。
検証環境で内訳を動かしてみた
Cloudflareのビーコンがどの計算方法を使っているかは、ドキュメントに書かれていません。そこで編集部では、同じ名前の内訳を出すライブラリ web-vitals（GoogleChromeのリポジトリで公開。6.2.3、attributionビルド）を使い、ページの作りを変えると内訳がどう動くかを確かめました。
検証は、ローカルのサーバーとChromium 141（ヘッドレス）で行いました。LCPになる画像は1600×900のJPEG（約744KiB）で、サーバー側で64KiBずつ0.1秒おきに送り、ダウンロードに約1.1秒かかるようにしています。各条件を3回ずつ測り、下の数字は中央値です。どの遅れもサーバーやページの側でわざと作ったもので、数字は実際のサイトや回線の値ではありません。内訳がどう動くかを見るための値として読んでください。
| 条件 | LCP | 大きく動いた内訳 |
|---|---|---|
基準：画像をHTMLに書き、fetchpriority="high" | 1136ms | Resource load duration 1103ms（ほかは各数十ms以下） |
| 画像を、0.6秒遅れて届くJavaScriptで追加 | 1772ms | Resource load delay 614ms |
<head> に3秒遅れて届くCSSを追加 | 3056ms | Element render delay 1942ms |
| サーバーがHTMLを1.2秒待ってから返す | 2368ms | Time to First Byte 1202ms |
| 画像を800×450（約107KiB）に縮小 | 136ms | Resource load duration 101ms |
LCPの合計が延びた理由は、どの条件でも変えた箇所に対応する内訳に現れました。遅いCSSの条件では、画像のダウンロードは基準と同じ約1.1秒で終わっていたのに、CSSが届くまで表示されず、その差がElement render delayに入っています。この条件では、画像を圧縮してもLCPは縮まらないことになります。
一方、loading="lazy" を付けた条件では、Resource load delayは33ms（基準は8ms）で、差は小さく出ました。遅延のないローカルの通信で、画像が最初から画面内にあったためと考えられ、この結果から実際のサイトでの影響の大きさは判断できません。
INPも同じ方法で確かめました。ボタンのクリック処理に0.3秒かかる処理を入れるとProcessing durationが302ms、クリックの直前に0.4秒の別の処理を走らせるとInput delayが349ms、クリック処理の後の描画（requestAnimationFrame）に0.3秒の処理を入れるとPresentation delayが310msになり、入れた場所に対応する内訳だけが伸びました。
GraphQLで取り出すときの注意
ダッシュボードだけでなく、GraphQL Analytics APIでも内訳を取り出せます。変更履歴に書かれたフィールドは次のとおりです。
- LCPとINPの内訳：
rumWebVitalsEventsAdaptiveGroupsの、lcpResourceLoadDelayP50やinpInputDelayP50のようなパーセンタイル付きの名前（ほかにtimeToFirstByte、lcpResourceLoadTime、lcpElementRenderDelay、inpProcessingDuration、inpPresentationDelay） - TCPとTLS：
rumPerformanceEventsAdaptiveGroupsのconnectionTimeWithoutTLSP50、tlsTimeP50など。合計のconnectionTimeも残る - パーセンタイル：P25・P50・P75・P90・P95・P99・P999
単位はマイクロ秒で、負の値はデータがないことを示すと書かれています。ダッシュボードのCore Web Vitalsの値はミリ秒と説明されているので、表計算などで並べるときは1000で割るのを忘れないようにします。負の値をそのまま平均に含めると、数字が実際より小さく見えます。GraphQLのドキュメント側には、10月22日時点でこれらのフィールドの説明がまだなく、実際のクエリの形は確認していません。
また、FAQによると、ビーコンのデータはサンプリングせずに7日間保持し、その後は約10%に集約されます。集計時にも、条件と件数に応じたサンプリングがかかります。7日より前の期間でアクセスの少ないページを細かく比べるときは、集約で件数が減っている点を考えに入れて読むのが安全です（編集部の考え）。
改善の依頼・報告に使うときの書き方
ここからは編集部の提案です。制作会社への依頼や社内への報告では、LCPの数字だけでなく「どのページの、どの要素で、どの内訳が、どのパーセンタイルで長いか」まで書くと、担当者が最初に触る場所を決められます。たとえば「トップページのヒーロー画像で、P75のResource load delayがLCPの半分を占める」と分かれば、画像の圧縮より先に、画像の指定場所と優先度を見直す話になります。
改善の前後を比べるときは、同じパーセンタイルと同じ期間の長さで比べ、内訳の比率が目安（delayの2つが10%未満）に近づいたかも見ます。測定の基本や画像の最適化の手順は、Core Web Vitals対策の実践ガイドとCDN×画像最適化のガイドで扱っています。
なお、Cloudflareを経由しているサイトでは、Web Analyticsの計測スクリプトが自動で挿入される設定があります。計測を始める前に、プライバシーポリシーとの関係や、意図しない挿入がないかを確認しておきます。この点はネームサーバを移したらJSが増えていたで整理しています。
確認した範囲
2026年10月22日に、Cloudflareの変更履歴「Deeper Core Web Vitals Diagnostics」（2026年10月13日）と、Web Analyticsのドキュメント（Core Web Vitals、Page load time、FAQ、概要）を、公開ページと cloudflare/cloudflare-docs リポジトリの原稿で確認しました。内訳と対策の対応は、web.devの「Optimize Largest Contentful Paint」（2025年3月31日更新）「Optimize Interaction to Next Paint」（2025年9月2日更新）と、
web-vitals6.2.3 のREADMEで確認しました（資料調査）。あわせて、編集部の検証環境（Linux、Node.js v22.22.0、Chromium 141.0.7390.37、web-vitals6.2.3）で、検証用のページの条件を変えてLCPとINPの内訳を各3回測りました（実機検証）。通信の遅れはサーバー側で人工的に作ったもので、実際のサイトや回線の値ではありません。CloudflareのダッシュボードとGraphQL APIでの表示、Cloudflareのビーコンの計算方法、Safari・Firefoxでの値は確認していません。
表示速度の改善や、計測をもとにしたサイトの作り直しは、HP制作・リニューアルのご相談からお問い合わせください。
参考資料
- Deeper Core Web Vitals Diagnostics: LCP & INP Sub-Part Metrics in Real User Monitoring（Cloudflare changelog の原稿、cloudflare/cloudflare-docs）
- Core Web Vitals（Cloudflare Web Analytics docs）
- Page load time（Cloudflare Web Analytics docs）
- FAQs（Cloudflare Web Analytics docs）
- Optimize Largest Contentful Paint（web.dev）
- Optimize Interaction to Next Paint（web.dev）
- GoogleChrome/web-vitals（README、LCPAttribution・INPAttribution）
