このページで: [隠れる]
訪問者は遅いサイトを待ちません. Google の調査によると、ページの読み込み時間が長くなると、 1 に 3 秒, バウンス確率が増加します 32%. First Contentful Paint は、ユーザーが空白の画面以外のものを初めて見たときの重要な瞬間を捉えます。.
簡単な回答: 最初の満足のいくペイント (FCP) 最初のテキストが送信されるまでの時間を測定するパフォーマンス指標です。, 画像, または SVG が画面に表示されます. 優れたFCPとは、 1.8 秒以下. FCP は直接 Google のランキング要素ではありませんが、, ユーザーの認識に影響を与え、LCP と相関します。, それはランキングに影響を与える.
最終レビュー済み: 2月 2026. 現在の web.dev ドキュメントと照合して検証された情報.
First Contentful Paint が実際に測定するもの
FCP は、ナビゲーションの開始からブラウザが最初に表示されるコンテンツをレンダリングするまでの時間を追跡します。. それはテキストかもしれない, 画像, SVG, または白以外のキャンバス要素. 背景色は考慮されません. ブランクロードスピナーも同様です.
こう考えてみてください: FCPが発火する前に, 訪問者は何かが壊れているのではないかと白い画面を見つめます. FCP後, 彼らはページが読み込まれていることを知っており、待つ可能性が高くなります.
FCP が起動する前に何が起こるか:
DNS ルックアップ → TCP 接続 → SSL ハンドシェイク → サーバー応答 (TTFB) → HTMLダウンロード → CSS解析 → 最初のペイント
各ステップに時間がかかります. これが、FCP がラボテストと実際のユーザーの間で異なる理由です。. テスト環境では、DNS ルックアップの厄介な現実を無視します。, 遅いモバイルネットワーク, 負荷がかかっているサーバー.
何が重要か “コンテンツ” FCP用
- HTML または Web フォントからレンダリングされたテキスト
- 画像 (CSS 背景画像を含む)
- ビジュアルコンテンツを含むSVG要素
- 白以外のキャンバス要素 (チャート, 図面)
カウントされないもの
- 白または空白のキャンバス
- プレースホルダーの背景色
- フレーム (彼らは自分自身のFCPを測定します)
- ブラウザUI要素
FCP が重要な理由 (ランキング要素ではないとしても)
FCP は Google のコア Web Vitals の 1 つではありません. 実際のランキングシグナルはLCPです (最大の満足のいくペイント), インド (次のペイントへのインタラクション), とCLS (累積レイアウトシフト). では、なぜ FCP に注目するのでしょうか?
1. FCP は LCP のフロアです. LCP は FCP よりも高速であることはありません. FCP が 3 秒, あなたのLCP (実際のランキングシグナル) 少なくとも 3 秒. FCP 問題を修正すると、通常、LCP 問題も修正されます.
2. FCP は体感速度に影響を与える. ユーザーはサイトの速度感を基準に判断します, 指標によるものではなく. コンテンツを表示するページ 1 2番目で終了 3 何も表示されない秒よりも秒が速く感じられます。 2.5 秒, たとえ総ロード時間が同じであっても.
3. FCPは直帰率に影響を与える. その空白の白い画面は、ユーザーが留まるか離れるかを決めるときです. 長く続くほど, コンテンツが表示される前に戻るボタンを押す人が増えるほど.
4. FCP アカウント 10% ライトハウススコアの. Lighthouse のスコアはランキングに直接影響しませんが、, 多くの監査やパフォーマンスレポートで使用されています.
FCP スコアのしきい値
Google は 3 つのパフォーマンス区分を定義しています:
- 良い: 1.8 秒以下
- 改善が必要: 1.8 に 3.0 秒
- 貧しい: より多い 3.0 秒
ここが重要です: あなたが必要です 75% ページ読み込み数 を打つ “良い” しきい値. ファイバーインターネットでの 1 回の高速負荷では、モバイルでの 100 回の低速負荷は相殺されません。.
コンテキストについて, ウェブ全体の FCP 中央値は約 2.5 HTTP アーカイブ データに基づくモバイルでの秒数. つまり、ほとんどのサイトは “改善が必要” ゾーン. 殴る 1.8 秒で大多数より先を行く.
モバイルとデスクトップのスコアは大きく異なります. モバイル デバイスのプロセッサが遅い, 携帯電話ネットワークにより遅延が増加します. サイトのスコアリング “良い” デスクトップではモバイルでは失敗する可能性があります. 必ず両方をチェックしてください.
FCP 対 LCP: 違いは何ですか?
どちらのメトリクスもペイントのタイミングを測定します, しかし、別の瞬間に:
FCP: コンテンツが初めて表示されるとき (ナビゲーションテキストだけでも).
LCP: 最大のコンテンツ要素の読み込みが完了したとき (通常、ヒーロー画像またはメイン見出し).
FCPが最初に発火する. ナビゲーション メニューのテキストが次のように表示される場合 0.8 秒, それがFCPです. ヒーロー イメージの読み込みが完了すると、 2.5 秒, それがLCPです.
SEOの違い: LCP は Web の重要な要素であり、ランキングに影響を与えます. FCP は診断指標です。. しかし、多くの原因が共通しているため、, FCP を改善すると、通常は LCP が改善されます.
現在の Core Web Vitals のしきい値:
- LCP: 良い下 2.5 秒
- インド: 良い下 200 ミリ秒
- CLS: 良い下 0.1
FCPの測定方法
両方のラボデータが必要です (管理されたテスト) そしてフィールドデータ (実際のユーザー). 彼らはさまざまな物語を語ります.
臨床検査ツール
Google PageSpeed Insights: 任意の URL を入力して、ラボとフィールドの両方のデータの FCP スコアを取得します. The “機会” このセクションでは、何が速度を低下させているかを正確に示します. 無料, セットアップは必要ありません.
灯台 (Chrome DevTools): 任意のページを右クリックします, 「検査」を選択します, 「灯台」タブに移動します. PageSpeed Insights よりもテスト条件をより細かく制御. レンダリングをブロックしているものの詳細な内訳を表示します.
ウェブページテスト: 複数の場所と接続速度からの高度なテスト. 場所固有の問題の診断に役立ちます.
フィールドデータ (実際のユーザー)
Chromeユーザーエクスペリエンスレポート (CrUX): サイトを訪問する Chrome ユーザーからの実際のデータ. 十分なトラフィックがある場合は PageSpeed Insights に表示されます. これは、Google がシグナルのランキングに実際に使用しているものです.
web-vitals JavaScript ライブラリ: これをサイトに追加して、すべての訪問者から FCP データを収集します:
輸入 {FCPについて} 「ウェブバイタル」より;
FCPについて(metric => {
// Google アナリティクスに送信する 4
タグ('イベント', 「ウェブバイタル」, {
メトリクス名: 「FCP」,
メトリック値: メトリック.値,
指標評価: メトリック.評価
});
});
Chrome DevTools パフォーマンス パネル
デバッグ用, パフォーマンスパネルでページロードを記録する. タイムライン上で FCP がレンダリングされたものと正確にマークされているのが表示されます。. これは、FCP が意味のあるコンテンツなのか、それとも単なる読み込みスピナーなのかを示します。.
即効性: The 80/20 FCP最適化の
完全な最適化ガイドを読む前に, 最小限の労力で最大の効果をもたらす変更を次に示します:
1. テキスト圧縮を有効にする. サーバーが Gzip または Brotli 圧縮応答を送信していない場合, 有効にする. 多くの場合、これは単一サーバーの構成変更であり、転送サイズを削減できます。 70%+.
2. フォント表示の追加: フォントに切り替える. この 1 つの CSS プロパティにより、フォントの読み込み中にテキストが非表示になるのを防ぎます。. ユーザーにはシステム フォントがすぐに表示されます, カスタムフォントが切り替わります.
3. 重要でない JavaScript を延期する. 追加 defer すぐに実行する必要のないスクリプト タグに追加. これにより、JavaScript が最初のペイントをブロックするのを防ぎます。.
4. ホスティングを確認してください. TTFB の場合 (最初のバイトまでの時間) 一貫して600msを超えています, フロントエンドをいくら最適化しても、良好な FCP は得られません. サーバーはより速く応答する必要があります. 考慮する VPSホスティング 共有ホスティングを使用している場合, または CDN を追加します.
5. PageSpeed Insights を実行して最初の問題を修正します “機会。” Google はペイントをブロックしているものを正確に教えてくれます. 推定節約額が最も大きいものから始めます.
完全な最適化ガイド
FCPはチェーンに依存します: DNS → 接続 → サーバー応答 → HTML ダウンロード → CSS 解析 → ペイント. 各部分を高速化する方法は次のとおりです.
サーバーの応答時間を短縮する (TTFB)
多くの場合、最初のバイトまでの時間が FCP に最も大きく影響します. サーバーがかかる場合 2 応答までの秒数, あなたの FCP がそれを下回る可能性はありません 2 秒.
- CDN を使用する (コンテンツ配信ネットワーク) ユーザーに近い場所からサービスを提供する
- データベースクエリとHTMLのサーバー側キャッシュを有効にする
- リダイレクトを減らす (それぞれに完全な往復が追加されます)
- プロバイダーが 200ms 未満の TTFB を配信できない場合は、ホスティングをアップグレードしてください
オンの場合 共有ホスティング 遅いTTFBの場合, 多くの場合、最も安価な修正は クラウドホスティング CDN内蔵.
レンダリングをブロックするリソースを排除する
ドキュメントヘッド内の CSS と JavaScript は、ダウンロードして実行するまでレンダリングをブロックします。.
- インラインクリティカルCSS (スクロールせずに見えるコンテンツのスタイル) HTML で直接
- 重要ではないCSSを非同期でロードする
- 追加
asyncまたdefer必須ではないJavaScriptへ - 可能な場合は、JavaScript を HTML の下部に移動します。
CSS配信の最適化
ブラウザは、CSS が影響する可能性のあるコンテンツを描画する前に、すべての CSS をダウンロードして解析する必要があります。.
- CSSを縮小する (空白とコメントを削除する)
- PurgeCSS などのツールを使用して未使用の CSS を削除する
- CSS @import を避ける (それぞれネットワークのラウンドトリップが追加されます)
- メディア属性を使用して CSS をメディア タイプごとに分割する
Web フォントの最適化
カスタム フォントは、ダウンロードされるまでテキストのレンダリングを完全にブロックする可能性があります.
- 使用
font-display: swap@font-face ルール内 - 重要なフォントをプリロードする:
<link rel="preload" href="font.woff2" as="font" crossorigin> - フォントの種類を制限する (各重みは別個のファイルです)
- 本文のシステムフォントを考慮する
すべてを圧縮して縮小する
- サーバーで Gzip または Brotli 圧縮を有効にする
- HTMLを縮小する, CSS, およびJavaScript
- 画像を最適化する (WebP または AVIF, 適切な寸法)
リソースヒントを使用する
事前接続 必要なサードパーティのドメインへ:
<リンクrel="事前接続" href ="https://fonts.googleapis.com">
プリロード 重要なリソース:
<リンクrel="プリロード" href ="クリティカル.css" として="スタイル">
控えめに使用してください. あまりにも多くのドメインに事前接続するとリソースが無駄になります.
DOM を簡素化する
大きい, 深くネストされた HTML は解析に時間がかかります. 構造をフラットに保つ, 過剰なラッパー div を避ける, スクロールせずに見えるコンテンツの遅延読み込み.
一般的な FCP 問題のトラブルシューティング
FCP はテストごとに異なります
ネットワークの状態とサーバーの応答時間は変動します. 複数のテストを実行し、中央値を使用する. フィールドデータの場合, 特定のセグメントかどうかを確認する (モバイルユーザー, 特定の地域) 悪いスコアを表示する.
良いラボスコア, 不十分なフィールドデータ
ラボテストは理想的な条件下で実行されます. 実際のユーザーの接続は遅い, 古い電話, 混雑したネットワーク. 実験室のデータよりも現場のデータを信頼する. DevTools でスロットルを有効にしてテストする.
FCPは改善したがLCPは依然として悪いまま
最初のコンテンツはマイナーなものかもしれません (ナビテキスト, ロゴ) メインコンテンツである一方で、 (ヒーローイメージ) まだ遅いです. FCP 時に実際に何がレンダリングされているかを確認する. 主要コンテンツの最適化に重点を置く.
ペイントをブロックするサードパーティのスクリプト
分析, チャットウィジェット, 広告スクリプトがレンダリングをブロックすることがよくあります. 監査する. 不要なものは延期または削除する. 一部のスクリプトはユーザー操作後にのみロードすることを検討してください。.
よくある質問
FCP は Google のランキング要素ですか?
いいえ, FCPはランキングに直接影響しない. SEO に影響を与える主要な Web Vitals は LCP です, インド, とCLS. でも, FCP 問題は原因が共通しているため、通常は LCP 問題も意味します. FCP を修正すると、実際のランキングシグナルが改善されることがよくあります.
FCPが高くなる原因?
最も一般的な原因はサーバーの応答が遅いことです (TTFB), レンダリングをブロックする CSS と JavaScript, 最適化されていないフォント, および大規模な非圧縮リソース. PageSpeed Insights を実行して、サイトをブロックしているものを正確に確認します.
モバイルの適切な FCP スコアはどれくらいですか?
同じ閾値: 下 1.8 秒は良いです, 1.8 に 3 秒は改善が必要, 以上 3 秒はダメだ. ネットワーク遅延とデバイスの処理能力により、モバイルは通常、デスクトップよりもスコアが悪くなります。. PageSpeed Insights でモバイルを個別に確認する.
FCP をブロックしているものを見つけるにはどうすればよいですか?
PageSpeed Insights を使用して、 “機会” セクション. より深い分析のために, Chrome DevTools のパフォーマンス パネルには、FCP が起動する前に何が起こったかをタイムラインで表示. Lighthouse は特定のレンダリングをブロックするリソースにもフラグを立てます.
ホスティングは FCP に影響しますか?
はい. ホスティングによって TTFB が決まります, 多くの場合、これが FCP 時間の最大の部分になります. サーバーの応答が遅いということは、FCP が遅いことを意味します, 期間. CDNサービス ユーザーに近い場所からコンテンツを提供することで役立ちます.
FCP と LCP のどちらに注目すべきか?
実際のランキングシグナルであるため、1 つしか選択できない場合は LCP に注目してください. ただし、ほとんどの最適化では両方の指標が改善されます. FCP は良好だが LCP が悪い場合, 問題はメインコンテンツです (大きなヒーローの画像, 読み込みが遅いセクション) 初期レンダリングではない.
FCP は Core Web Vitals とどのように関係するのか?
FCP は診断指標です, コアウェブバイタルではない. 問題の特定には役立ちますが、Google のランキング計算には反映されません. Web の 3 つの重要な要素は LCP です (読み込み中), インド (インタラクティブ性), とCLS (視覚的な安定性).
次に何をすべきか
まずは測定から. 今すぐ PageSpeed Insights を通じてサイトを実行し、モバイルとデスクトップの両方で FCP スコアを記録してください。. 見てください “機会” 具体的な推奨事項のセクション.
TTFBが高い場合 (500ミリ秒以上), 最初にアドレスホスティング. サーバーが遅い場合、フロントエンドをいくら最適化しても役に立ちません. 弊社のオプションを比較してください SSDホスティングガイド または検討してください クラウドホスティング 統合された CDN を使用する.
TTFB は問題ないが、FCP がまだ遅い場合, 早い段階で成功するように取り組む: 圧縮を有効にする, フォント表示を追加: スワップ, 重要でない JavaScript を延期する. これらの変更だけでも、多くの場合、FCP は次のように削減されます。 30-50%.
継続的なモニタリングのために, Web-Vitals ライブラリを追加して、実際のユーザーの FCP を長期にわたって追跡する. フィールドデータは、実際の訪問者がサイトをどのように体験したかを示します, 管理されたテストでのパフォーマンスだけではなく.