FCPの改善は必要？Core Web Vitals外、急ぐかはLCPで決める

FCPが赤や黄色でも、Core Web Vitalsの3つが良好なら私は急いで直しません。LCPも良好でないときは、その原因を探る手がかりとして見る価値があります。この記事は、PageSpeed InsightsでFCPが赤や黄色になっていて、直すべきか迷っている個人ブロガーに向けて書きました。読み終えると、FCPが何の時間で何秒が線なのか、自分の場合に急ぐかどうか、急ぐなら何から見るかを決められます。

根拠にしたのは、web.dev の「First Contentful Paint（FCP）」「ウェブに関する主な指標」「Largest Contentful Paint を最適化する」、Googleの「PageSpeed Insights について」、Chromeの開発者向けサイトのLighthouseのFCPのページと「パフォーマンス分析情報」の一覧、Search Consoleヘルプの「Core Web Vitals レポート」、Google 検索セントラルのページ エクスペリエンスの説明で、2026年10月21日に日本語版と英語版を読み比べました。ページ エクスペリエンスの説明を除く7ページの日本語版はAIによる翻訳と注記されていて、訳が崩れている文がいくつかあったので、そこは英語版を私が訳しています。

私はこの記事のために、自分のブログのFCPをPageSpeed InsightsやLighthouseで測ってはいません。画面や項目の名前は上の文書に書かれている字で呼んでいます。急ぐかどうかの分け方と見る順番は私の決め方で、Googleの文書にこの形で書かれているわけではありません。

結論:FCPはCore Web Vitalsに入らない。急ぐかはLCPを見て決める

文書に書かれていることと、そこから私が決めている見方をまとめると、次の4つです。

• FCPは、最初に何か1つが描かれるまでの時間。いちばん大きなものが描かれるまでの時間であるLCPとは別の指標です
• 1.8秒以下が良好、3.0秒を超えると低速。web.dev とPageSpeed Insightsの上の欄の線は同じです。下の欄の色の線は、パソコンだけ厳しい別の線が書かれています
• Core Web Vitals は LCP・INP・CLS の3つで、FCPは入らない。PageSpeed Insightsの合否にも入らないので、FCPだけが赤いなら私は急ぎません
• LCPも良好でないなら、FCPを手がかりに、サーバーの応答と最初の描画を止めるCSSやスクリプトを見る。web.dev は、LCPを最適化するならFCPとTTFBも使うよう書いています。見るのは、上の欄の実際の訪問のデータが先です

FCPとは:ページを開いてから、最初に何か1つが描かれるまでの時間

web.dev のFirst Contentful Paint（FCP）は、FCPをこう説明しています。

First Contentful Paint（FCP）は、ユーザーがページに初めて移動してから、ページのコンテンツのいずれかの部分が画面上にレンダリングされるまでの時間を測定します。
— web.dev「First Contentful Paint（FCP）」

ここで言うコンテンツは、文字、画像(背景画像を含む)、<svg> の図、白以外の <canvas> だと続けて書かれています。真っ白な画面から、読者の目に何かが見え始めるまでの時間、ということです。同じページは、そのときまだ全部は描かれていない点がLCPとの違いだとして、LCPはページのメインの中身が読み込み終わった時点を測るものだと説明しています。LCPが何の時間かはLCPの改善とは？PageSpeed Insightsで4つの内訳を確かめるに書きました。

もう1つ、英語版は、FCPには前のページを閉じる時間、接続の準備、リダイレクト、サーバーが最初の1バイトを返すまでの時間(TTFB)が含まれ、実際の訪問ではこれが大きくなりうるので、実際の訪問と試験で数字が違う元になる、と注意しています(私の訳。日本語版はこの部分を、前のページを読み込む時間のように訳していて、意味がずれています)。測る場所ごとに数字が違う理由はCore Web Vitalsの計測はどこで？実際の訪問と試験で数字が違う理由にまとめました。

FCPは何秒なら良好？1.8秒以下が良好、3.0秒を超えると低速

web.dev の同じページは、目標をこう書いています。

優れたユーザー エクスペリエンスを提供するには、サイトで 1.8 秒以内にファースト コンテンツフル ペイントを実現するようにします。
— web.dev「First Contentful Paint（FCP）」

英語版は "1.8 seconds or less"(1.8秒以下)です。図の説明は日本語版も英語版も、1.8秒以下が良好、3.0秒を超えると低速という線で、その間が改善が必要だという語は図の代替テキストのほうにあります。その代替テキストは、日本語版だけ「1.8 秒未満」となっています。英語版はどこも "or less" なので、ちょうど1.8秒は良好に入る、と読んでください。判定には実際の訪問の75パーセンタイル(4回に3回の訪問がその値か、それより速い値)を使い、モバイルとパソコンを分けて見るよう勧めています。

PageSpeed Insightsの上と下の欄に出る線も、並べると次のとおりです。

上の欄の線は、「PageSpeed Insights について」の英語版の表から写しました(日本語版はこの表の括弧の訳が崩れています)。下の欄の線は、Chromeの開発者向けサイトのLighthouseのFCPのページの英語版からで、このページの最終更新は2019年5月2日です。今のLighthouseでも同じ線かは、このページには書かれていません(日本語版はモバイルの表の、3秒を超える行の訳が崩れているので、英語版で読みました)。下の欄はパソコンのほうが厳しい線なので、同じページでもパソコンの色のほうが悪く出ることがありえます。見るならモバイルどうし、パソコンどうしで比べてください。下の欄の点数の中でFCPがどれだけの重みを持つかと、モバイルとパソコンの試験の条件はPageSpeed Insightsの見方は？下の点数より上の欄を先に見るに書きました。

FCPはCore Web Vitalsに入る？入らず、合否にも入らない

web.dev のウェブに関する主な指標は、Core Web Vitals の今のセットを LCP・INP・CLS の3つとしています。「PageSpeed Insights について」の英語版も、Core Web Vitals の指標は INP・LCP・CLS で、上の欄の合否はこの3つの75パーセンタイルで決まると書いています。FCPは上の欄に数字と色の棒が並びますが、合否には入りません。合否の決まり方は、上のPageSpeed Insightsの記事に書いたとおりです。

Search Consoleの「ウェブに関する主な指標」についても見ておきます。web.dev のFCPのページは、FCPを測れる場所の1つにSearch Consoleの速度レポートを挙げています(ページの最終更新は2023年12月6日)。速度レポートはweb.devのこのページに書かれた名前で、下のヘルプの本文には、この名前は日本語版にも英語版にも出てきません。また、今回読んだSearch Consoleヘルプの「Core Web Vitals レポート」の本文には、日本語版にも英語版にも、FCPという語は1度も出てきませんでした。ヘルプが判定の線を書いているのは LCP・INP・CLS の3つです。今のSearch Consoleの画面のどこかにFCPが出るかは、私は画面で確かめていません。

では、FCPは何のための指標なのか。「ウェブに関する主な指標」は、Core Web Vitals のほかにそれを支える指標があるとして、英語版で次のように書いています。

For example, 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).
— web.dev「Web Vitals」(英語版)

TTFBとFCPはどちらも読み込みの体験の大事な側面で、LCPの問題を見つけるのに役立ち、TTFBはサーバーの応答の遅さ、FCPは描画を止めるリソースの手がかりになる、という意味です(私の訳)。日本語版は最後の "respectively"(それぞれ)を訳しておらず、どちらがどちらの手がかりかが読み取れなくなっています。FCPは、それ自体を合格させる指標というより、LCPの原因を探るときの補助の指標として書かれている、と私は読んでいます。

順位について、Google 検索セントラルのページ エクスペリエンスの説明は「Google のランキング システムでは Core Web Vitals が使用されます。」と書く一方、レポートやサードパーティのツールで良い結果が出ても「…Google 検索の検索結果で上位に表示されることが保証されるわけではありません。」とも書いています。同じ回答は「Core Web Vitals 以外のページ エクスペリエンスの要素が検索結果でのランキング上昇に直接貢献することはありません。しかし、そういった要素はウェブサイトのユーザー満足度を向上させる可能性があり、それは通常、Google のランキング システムでも高く評価されます。…」とも書いています(前半だけを取らず、後半とセットで読みます)。このページの本文(日本語版・英語版)にFCPという語は出てこず、FCPがこの「要素」に当たるかは書かれていません。ただ、FCPは Core Web Vitals に入らないので、FCPだけのために、順位を理由に急いで直す根拠は無い、と私は読んでいます。この記事も、両方を書いたページエクスペリエンスは順位に効く？名指しはCore Web Vitalsだけの結論を越えません。

FCPが赤いとき、急がなくていい場合と見る価値がある場合

ここからは私の決め方です。FCPが赤や黄色のとき、私はLCPと、上の欄の実際の訪問のデータがあるかどうかで分けています。

1行目から3行目は、Core Web Vitalsの計測はどこで？と上のPageSpeed Insightsの記事で書いた線(データが無ければ判断する段階ではない、上の欄が合格なら下の欄の赤は急がない)を、FCPに当てはめたものです。Search Consoleで「改善が必要」だけが出ている状態を急がないのも、ウェブに関する主な指標レポートの見方は？URLグループとデータなしと同じです。6行目は、計測の記事の手順3と同じく、良好でない指標から見る線です。INPならINPの改善とは？サーチコンソールで「改善が必要」と出たら遅い操作を探す、CLSならCLSの改善とは？PageSpeed Insightsでずれる場所を探すに書きました。なお、重いと感じるページが決まっていて、読者のために軽くしたいだけなら、このどれにも当たらなくても、そのURLをPageSpeed Insightsに入れて見るところからでかまいません。

LCPも良好でないときに、FCPを見る理由

4行目と5行目の根拠は、web.dev のLargest Contentful Paint を最適化するです。PageSpeed Insightsの上の欄の補助の指標を使う節で、こう書いています。

LCP の最適化を目指す場合は、First Contentful Paint（FCP）と Time to First Byte（TTFB）のタイミングも使用する必要があります。これらは、LCP に関する貴重な分析情報を提供できる優れた診断指標です。
— web.dev「Largest Contentful Paint を最適化する」

同じ節は、数字どうしの差の読み方も書いています。TTFBとFCPの差が大きければ、描画を止めるファイルを大量に読み込む必要があるか、意味のある中身を描くまでに多くの処理が要ることを示している可能性がある。FCPとLCPの差が大きければ、LCPの画像などがすぐには使えないか、ブラウザがLCPを描く前にほかの作業をしていることを示す、という説明です(要約)。見るのは上の欄、つまり実際の訪問のデータの値です。

LCPの記事では、web.dev にならってLCPの時間を4つの内訳に分けました。FCPはその内訳の1つではありませんが、私の読みでは、FCPが遅いときに疑う場所は、内訳のうち最初のTTFBと、描画の遅延のうちページの先頭のスタイルシートやスクリプトが描画を止めている部分に重なります。逆に、FCPは良好でLCPだけが遅いなら、画像の読み込みが始まるのが遅い、画像そのものが重い、描かれる前にほかの処理がふさいでいる、といったところを、LCPの記事の手順で見ていきます。

FCPを改善するには、何から見る？私が決めている順番

その前に1つだけ。速度の数字より先に、記事の表示回数・掲載順位・クリック率を見る順番があり、それはページ表示速度はSEOに効くか、Core Web Vitalsより先に見る3つに書きました。そちらが済んで、速度を見る段階に来たときの順番です。

1. Search Consoleの「ウェブに関する主な指標」で、サイト全体のLCP・INP・CLSを見る。このレポートのヘルプの本文には、FCPは出てきません。「低速」があればそこから、「改善が必要」だけなら急ぎません
2. 記事のURLをPageSpeed Insightsに入れて、上の欄を見る。端末はSearch Consoleで問題が出たのと同じほう、出ていなければ自分のブログに多いほうを選びます。出ている数字が記事のものか、サイト全体のものかも確かめます。合否とLCPを見てから、FCPとTTFBの値を見て、上の表のどの行に当たるかを決めます
3. 見る価値がある行なら、原因は下の欄(試験)で探す。FCPに関係しそうなのは、主に分析情報の「レンダリングをブロックしているリクエスト」「ドキュメント リクエストのレイテンシ」「フォント表示」です
4. 直したら、試験で手元の変化を確かめてから、実際の訪問のデータが溜まるのを待つ。LCPの問題がSearch Consoleに出ていたなら、[トラッキングを開始]を押します

3つ目の名前は、Chromeの開発者向けサイトのパフォーマンス分析情報の一覧の字です。一覧の説明によると、「レンダリングをブロックしているリクエスト」はページの最初の描画を止めてLCPを遅らせているファイル、「ドキュメント リクエストのレイテンシ」は最初のHTMLが届くまでに時間がかかった理由、「フォント表示」は外から読み込む書体を待つ間も文字が表示されるかを見る項目です。web.dev のFCPのページも、FCPを良くするための一般的なガイドとして、主に、描画を止めるリソースを除く、サーバーの応答時間(TTFB)を縮める、リダイレクトを重ねない、Webフォントの読み込み中も文字を表示する、といった14のガイドを挙げ、LighthouseのFCPのページは、FCPで特に大事な問題の1つとして書体の読み込み時間を挙げています(英語版、私の訳)。ブログでは、テーマが読み込むCSS、ページの先頭に貼ったタグ、外から読み込む書体、記事のURLを変えたあとの転送の重なりがこれに当たりうる、と私は考えています。

web.dev のFCPのページのガイドは、Lighthouseの古い監査の名前で書かれています。今の下の欄の項目とどう対応するか、各項目の中身は「レンダリングをブロックしているリクエスト」とは？PageSpeedの分析情報に書きました。この順番の1つ目から4つ目は、計測の記事に書いた順番を、FCPのために言い換えたものです。

この記事で引いた公式の文書は、web.dev の3ページ、Googleの「PageSpeed Insights について」、Chromeの開発者向けサイトの2ページ(LighthouseのFCPのページと、パフォーマンス分析情報の一覧)、Search Consoleヘルプの「Core Web Vitals レポート」、Google 検索セントラルのページ エクスペリエンスの説明の8ページです(2026年10月21日に日本語版と英語版の本文を取得して照合しました)。

よくある質問

FCPはCore Web Vitalsの1つですか

いいえ。web.dev が今のセットとしているのは LCP・INP・CLS の3つで、FCPは入っていません。web.dev はFCPを、Core Web Vitals を支える指標の1つとして、LCPの問題を見つける手がかりに挙げています。

FCPが赤いと、検索順位が下がりますか

読んだGoogleの文書からは、どちらとも言えません。ページ エクスペリエンスの説明がランキングで使うと書いているのは Core Web Vitals で、本文にFCPという語はありませんでした。同じページは、Core Web Vitals 以外のページ エクスペリエンスの要素はランキングの上昇に直接貢献しないと書き(ただし、ユーザー満足度を通じて、ランキング システムでも通常高く評価されるとも続けています)、Core Web Vitals についても、良い結果で上位表示が保証されるわけではないと書いています。FCPがその要素に当たるかは書かれていませんが、FCPは Core Web Vitals に入らないので、FCPだけが赤い状態を順位のために急いで直す根拠は無い、と私は読んでいます。

パソコンのほうが、FCPの色が悪く出ます

下の欄(試験)の色なら、ありえます。LighthouseのFCPのページによると、パソコンは0.9秒までが緑、1.6秒を超えると赤で、モバイルより厳しい線です。同じ秒数でも色が違って見えるので、比べるならパソコンどうし、モバイルどうしで、前に測ったときと比べてください。上の欄(実際の訪問)の線は、モバイルとパソコンで同じ1.8秒と3.0秒です。

上の欄にFCPが出ません

記事1本の訪問が少ないと、実際の訪問のデータが足りず、サイト全体(オリジン)の数字に切り替わるか、何も出ません。「PageSpeed Insights について」もそう書いています。その段階では、下の欄のFCPでおおよその見当をつけるところまでにして、急いで直すかどうかを決めないのが私のやり方です。

まとめ

• FCPは、ページを開いてから文字や画像などが最初に1つでも描かれるまでの時間。LCPは、いちばん大きなものが描かれるまでの時間で、別の指標
• web.dev とPageSpeed Insightsの上の欄の線は、1.8秒以下が良好、3.0秒を超えると低速。下の欄の色は、Lighthouseの2019年のページではパソコンだけ0.9秒・1.6秒の厳しい線
• Core Web Vitals は LCP・INP・CLS の3つで、FCPは入らず、PageSpeed Insightsの合否にも入らない。今回読んだSearch Consoleのヘルプとページ エクスペリエンスの説明の本文にも、FCPは出てこない
• 上の欄で Core Web Vitals が合格していて、FCPだけが赤いなら急がない(私の決め方)。上の欄が出ないなら、FCPで判断する段階ではない
• LCPも良好でないときは、web.dev がLCPの診断に使うよう書いているとおり、FCPとTTFBを手がかりに、サーバーの応答(TTFB)と、最初の描画を止めるCSSやスクリプトを疑う。見るのは上の欄の実際の訪問のデータが先
• 順位については、Googleは Core Web Vitals をランキングで使うと書く一方、良い結果でも上位表示は保証されないとも書いている。Core Web Vitals 以外の要素は直接貢献しない(ただしユーザー満足度を通じて通常は評価される)ともあるが、FCPがその要素に当たるかは書かれていない。FCPだけのために順位を理由に急ぐ根拠は無い(私の読み)

FCPだけが赤く、Core Web Vitals の3つが良好なら、その数字を追いかける時間は、すでに検索結果に出ている記事の中身やタイトルを見直すほうに回せます。

ここからは自分のツールの宣伝になることを、先に断っておきます。

FCPだけが赤く、急ぐ数字が無かったなら、リライトレーダーに記事のURLを入れて、見出しや本文の直す点を見てみてください。もっと具体的に深掘りするなら、Search Consoleのデータを入れると、どの記事から直すかの順番まで出ます。URLの診断で送るのは入れたURLだけで、本文は保存しません。Search Consoleの「ページ」タブのエクスポートをZIPのまま置くと、掲載順位4.0〜20.5位のページから手を入れる候補を順に並べます。判定と、そのうち1記事分の診断カードまでは無料です。有料は2,980円(税込)の買い切りで3記事分(候補が4件以上のときだけご案内)、生成の期限は購入から90日間で、月額課金はありません。CSVはブラウザの中で読み、送るのは候補ページのURLと、診断カードを出すときの狙いキーワード・順位・表示回数・CTRだけです。

⚠️ URLの診断は本文だけを読み、順位・表示回数・CTRは使いません(それらを使うのはSearch Consoleのデータを入れたときです)。このツールはFCPも表示速度も測らないので、FCPやLCPの数字は、PageSpeed InsightsとSearch Consoleで確かめてください。