First Contentful Paint（FCP）
First Contentful Paintが測るもの、良好なFCPスコア、Core Web Vitalではない理由、First PaintやLCPとの違い、遅いFCPの改善方法を解説します。
言語
First Contentful Paint（FCP）は、ページの読み込み開始から、テキスト、画像、SVG、白以外のcanvasなど、コンテンツの一部が初めて描画されるまでの時間です。実ユーザーの75パーセンタイルで1,8秒以下が良好です。FCPはCore Web Vitalではなく、ランキングシグナルはLCP、INP、CLSです。FCPはラボとフィールドの両方で使える診断指標であり、LCPに先行するため、レンダリングを妨げるリソースや遅いTTFBの発見に役立ちます。Lighthouse 10ではPerformanceスコアの10%を占めます。改善するには、レンダリングを妨げるCSSとJavaScriptをなくし、TTFBを短縮し、クリティカルCSSをインライン化し、font-display: swapを使い、必要なオリジンへpreconnectします。
要点 — First Contentful Paint（FCP）は、訪問者が真っ白な画面ではなく、ページ上の最初の要素（テキスト、画像、グラフィックなど）を目にする瞬間を表します。速いほど良く、1,8秒未満が「良好」の目安です。速度確認に役立ちますが、Googleがランキングに使用する指標の1つではありません。
FCPとは何か
誰かがページへのリンクをクリックすると、ブラウザーがページを取得して処理する間、何もない真っ白な画面を見つめる短い時間があります。First Contentful Paintとは、その空白画面が実在する何かに変わる瞬間です。 見出し、ロゴ、写真など、訪問者が実際に見られるものであれば対象になります。
考え方はそれだけです。FCPは、*“ページが動いているとユーザーに伝わるまで、どのくらいかかるか？“*という単純な問いに答えます。0,5秒でコンテンツが描画されるページは速く感じられます。3秒間真っ白なままのページは壊れているように感じられ、離脱につながります。
Evidence for this claim FCP measures from navigation until the first text, image, SVG, or non-white canvas content is rendered. Scope: Current web.dev FCP definition and qualifying content types. Confidence: high · Verified: web.dev: First Contentful Paint「コンテンツ」に含まれるもの
FCPは、ブラウザーが次のいずれかを画面に描画した時点で記録されます。
- テキスト（見出し、段落、ナビゲーションリンク）
- 画像（背景画像を含む）
<svg>グラフィック- 1つの白以外の
<canvas>要素
単なる背景色だけでは対象になりません。それはFirst Paintと呼ばれる、別のより早いタイミングです。FCPは実際のコンテンツが現れたときにだけ記録されます。
良好なスコアとは
実際の訪問者を対象に測定するGoogleの評価帯は次のとおりです。
| FCP時間 | 評価 |
|---|---|
| 1,8秒以下 | 良好 |
| 1,8～3,0秒 | 改善が必要 |
| 3,0秒超 | 不良 |
FCPはPageSpeed InsightsやLighthouseなど、Core Web Vitalsも表示する同じレポートで確認できます。
FCPはGoogleランキングに影響するか
直接は影響しません。 多くの人が誤解する点です。Googleがランキングに実際に使用する3つのCore Web VitalsはLCP、INP、CLSであり、FCPは含まれません。
それでも監視する価値があるのは、FCPを遅くする要因（応答の遅いサーバー、描画を妨げる大きなスタイルシートやスクリプト）と同じものが、**Largest Contentful Paint（LCP）**も悪化させることが多いためです。LCPはランキングシグナルであるため、FCPの根本原因を直すとLCPも改善することがよくあります。ただし、LCPには最大要素そのもののサイズや読み込み優先度など固有の原因もあるため、保証ではありません。FCPは煙探知機のようなものです。確認する価値はありますが、火が消えた証明にはなりません。
すぐに試せる改善
FCPが遅いときに疑うべき代表的な原因と対処法は次のとおりです。
- レンダリングを妨げるファイル。 ページの
<head>にあるCSSとJavaScriptは、読み込みが終わるまでブラウザーに何も描画させないことがあります。最大の原因です。 - 遅いサーバー。 サーバーの応答に時間がかかる（Time to First Byteが長い）と、バイトが届くまでブラウザーは描画できません。
- テキストを隠すフォント。 Webフォントの読み込み中、設定によっては最大3秒ほどテキストが見えなくなります。
font-display: swapへ変更すると、代替フォントのテキストをすぐに表示できます。
ラボとフィールドの差、FCPとLCPの診断手順、改善策の完全版を知りたい場合は、Advancedタブに切り替えてください。
要点 — FCPは、ナビゲーション開始から、ページ上のいずれかのコンテンツ（テキスト、画像、
<svg>、白以外の<canvas>）が初めて描画されるまでの時間です。Core Web Vitalではありません。ラボとフィールドの両方で使える補助的な診断指標で、LCPの構成要素です（FCPはLCP以前または同時に発生します）。フィールドしきい値（p75）は、良好 ≤ 1,8秒、改善が必要 ≤ 3,0秒、不良 > 3,0秒です。Lighthouse 10ではPerformanceスコアの10% を占めます。FCPの計測はナビゲーションから始まり、リダイレクト、接続確立、TTFBも含むため、ラボ（Lighthouse）とフィールド（CrUX）の値はよく異なります。原因のある場所から直します。まずレンダリングを妨げるCSS／JavaScript、次にTTFB、最後にフォントです。
FCPが正確に測るもの
ここでの基準は、Philip Waltonによるweb.dev記事のGoogle定義です。“First Contentful Paint (FCP) measures the time from when the user first navigated to the page to when any part of the page’s content is rendered on the screen.” (翻訳) 「First Contentful Paint（FCP）は、ユーザーがページへ最初に移動した時点から、ページのコンテンツの一部が画面に描画されるまでの時間を測定します。」同じ文書で「content」は「テキスト、背景画像を含む画像、SVG要素、白以外のcanvas要素」を意味し、原文では “text, images (including background images), <svg> elements, or non-white <canvas> elements.” と書かれています。
重要なのはいずれかという言葉です。FCPは何が描画されたかを区別しません。40ピクセルのロゴも、画面いっぱいのヒーロー画像も同じように対象です。「画面にはもう何か表示されているか」を示すシグナルなので、完了指標ではなく早期指標なのです。
Evidence for this claim FCP measures from navigation until the first text, image, SVG, or non-white canvas content is rendered. Scope: Current web.dev FCP definition and qualifying content types. Confidence: high · Verified: web.dev: First Contentful Paint見落としやすく、数値の読み方を変える点があります。FCPの時計はナビゲーション時に始まるため、HTMLが解析される前の処理もすべて含まれます。GoogleのKey Pointは、“FCP includes any unload time from the previous page, connection set up time, redirect time, and Time To First Byte (TTFB) which can be significant when measured in the field.” (翻訳) 「FCPには、前のページのアンロード時間、接続確立時間、リダイレクト時間、Time To First Byte（TTFB）が含まれ、フィールド計測では大きな割合になることがあります」と説明しています。サーバー応答に1,5秒かかれば、ブラウザーが1バイトも処理しないうちに1,8秒の予算の大半を使い切っています。
FCPはCore Web Vitalではない
多くのページが曖昧にするため、はっきり述べます。FCPはCore Web Vitalではなく、Googleのランキングシグナルにも含まれません。 Core Web VitalsはLCP、INP、CLSであり、Google SearchのCore Web VitalsランキングページにFCPは記載されていません。
Googleの分類では、FCPは診断に役立つ補助指標である「Other Web Vital」です。web.devは、“the metrics Time to First Byte (TTFB) and First Contentful Paint (FCP) are both vital aspects of the loading experience, and are both useful in diagnosing issues with LCP (slow server response times or render-blocking resources, respectively).” (翻訳) 「Time to First Byte（TTFB）とFirst Contentful Paint（FCP）はどちらも読み込み体験の重要な側面であり、LCPの問題（それぞれ遅いサーバー応答とレンダリングを妨げるリソース）の診断に役立ちます」と説明しています。
したがって、関係者には次の両面を率直に伝える必要があります。
- FCPはランキングに直接影響しません。 「SEOのため」にFCPを最適化しないでください。
- FCPは、ランキングに影響するLCPの優れた診断指標です。 レンダリングを妨げるリソースは、まずFCPに表れます。
FCPとFirst Paint（FP）の違い
この2つは頻繁に混同されます。
- First Paint（FP） は、実際のコンテンツがなくても、単なる背景色を含む何かをブラウザーが描画した時点で記録されます。
- FCP は対象コンテンツ、つまりテキスト、画像（背景画像を含む）、
<svg>要素、白以外の<canvas>要素が描画されたときだけ記録されます。仕様で定められた具体的な一覧であり、曖昧な「任意のDOMコンテンツ」ではありません。背景画像はDOM内のテキストでなくても対象になるため、正確に区別する価値があります。
したがって、常にFP ≤ FCPです。 コンテンツを伴わず背景色だけを描くケースは少ないため、ほとんどのページでは両者がほぼ同じです。意味のある差がある場合、通常は実際のコンテンツより先に装飾的な背景が描画されています。Paint Timing APIはfirst-paintとfirst-contentful-paintの両方を返しますが、分析する価値があるのはFCPです。FPから得られる実用的な情報はほとんどありません。
FCPとLCPの違い
もう1つ、よく一緒にされる組み合わせです。
- FCP = いずれかのコンテンツが描画された時点。早期に発生し、小さなロゴやナビゲーションリンクでも対象になります。
- LCP = ビューポート内で最大の要素が描画された時点。FCPと同時か、それ以降に発生します。
Googleの表現では、FCPはいずれかのコンテンツが描画された時点を、LCPはメインコンテンツが描画された時点を測るため、LCPの方が選択的です。ただし「より選択的」を「正しさが保証される」と読み替えてはいけません。どちらの指標も、実際のメインコンテンツが完成し、訪問者に役立つ状態だとは証明しません。FCPは対象となる何かが描画されたことを、LCPは対象候補のうち最大のものが描画されたことを示すだけです。FCPが0,5秒（ロゴ）でもLCPが4秒（ヒーロー画像）になることがあり、その差自体が有用な診断材料です。FCPがLCPに近い場合、最初に描画されたものが最大要素でもあり、ユーザーに不要な画面部品を先に描く無駄がない可能性を示すため、多くの場合は良い兆候です。
Evidence for this claim FCP answers when any eligible content first appears, while LCP tracks the largest eligible viewport candidate; neither metric proves the page's main content is complete or useful. Scope: field and lab Confidence: high · Verified: First Contentful Paint (FCP)計測上の例外も知っておくと役立ちます。クロスオリジン画像のタイミングに関するセキュリティ制限により、まれにブラウザーAPIがLCPをFCPより早く報告することがあります。実際の描画順ではなく、計測上のアーティファクトです。
しきい値とラボ・フィールドの不一致
フィールドしきい値（CrUX、p75）： 良好 ≤ 1,8秒 · 改善が必要 ≤ 3,0秒 · 不良 > 3,0秒。Googleは、モバイルとデスクトップに分けたページ読み込みの75パーセンタイルで測定するよう案内しています。
Evidence for this claim A good FCP is 1.8 seconds or less at the 75th percentile; above 3 seconds is poor. Scope: Current web.dev FCP field thresholds. Confidence: high · Verified: web.dev: First Contentful Paint一方、Lighthouseデスクトップは異なる、より厳しい境界値を使います。 緑はおおむね0～0,9秒、オレンジは0,9～1,6秒、赤は1,6秒超です。ラボは実環境ではなく、速度を制限したクリーンなChromeをシミュレート端末上で実行するためです。以下のスコア重みと同様、これらの評価帯はLighthouseのバージョンに固有で、執筆時点の監査文書に基づきます。LighthouseのFCPスコアは、“a comparison of your page’s FCP time and FCP times for real websites, based on data from the HTTP Archive.” (翻訳) 「ページのFCP時間を、HTTP Archiveのデータに基づく実在サイトのFCP時間と比較したもの」です。
FCPに関する混乱の原因として最も多いため、次の違いを覚えてください。
1,8秒という「良好」ラインは、フィールド（CrUX p75）のしきい値です。Lighthouseデスクトップの「緑」は約0,9秒です。用途が異なる別々の尺度です。
フィールド値とラボ値が異なる主因は、サンプルとする母集団が違うことであり、どちらかが常に「より真実」に近いからではありません。Lighthouseは、固定された端末とネットワーク条件で、クリーンなセッションを1回実行します。フィールド／CrUXは、実際の端末、ネットワーク、キャッシュ状態、ナビゲーション種類を集計します。通常のナビゲーションのように新しいFCPが自動で発生せず、独自のライフサイクル処理を必要とするback/forward cacheからの復元やprerenderedページも含まれます（web-vitalsライブラリが処理します）。多くのサイトでは、実ユーザーにリダイレクトチェーン、前ページのアンロード時間、ラボ実行では省かれるコールド接続があるため、フィールド値の方が実際に高くなります。ただし、傾向であって規則ではありません。ラボとフィールドの差を問題と判断する前に、端末クラスやネットワーク条件が同等か確認してください。実際の数値にはフィールドデータを使い、診断にはLighthouseを使います。
LighthouseスコアにおけるFCPの位置
執筆時点の現行版であり、恒久的な値ではないLighthouse 10では、FCPは**Performanceスコアの10%**です。重みの全体像は次のとおりです。
| 指標 | 重み |
|---|---|
| Total Blocking Time（TBT） | 30% |
| Largest Contentful Paint（LCP） | 25% |
| Cumulative Layout Shift（CLS） | 25% |
| First Contentful Paint（FCP） | 10% |
| Speed Index | 10% |
Performanceスコアは各指標スコアの加重平均であり、Googleは調査の進展に伴って重みが変わると説明しています。FCPはLighthouse 8から10まで10%を維持していますが、「10%」を不変の値として扱う前に、使用中のバージョンで確認してください。実務上、FCPが満点でもLighthouse全体の数値を動かせる範囲には限界があります。一方、FCPが悪いとLCPも悪いことがよくあります。根本原因を共有するためですが、スコアが保証する関係ではなく、確認すべき重なりです。
FCPが遅くなる原因
おおまかな優先順位は次のとおりです。
- レンダリングを妨げるリソース — 最大の原因です。
<head>内のCSSと同期JavaScriptはブラウザーを待たせます。ファイルのダウンロードと解析が終わるまでCSSOMとレンダーツリーを構築できず、何も描画できません。 - 長いTTFB — バイトが届く前にFCPは発生しません。遅いサーバーは最初のドミノであり、FCPの計測時間に含まれます。
- リダイレクトチェーン — リダイレクトのたびに、最初のバイトより前に完全な往復通信が加わります。
- Webフォントの読み込み方法 —
font-display: block（または指定なし）は、最大約3秒テキストを見えなくすることがあります。背景で技術的に描画が発生しても、ユーザーには有用なものが見えません。
改善方法
文書にはない優先順位を付けた完全な一覧です。これは一般的な手段であり、すべてのページに当てはまるわけではありません。まず自身のトレースやフィルムストリップを確認し、どのリソースまたは処理段階がそのページのFCP候補を遅らせているか特定してください。ページに不要かもしれないpreconnect、preload、font-display変更を先に適用しないことが大切です。
最初に行うこと（効果が大きい順）：
- レンダリングを妨げるCSSとJavaScriptをなくす。 ファーストビューに必要なクリティカルCSSを
<head>へ直接インライン化し、残りは非同期で読み込みます。重要でないスクリプトにはasync／deferを付けます。<link>タグの位置を変えるだけでは役立ちません。配置に関係なく、すべてのCSSの読み込みと解析が終わるまでブラウザーは描画しないためです。 - TTFB（サーバー応答時間）を短縮する。 キャッシュ、CDN、高速なオリジンなど、最初のバイトを早く返す対策はFCPを直接短縮します。
- フォント読み込みを直す。
font-display: swap（代替テキストをすぐに表示し、準備できたらWebフォントへ切り替える）またはfont-display: optional（キャッシュ済みでなければWebフォントを使わない）を使います。重要なテキストにfont-display: blockを使うとFCPへの影響が最も大きくなるため避けてください。
次に残りを整える：
- 必要なオリジンへpreconnectする（
<link rel="preconnect">）。重要な第三者オリジンとの接続を早く確立すると100～500ミリ秒短縮できることがあります。 - 重要なリクエストをpreloadする（
<link rel="preload">）。クリティカルフォントやLCP画像が対象です。 - CSSをminifyし、未使用CSSと未使用JavaScriptを削除する。 ファイルが小さければ解析が速く、描画の妨げが早く解消します。
- 複数のリダイレクトを避ける、巨大なネットワークペイロードを避ける、静的アセットに効率的なキャッシュポリシーを設定する、過剰に大きなDOMを避ける、そしてクリティカルリクエストの深さを減らす。 いずれも最初の描画に影響する一般的なペイロード対策です。
FCP → TTFB → LCPの診断手順
私ならFCPをこのように使います。文書が示唆するものの詳しく説明していない枠組みです。3つの読み込み指標を1つのワークフローとして扱います。
- FCPが長い → レンダリングを妨げるリソースを確認する（
<head>内のCSS／JavaScript）。最も一般的な原因で、短時間で改善しやすい場所です。 - TTFBも確認する。 FCPに含まれるため、遅いサーバーはレンダリングを妨げる処理が関係する前からFCPを長くします。web.devの案内では、TTFBはFCPとLCPの両方に先行するため、ユーザーの75パーセンタイルが「良好」なFCPに届く速さでサーバーが応答する必要があります。
- 同じ問題がLCPへ連鎖することが多い。 FCPとLCPは根本原因を共有しやすいため、ランキングシグナルであるLCPも悪化します。ただし、確認すべき重なりであり、保証ではありません。LCPには最大要素固有のサイズ、優先度、読み込み経路といった要因があります。FCPの原因を直してもLCP改善を約束できません。最初に調べる場所として適切ですが、最後の手順ではありません。
SEO担当者にとってのFCPの価値は、より選択的なLCP計測が完了する前に、読み込み経路が健全かを低コストで早期確認できることです。
AI要約
Advanced版を簡潔にまとめます。
- FCP = ナビゲーション開始から、いずれかのコンテンツが初めて描画されるまでの時間。 テキスト、画像（背景画像を含む）、
<svg>、白以外の<canvas>が対象です。「画面にもう何か表示されているか」を示します。 - FCPはCore Web Vitalではありません。 ランキングシグナルはLCP、INP、CLSです。FCPはラボとフィールドの両方で使える補助的な診断指標で、直接のランキング要因ではありません。
- FCPはLCPの構成要素です。 FCPはLCP以前または同時に発生するため、同じレンダリングを妨げるリソースや遅いTTFBを発見できることがあります。これらはLCPを悪化させ、LCPは実際にランキングへ影響します。ただし、LCPには固有の要因があるため、FCPの原因を直してもLCP改善は保証されません。
- フィールドしきい値（CrUX p75）： 良好 ≤ 1,8秒 · 改善が必要 ≤ 3,0秒 · 不良 > 3,0秒。
- ラボ ≠ フィールドであり、「フィールド値は常に高い」は傾向であって規則ではありません。 Lighthouseデスクトップの約0,9秒という「緑」ラインは、固定条件でのクリーンな1回の実行なので、1,8秒のフィールドしきい値より厳格です。フィールド／CrUXは、実際の端末、ネットワーク、キャッシュ状態、ナビゲーション種類（bfcache復元やprerenderedページを含む）を集計します。差を問題と判断する前に母集団を合わせ、実際の数値にはフィールド、診断にはラボを使います。
- FCP対FP： First Paintは背景色だけでも任意の描画で発生します。FCPには対象コンテンツ（テキスト、背景画像を含む画像、SVG、白以外のcanvas）が必要です。常にFP ≤ FCPです。
- FCP対LCP： FCPはいずれかの対象コンテンツ、LCPは最大の対象候補です。どちらも実際のメインコンテンツが完成して役立つことを証明するものではなく、代理指標です。速いFCPと遅いLCPの組み合わせは実際によくあります。
- Lighthouse 10（執筆時点の現行版）の重み：10%。 TBT 30%、LCP 25%、CLS 25%、FCP 10%、Speed Index 10%であり、重みはLighthouseのバージョン間で変わります。
- 主な改善策（順番どおり）： レンダリングを妨げるCSS／JavaScriptをなくす → TTFBを短縮する → フォントを直す（
font-display: swap／optional）→ preconnect／preload → minify、キャッシュ、DOMを整える。
公式文書
GoogleによるFCPの一次資料です。
web.dev（Google）
- First Contentful Paint（FCP） — Philip Waltonによる基準となる定義、コンテンツに含まれるもの、1,8秒のしきい値、TTFBとリダイレクトに関するKey Point、Paint Timing APIとweb-vitalsライブラリを使った計測方法。
- Web Vitals — FCPの位置付け。Core Web Vitals（LCP、INP、CLS）を補足し、LCPの診断に役立つ「Other Web Vital」です。
- Largest Contentful Paint（LCP） — FCPとLCPの違い、および両者の関係。
- Time to First Byte（TTFB） — TTFBがFCPに先行し、その時間に含まれる理由。
- ユーザー中心のパフォーマンス指標 — FCPをラボとフィールドの両方で使える指標として分類しています。
Lighthouse／Chrome Developers
- First Contentful Paint監査 — Lighthouseデスクトップの評価帯（緑 ≤ 0,9秒）と、HTTP Archiveデータに対するFCPスコアの算出方法。
- LighthouseのPerformanceスコア — Lighthouse 10でFCPがPerformanceスコアの10%を占めることを含む、各指標の重み。
Google Search Central
- Core Web VitalsとGoogle Search — ランキングに関するページで、LCP、INP、CLSを掲載しています。FCPが載っていないことが要点です。
出典からの引用
Googleの文書に記録された発言です。各リンクは、出典ページ上の引用箇所へ移動するディープリンクです。
web.dev — 定義
- “First Contentful Paint (FCP) measures the time from when the user first navigated to the page to when any part of the page’s content is rendered on the screen.” (翻訳)「First Contentful Paint（FCP）は、ユーザーがページへ最初に移動した時点から、ページのコンテンツの一部が画面に描画されるまでの時間を測定します。」— Philip Walton、First Contentful Paint (FCP)、web.dev（2023年12月6日更新）。 引用箇所へ移動
web.dev — しきい値
- “sites should strive to have a First Contentful Paint of 1.8 seconds or less.” (翻訳) 「サイトはFirst Contentful Paintを1.8秒以下にすることを目指すべきです。」 — 同じ出典。 引用箇所へ移動
web.dev — FCPに含まれる時間（Key Point）
- “FCP includes any unload time from the previous page, connection set up time, redirect time, and Time To First Byte (TTFB) which can be significant when measured in the field.” (翻訳) 「FCPには、前ページのアンロード、接続確立、リダイレクト、Time To First Byte（TTFB）の時間が含まれ、フィールド計測では大きな割合になることがあります。」 — 同じ出典。
web.dev — Core Web Vitalsに対するFCPの役割
- “the metrics Time to First Byte (TTFB) and First Contentful Paint (FCP) are both vital aspects of the loading experience, and are both useful in diagnosing issues with LCP (slow server response times or render-blocking resources, respectively).” (翻訳) 「TTFBとFCPはどちらも読み込み体験の重要な側面であり、LCPの問題を診断するうえで役立ちます。」 — Web Vitals、web.dev。 引用箇所へ移動
Lighthouse — FCPスコアの算出方法
- “Your FCP score is a comparison of your page’s FCP time and FCP times for real websites, based on data from the HTTP Archive.” (翻訳) 「FCPスコアは、ページのFCP時間をHTTP Archiveに基づく実在サイトのFCP時間と比較したものです。」 — First Contentful Paint audit、developer.chrome.com。
Lighthouse — Performanceスコアの仕組み
- “The Performance score is a weighted average of the metric scores.” (翻訳) 「Performanceスコアは各指標スコアの加重平均です。」
- “The weightings have changed over time because the Lighthouse team is regularly doing research and gathering feedback to understand what has the biggest impact on user-perceived performance.” (翻訳) 「Lighthouseチームは、ユーザーが感じるパフォーマンスへの影響を把握するために継続的な調査とフィードバック収集を行っており、重みは時間とともに変化しています。」 — Lighthouse performance scoring、developer.chrome.com。
#:~:text=ディープリンクなしで掲載しています。引用を最終版として扱う前に、公開中のページで確認してください。Lighthouseの重みはLighthouse 10に基づくため、新しいバージョンが公開されている場合は再確認が必要です。 遅いFCPの切り分けチェックリスト
FCPが長い場合は、効果が大きい順におおむね並んでいる次の一覧を上から確認します。
- Lighthouseだけでなく、フィールド値を確認する。 実際のFCPにはCrUX／PageSpeed Insightsのp75を読み、Lighthouseは診断だけに使います。
- レンダリングを妨げるリソースを探す。
<head>内のCSSと同期JavaScriptが最大の原因です。Lighthouseの「Eliminate render-blocking resources」監査に一覧が表示されます。 - ファーストビューのクリティカルCSSをインライン化し、残りを非同期で読み込みます。
- 重要でないスクリプトへ
async／deferを追加し、第三者タグを最初の描画より後へ移します。 - TTFBを測る。 FCPに含まれるため、遅いサーバーは他の処理より先にFCPを長くします。キャッシュ、CDN、高速なオリジンを追加します。
- リダイレクトチェーンをなくす。 各ホップが最初のバイトより前に完全な往復通信を追加します。
- フォントを直す。
font-display: swapまたはoptionalを使い、重要なテキストにはblockを使いません。クリティカルフォントファイルをpreloadします。 - 必要な第三者オリジンへpreconnectし、LCP画像や重要リクエストをpreloadします。
- ペイロードを減らす。 CSSをminifyし、未使用のCSS／JavaScriptを削除し、効率的なキャッシュポリシー、小さなDOM、浅いクリティカルリクエスト経路を実現します。
- 最後にLCPを再確認する。 同じ改善でLCPも動いているはずであり、ランキングに影響するのはLCPです。
FCP早見表
フィールドしきい値（CrUX、75パーセンタイル）
| FCP時間 | 評価 |
|---|---|
| ≤ 1,8秒 | 良好 |
| 1,8～3,0秒 | 改善が必要 |
| > 3,0秒 | 不良 |
Lighthouseデスクトップ評価（ラボ。フィールドより厳格）
| FCP時間 | 色 |
|---|---|
| 0～0,9秒 | 緑（速い） |
| 0,9～1,6秒 | オレンジ（中程度） |
| 1,6秒超 | 赤（遅い） |
Lighthouse 10のPerformanceスコア重み（執筆時点の現行値。重みはLighthouseのバージョン間で変わります）
| 指標 | 重み |
|---|---|
| Total Blocking Time | 30% |
| Largest Contentful Paint | 25% |
| Cumulative Layout Shift | 25% |
| First Contentful Paint | 10% |
| Speed Index | 10% |
3つの読み込み指標の違い
| 指標 | 発生する時点 | Core Web Vitalか |
|---|---|---|
| First Paint（FP） | 背景色だけでも、ブラウザーが何かを描画したとき | いいえ |
| First Contentful Paint（FCP） | いずれかの実コンテンツ（テキスト／画像／SVG／canvas）が描画されたとき | いいえ（診断用） |
| Largest Contentful Paint（LCP） | ビューポート内で最大の要素が描画されたとき | はい |
発生順序：FP ≤ FCP ≤ LCP。
FCPの「コンテンツ」に含まれるもの
テキスト · 画像（背景画像を含む）· <svg>要素 · 白以外の<canvas>要素
要点
- FCPの時計はナビゲーション開始時に動き、リダイレクト、接続確立、TTFBを含みます。
- FCPはラボとフィールドの両方で測定できます。
font-displayにはswap／optionalを使い、block（最大約3秒の不可視テキスト）は避けます。- 第三者オリジンへのpreconnectは100～500ミリ秒短縮できることがあります。
FCPを測定するツール
フィールド（実ユーザー）データ
- PageSpeed Insights — URLのCrUX p75 FCP（フィールド）とLighthouse（ラボ）実行を並べて表示します。
- Chrome User Experience Report（CrUX） — APIまたはBigQueryから利用できる、フィールド値の基になる実ユーザーデータセットです。
- web-vitals JavaScriptライブラリ —
onFCP(console.log)を追加（または分析基盤へ送信）して、自サイトの訪問者からFCPを取得します。bfcacheとバックグラウンドタブの例外も処理します。
ラボ（シミュレーション）データ
- Lighthouse — Chrome DevTools、PageSpeed Insights、CLIで利用できます。FCPの診断に使い、特に「Eliminate render-blocking resources」監査を確認します。
- Chrome DevToolsのPerformanceパネル — 記録したページ読み込みで、First PaintとFirst Contentful Paintが発生した正確な時点を確認できます。
Paint Timing APIで自分で測定する
new PerformanceObserver((entryList) => {
for (const entry of entryList.getEntriesByName('first-contentful-paint')) {
console.log('FCP candidate:', entry.startTime, entry);
}
}).observe({type: 'paint', buffered: true});またはweb-vitalsライブラリを使う（推奨）
import {onFCP} from 'web-vitals';
onFCP(console.log);生のAPIでは処理できず、web-vitalsライブラリが処理する注意点がいくつかあります。バックグラウンドタブで発生したFCPを無視し、back/forward cacheからページを復元したときもFCPを報告します（bfcache復元では新しいナビゲーションイベントが自動で発生しないため、明示的な処理が必要です）。また、ナビゲーション開始時ではなくactivationStartを時計の起点にするprerenderedページも処理します。クロスオリジンiframe内のPaint Timingは今も既知の欠落です。メインコンテンツがiframe内に描画されるページでは、誤解を招くほど速いFCPが表示されることがあります。
本当のボトルネックを隠すFCPの誤り
- FCPをCore Web Vitalとして扱う。 FCPは有用な診断指標ですが、Googleのランキングシステムで使われるCore Web VitalsはLCP、INP、CLSです。FCPは真っ白な画面の段階を調査するために使い、フィールドのCWVデータの代わりにしないでください。
- 最初に描画されるという理由で小さなロゴを最適化する。 意味のない描画を早めると、有用なページコンテンツが遅いままでもFCPは改善できます。変更によって訪問者が実際に見るものが改善したか確認するため、FCPと一緒にLCPとフィルムストリップも確認してください。
- ページが真っ白なのに画像圧縮から始める。 何も描画できない場合、一般的な妨げはサーバー応答時間、レンダリングを妨げるCSS、同期JavaScript、フォントです。関係のないアセットを変更する前に、リクエストウォーターフォールを追ってください。
- 条件の異なるLighthouse実行を比較する。 端末エミュレーション、ネットワーク条件、キャッシュ状態、実行ごとのばらつきは、いずれもラボのFCPを変えます。同じ設定で複数回実行した結果を比較し、可能であればフィールドデータで確認してください。
真っ白な画面の時間予算
FCPの最終値を1つの問題として扱うのではなく、連続する3つの問いに分解します。
- HTMLが届くまでどのくらいか。 TTFBを調べます。応答が遅いとブラウザーは有用な処理を始められないため、サーバー、キャッシュ、リダイレクト、接続確立から確認します。
- ブラウザーが描画できるまでどのくらいか。 レンダリングを妨げるスタイルシート、同期スクリプト、フォントの挙動を調べます。HTMLが届いていても、メインスレッドやレンダリング経路が妨げられていることがあります。
- 実際に何が最初のコンテンツになるか。 フィルムストリップまたはトレースを使い、最初の描画が意味のあるテキストや画像であり、体験を改善せず指標だけを良く見せる小さな要素ではないことを確認します。
この枠組みによって、配信、描画、有用性の順に改善できます。各変更後に同じラボプロファイルで再実行し、どの段階が動いたかを確認してください。
理解度チェック：First Contentful Paint
FCPが測るものと診断方法に関する5つの簡単な質問です。それぞれ回答を選んでから、答えを確認してください。
読む価値のある資料
Google／web.dev
- First Contentful Paint（FCP） — 定義、しきい値、計測コード、改善策の完全な一覧を掲載した基準資料です。
- Web Vitals — FCPとCore Web Vitalsの関係、およびFCPが診断指標である理由を説明しています。
- Largest Contentful Paint（LCP） — FCPが診断に役立つCore Web Vitalです。
- Time to First Byte（TTFB） — FCPの時間に含まれるサーバー応答指標です。
Lighthouse
- First Contentful Paint監査 — デスクトップ評価帯とスコアの算出方法。
- LighthouseのPerformanceスコア — FCPの10%を含む各指標の重み。
関連する私の記事
- テクニカルSEO初心者ガイド — ページ速度が全体像のどこに位置するかを解説しています。
- Core Web Vitals：概要と改善方法 — FCPがつながるランキングシグナル指標です。
業界の資料
- First Contentful Paint（FCP） — Philip WaltonによるGoogleの基準記事。定義、しきい値、Paint Timing APIコード、改善策の完全な一覧を掲載しています。
- Web Vitals — FCPがCore Web Vitalsを補助する「Other Web Vital」であることと、LCP診断における役割を説明するGoogleの枠組みです。
- First Contentful Paint監査 — Lighthouseデスクトップの評価帯と、HTTP Archiveデータに対するFCPスコアの算出方法を扱うChrome Developers文書です。
- Time to First Byte（TTFB） — TTFBがFCPに先行してその時間に含まれ、遅いサーバーがブラウザーの最初の描画より前にFCP予算を消費する理由を説明するGoogleのガイドです。
- レンダリングを妨げるリソースをなくす — FCP最大の原因である、ブラウザーの描画を妨げる<head>内のCSSと同期JavaScriptについて説明するChrome Developersガイドです。
- Webフォント読み込み中もテキストを表示する — font-displayの値と、
blockがFCPを遅らせる一方でswapまたはoptionalがテキストを表示し続ける理由を説明するChrome Developers監査です。 - First Contentful Paint — CMS固有の改善ヒントと、フィールド対ラボの明快な説明を含むNitroPackの実践ガイドです。
引用に使える統計
- 良好なFCP = ≤ 1,8秒（実ユーザーの75パーセンタイル）。3,0秒までは改善が必要、それを超えると不良です（フィールド／CrUXしきい値）。 出典
- Lighthouseデスクトップはより厳格です。 ラボは実環境ではなく、速度を制限したシミュレーション環境で実行されるため、約0～0,9秒が「緑」です。 出典
- FCPはLighthouse 10のPerformanceスコアの10%です（執筆時点の現行値。重みはLighthouseのバージョン間で変わります）。TBT 30%、LCP 25%、CLS 25%、Speed Index 10%と組み合わされます。 出典
- 第三者オリジンへのpreconnectは、読み込み時間を100～500ミリ秒短縮できることがあります。 接続を早期に確立するためです。 出典
変更履歴
2026年8月20日に更新。
編集概要と記録された変更の詳細。変更の詳細
-
変更の詳細な注記は現在英語でのみ提供されています。
-
変更の詳細な注記は現在英語でのみ提供されています。
-
変更の詳細な注記は現在英語でのみ提供されています。
完全な比較は利用できません — この改訂の以前のスナップショットがアーカイブされていません。
2026年7月17日に更新。
編集概要と記録された変更の詳細。変更の詳細
-
変更の詳細な注記は現在英語でのみ提供されています。
完全な比較は利用できません — この改訂の以前のスナップショットがアーカイブされていません。