What is First Contentful Paint (FCP)?

Definition

First Contentful Paint (FCP) is a performance metric that measures the time from when a user starts loading a page to when the first piece of DOM content is rendered on screen. This includes text, images (including background images), non-white canvas elements, or SVGs. FCP marks the point where the user first sees something meaningful appear, signaling that the page is actually loading. FCP is a diagnostic performance metric, not a Core Web Vital.

FCP differs from First Paint (FP), which triggers when anything renders, including background colors or non-meaningful visual changes. FCP specifically requires content, text or images that a user would recognize as page content. The gap between FP and FCP reveals whether your page renders a blank shell first (fast FP, slow FCP) or renders content immediately (FP and FCP nearly simultaneous). Pages with a large gap between FP and FCP typically have render-blocking resources or client-side rendering that delays meaningful content appearance.

Why It Matters

FCP is a critical early indicator of perceived page speed. If FCP is slow, visitors see a blank white screen for too long and may assume the site is broken or abandon it entirely. While Largest Contentful Paint (LCP) measures when the main content loads, FCP captures the user's first visual feedback that something is happening. A fast FCP reassures visitors that the page is responsive, even if the full content hasn't loaded yet.

FCP also helps diagnose performance bottlenecks in the early stages of page rendering. If both FCP and LCP are slow, the problem is likely server-side (slow TTFB) or render-blocking resources preventing any content from appearing. If FCP is fast but LCP is slow, the issue is likely with a specific heavy resource (like an unoptimized hero image) that loads after initial content. This diagnostic value makes FCP an important metric even though it's not a Core Web Vital directly.

How to Measure

Measure FCP using Google PageSpeed Insights, Chrome DevTools (Performance tab), or the Web Vitals JavaScript library. Target thresholds: under 1.8 seconds is good, 1.8-3.0 seconds needs improvement, and above 3.0 seconds is poor. FCP is reported alongside Core Web Vitals in most performance tools but is classified as a diagnostic metric rather than a Core Web Vital itself.

Use FCP in combination with other timing metrics to diagnose rendering issues. Compare FCP to TTFB to understand how much time is spent on server response versus client-side rendering. Compare FCP to LCP to understand whether the main content loads quickly after initial content or if there's a significant delay. Chrome DevTools Performance tab shows both FCP and LCP as markers on the timeline, making it easy to visualize the rendering sequence and identify bottlenecks between each stage.

How Racoons.ai Helps

Racoons.ai captures FCP as part of its comprehensive page performance audits. Our AI uses FCP alongside other timing metrics to diagnose early rendering bottlenecks, such as render-blocking stylesheets, slow server response times, or large HTML payloads. You get specific recommendations to ensure visitors see content as quickly as possible.

Best Practices

Minimize the time between the browser receiving the HTML response and rendering the first content. The three main factors that delay FCP are: slow server response (TTFB), render-blocking resources (CSS and synchronous JavaScript that must be downloaded and parsed before anything can render), and large HTML payloads that take time to parse. Inline critical CSS in the HTML head so the browser has the styles it needs to render above-the-fold content without waiting for external stylesheets.

Use font-display: swap to ensure text content renders immediately with a fallback font rather than waiting for web fonts to download (which causes Flash of Invisible Text). Minimize the number of round-trips required before first content can appear, combine or inline critical resources, and ensure your server sends the HTML response as quickly as possible. For single-page applications, implement server-side rendering or static generation so the initial HTML contains actual content rather than an empty shell that requires JavaScript to populate.

Frequently Asked Questions