First Contentful Paint (FCP): Definition, Thresholds, Fixes

What is First Contentful Paint (FCP)?

First Contentful Paint (FCP) is the time from the start of navigation until the browser first paints any content from the page: text, an image (including a background image), an SVG or a non-white canvas. It is the first sign for a visitor that the page is loading, which makes it a good proxy for perceived loading speed.

FCP is not one of the Core Web Vitals, which are LCP, INP and CLS. web.dev lists it among the supporting metrics, useful for diagnosing a slow Largest Contentful Paint: the largest element cannot paint before the first content does.

FCP thresholds

web.dev recommends judging the 75th percentile of page loads, separately for mobile and desktop. A page is "good" when at least 75% of visits paint their first content within 1.8 seconds.

Example

A product page is built as a single-page app. The server answers fast, but the HTML is an empty container, so the visitor stares at a white screen until a large JavaScript bundle has downloaded and run. FCP waits for all of that. Rendering the page shell on the server, or inlining the critical CSS and deferring the bundle, lets the first text appear long before the bundle finishes.

What contributes to FCP

• Server response. Nothing paints before the first byte arrives, so a slow TTFB and redirects set a floor under FCP.
• Render-blocking resources. CSS and synchronous JavaScript in the head must load before the browser can paint.
• Heavy client-side rendering. The first content waits for JavaScript to download, parse and run.
• Web fonts that hide text. Text stays invisible until the font arrives.
• Large payloads and long request chains. Missing preconnects, weak caching and a high request count all add delay.

How to measure FCP

In the field, the Performance API exposes FCP as a paint entry:

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

In the lab, Lighthouse and the Chrome DevTools Performance panel report it. For field data, PageSpeed Insights shows Chrome UX Report values, or you can collect your own with the web-vitals library. Lab and field numbers often differ, because lab runs use a fixed device and network.

How to improve FCP

1. Lower the server response time with caching and a CDN, and remove redirects.
2. Defer non-critical CSS, and add defer or async to scripts that are not needed for the first paint.
3. Inline the critical above-the-fold CSS.
4. Preconnect to the origins you need early, as shown below.
5. Minify and compress CSS and JavaScript.
6. Use font-display: swap so text shows in a fallback font while the web font loads.

<link rel="preconnect" href="https://cdn.example.com" crossorigin>

Common mistakes

• Treating FCP as the goal. A tiny logo can paint early while the hero image takes seconds. Check LCP too.
• Testing only on a fast desktop. Judge mobile and desktop separately, as web.dev recommends.
• Comparing lab and field directly. A good Lighthouse score does not guarantee good field data.
• Ignoring what happens before rendering. Redirects, connection setup and TTFB all count towards FCP.

FAQ: First Contentful Paint

What is a good FCP score?

1.8 seconds or less at the 75th percentile of page loads. Between 1.8 and 3.0 seconds needs improvement, and above 3.0 seconds is poor.

Is FCP a Core Web Vital?

No. The Core Web Vitals are LCP, INP and CLS. FCP is a supporting metric that helps diagnose slow loading.

How is FCP different from LCP?

FCP marks the first content of any size, often text or a logo. LCP marks when the largest visible element, often a hero image or headline, has rendered.

Why is my FCP slow?

Usual causes are a slow server response, redirects, render-blocking CSS or JavaScript, client-side rendering and web fonts that hide text. PageSpeed Insights or a Lighthouse report shows which one dominates.

Can FCP be fast while the page still feels slow?

Yes. FCP only says something appeared. Slow LCP, input delay or layout shifts can still make the page feel slow, which is why FCP is read alongside the Core Web Vitals.

Track FCP over time with LoadFocus

Use the free Core Web Vitals checker for a quick read, or page speed monitoring to track your pages from several cloud locations with Lighthouse and get alerted when they slow down. The guide on monitoring Core Web Vitals with alerts and reports shows the setup. Sign up free to start.