First Contentful Paint (FCP)
First Contentful Paint(FCP)は、ユーザーがページをリクエストしてから、最初のコンテンツ(テキスト、画像、SVG、または白以外のキャンバス)が画面に描画されるまでにかかる時間を測定します。これは、ユーザーが「このページは反応している」という最初の兆しを目にする瞬間です。
First Contentful Paint(FCP)は、ユーザーがページをリクエストしてから、最初のコンテンツ(テキスト、画像、SVG、または白以外のキャンバス)が画面に描画されるまでにかかる時間を測定します。これは、ユーザーが「このページは反応している」という最初の兆しを目にする瞬間です。
なぜ重要か
真っ白な画面を見つめるユーザーは、すぐに離脱します。Nielsen Norman Groupの調査によると、最初の視覚的な反応が1秒を超えると、注意力は急激に低下します。FCPは今日では公式のCore Web Vitalではありませんが、Lighthouseのパフォーマンススコアの主要な構成要素であり、LCPの先行指標です。FCPが遅ければ、LCPが良好になることは決してありません。
しきい値
| 評価 | FCP |
|---|---|
| 良好 | 1.8秒以下 |
| 改善が必要 | 1.8〜3.0秒 |
| 不良 | 3.0秒超 |
Chrome User Experience Reportの実ユーザーデータの75パーセンタイル(p75)で測定されます。
TTFB → FCP → LCP → INP
ページの読み込みは、連続する指標のタイムラインです。
- TTFB: サーバーが最初のバイトを送るまでの時間
- FCP: 最初のコンテンツが描画されるまでの時間
- LCP: 最大のコンテンツ要素が描画されるまでの時間
- INP: ユーザーの操作が視覚的に反応するまでの時間
順序が重要です。TTFBが遅ければFCPは速くなれず、LCPも速くなれません。パフォーマンスの作業は「上から」始めなければなりません。
FCPを遅くする要因
遅いTTFB: 遅いサーバーは、同じ分だけFCPを遅くします。
レンダリングをブロックするリソース: <head>内の外部CSSと同期JSは、ブラウザが描画する前にダウンロードして実行されなければなりません。多すぎたり大きすぎたりすると、FCPが停滞します。
大きなDOMサイズ: 初期HTML内の数千の要素は、解析とレイアウトの時間を要します。
Webフォントの読み込み: まだ読み込まれていないカスタムフォントはFOIT(不可視テキストの一瞬の表示)を引き起こし、FCPが遅れて感じられます。
クライアントサイドレンダリング(CSR): JSバンドルをダウンロードして実行した後にのみコンテンツを描画するReactやVueのアプリは、FCPを大幅に後ろにずらします。
最適化の方法
TTFBを改善する: CDN、サーバーサイドキャッシュ、DBの最適化。これが土台です。
レンダリングをブロックするリソースを排除する: asyncとdeferを使ってJSを遅延させます。重要なCSSをインライン化し、残りを非同期で読み込みます。
サーバーサイドレンダリング(SSR): Next.js、Astro、Remixのようなフレームワークを使い、サーバー上でHTMLを事前生成します。
フォントの最適化: font-display: swapは、カスタムフォントが読み込まれる間、フォールバックのテキストを即座に表示します。preloadは重要なフォントにのみ使います。
JSバンドルを縮小する: ツリーシェイキング、コード分割、未使用ライブラリの削除はすべて、初期バンドルを軽くします。
画像の最適化: ヒーロー画像を<link rel="preload">し、WebPまたはAVIFで配信します。
計測ツール
- PageSpeed Insights: CrUXのフィールドデータ+ラボデータ
- Lighthouse: ページ単位の診断
- Chrome DevTools → Performance: タイムライン上のFCP
- web-vitals JSライブラリ: 自サイトで実ユーザーデータを収集
Sources: