First Contentful Paint (FCP)

First Contentful Paint, or FCP, measures how long it takes for the first piece of content to appear on screen after someone navigates to your page. That first paint is the moment a blank white screen becomes something, the point at which a visitor gets the first sign that the page is loading rather than broken. A fast FCP reassures people that something is happening; a slow one leaves them staring at nothing.

What FCP measures

FCP records the time from navigation until the browser renders the first bit of DOM content. That content can be text, an image, an SVG, or a non-white canvas: essentially the first thing that is not a blank background. It marks when rendering begins, not when the page is complete or usable, which makes it a pure measure of how quickly the browser gets started.

Because it only cares about the first paint, FCP is heavily influenced by everything that happens before rendering can begin: the server response, and any resources that block the browser from drawing.

What is a good FCP score

Google defines three bands, measured at the 75th percentile of real page loads across mobile and desktop:

• Good: 1.8 seconds or less
• Needs improvement: between 1.8 and 3 seconds
• Poor: more than 3 seconds

FCP also carries weight in the Lighthouse performance score, so improving it lifts both the real experience and the lab number you see in PageSpeed Insights.

Is FCP a Core Web Vital?

No, and this is worth being clear about. FCP is not one of the three Core Web Vitals, so it is not a direct Google ranking signal the way Largest Contentful Paint, Cumulative Layout Shift and Interaction to Next Paint are. It is a diagnostic loading metric. That said, FCP and LCP share most of their causes, so a fast FCP is usually the first step toward a fast Largest Contentful Paint, which is a ranking factor. Fixing FCP is rarely wasted effort.

How FCP differs from LCP

The two are easy to confuse. First Contentful Paint marks when the first content of any kind appears. Largest Contentful Paint marks when the largest, most meaningful element appears. FCP tells you rendering has started; LCP tells you the main content the visitor came for is there. A page can have a quick FCP, painting a header and some text early, yet a slow LCP because the hero image arrives much later. You want both to be fast, and they are improved by overlapping but not identical fixes.

How FCP is measured: lab and field

FCP appears in both lab tools such as Lighthouse and field data from the Chrome UX Report, which reflects real users over a trailing 28-day window. You can also read it in the browser with the paint timing API:

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.name === 'first-contentful-paint') {
      console.log('FCP:', Math.round(entry.startTime), 'ms');
    }
  }
}).observe({ type: 'paint', buffered: true });

What affects FCP

Everything on the critical path between the request and the first paint feeds into FCP:

• Server response time. A slow Time to First Byte delays the moment the browser even receives the HTML.
• Render-blocking CSS and JavaScript. The browser will not paint until it has processed blocking resources in the head.
• Web fonts. Text can be held back if it waits on a font instead of showing a fallback.
• A long critical request chain. Each dependency the browser must fetch before it can render adds to the delay.

How to improve FCP

1. Reduce server response time

Nothing can paint until the HTML arrives, so a fast Time to First Byte is the foundation. Caching and a CDN are the biggest levers here. See reduce initial server response time.

2. Eliminate render-blocking resources

Render-blocking CSS and JavaScript in the head are the most common cause of a slow FCP. Defer non-critical scripts, and inline the critical CSS while loading the rest asynchronously. See eliminate render-blocking resources.

3. Show text immediately with font-display

Add font-display: swap so text paints in a fallback font right away instead of waiting for the web font. This alone can move FCP earlier on text-heavy pages.

4. Shorten the critical request chain

Reduce the number of resources the browser must fetch before it can render. Preconnect to critical origins, preload the few resources needed for the first paint, and keep the initial HTML lean so the browser reaches something paintable quickly.

How to verify your FCP

Re-run PageSpeed Insights and confirm the lab FCP has improved, then watch the field data in the Chrome UX Report over its trailing 28-day window. Test on a mid-range mobile device with throttling, since a slow connection is where a poor FCP shows itself, and check several templates, because a cached article and an uncached landing page can start rendering at very different speeds.

Frequently asked questions

What is a good FCP score?

1.8 seconds or less at the 75th percentile of real users is good. Between 1.8 and 3 seconds needs improvement, and more than 3 seconds is poor.

What is the difference between FCP and LCP?

First Contentful Paint marks when the first content of any kind appears. Largest Contentful Paint marks when the largest, most meaningful element appears. FCP shows rendering has started; LCP shows the main content is ready.

Is FCP a Core Web Vital?

No. FCP is a diagnostic loading metric, not one of the three Core Web Vitals, so it is not a direct ranking signal. It shares causes with LCP, which is a Core Web Vital, so improving FCP usually helps LCP too.

How do I improve FCP?

Reduce server response time, eliminate render-blocking resources, use font-display: swap so text shows immediately, and shorten the critical request chain with preconnect and preload.

How is FCP measured?

It appears in lab tools like Lighthouse and in field data from the Chrome UX Report. In the browser you can read it through the paint timing API by observing the first-contentful-paint entry.