Guides

Every performance metric answers a question, and the metric is only worth as much as the question. First Contentful Paint asks one that every visitor asks without thinking: how long am I looking at nothing? Not how long until the page is usable, not how long until the big image lands, just how long until anything at all appears.

That makes FCP the earliest honest signal a page can give. It is also, for reasons worth understanding, not a Core Web Vital, and that changes how much weight it deserves in your priorities.

What FCP actually measures

FCP measures the time from when the user starts navigating to the page to the moment any part of the page's content is first rendered on screen. Content has a specific definition here rather than an intuitive one: text, images including background images, SVG elements, and canvas elements that are not blank white.

The distinction that matters is between First Paint and First Contentful Paint. First Paint fires as soon as the browser changes any pixel, which includes painting a background colour over the previous page. Nothing has been communicated at that point. FCP waits for something a person could actually read or look at.

Because FCP is the first content, it is by definition earlier than or equal to Largest Contentful Paint. On a page whose largest element is also its first, the two are the same number. On a page that shows a headline immediately and a hero image three seconds later, they are far apart, and that gap is the interesting part of the reading.

The thresholds, and the Core Web Vital it is not

Google publishes three bands for FCP, measured at the 75th percentile of page loads and segmented by device: good at 1.8 seconds or less, needs improvement between 1.8 and 3 seconds, and poor above 3 seconds. Mobile and desktop are scored separately, which matters because the same site routinely sits in different bands on each.

• Total Blocking Time - 30%
• Largest Contentful Paint - 25%
• Cumulative Layout Shift - 25%
• First Contentful Paint - 10%
• Speed Index - 10%

FCP is not a Core Web Vital. The Core Web Vitals are LCP, INP and CLS, and those three are what feed Google's page experience signals. FCP sits beside them as a diagnostic metric: reported by PageSpeed Insights and the Chrome User Experience Report, weighted in the Lighthouse performance score, but not part of the ranking-facing set itself.

That is not a reason to ignore it. It is a reason to use it for what it is good at, which is telling you whether your problem starts before rendering or during it. In the Lighthouse 10 performance score, the weights are distributed like this:

What actually delays it

The first component of FCP is time to first byte. Nothing can be painted before the first byte of HTML arrives, so a slow server, a slow query or a distant origin sets a floor under FCP that no amount of front-end work will lift. If TTFB is 1.5 seconds, an FCP under 1.8 is close to impossible.

The second is render-blocking resources. A stylesheet in the head must be downloaded and parsed before the browser will paint, because painting with the wrong styles and repainting is worse than waiting. Synchronous scripts in the head block parsing outright. Each one is a serialised round trip inserted between the HTML arriving and anything appearing.

The third is web fonts, and it is the one people miss. A font declared with font-display: block gives the browser a period during which text in that font is rendered invisibly while the file downloads. Invisible text is not contentful, so FCP waits for it. Switching to font-display: swap paints a fallback face immediately and swaps in the real one on arrival, trading a visible reflow for an earlier first paint of actual words.

Measuring it yourself

In the field, FCP comes from the Chrome User Experience Report, which is what PageSpeed Insights shows in its top section for real users on real connections. That is the number to trust, because it reflects the devices and networks your visitors actually have rather than the machine you happen to be testing on.

In the browser, a PerformanceObserver watching the paint entry type reports both first-paint and first-contentful-paint. Reading both is more useful than reading either alone. A large gap between them means the browser had pixels to push and chose a background colour first, which is the signature of a stylesheet or a font standing between your HTML and your reader.

FCP or LCP: which to fix first

If FCP and LCP are both poor, fix the shared cause and both move. TTFB, render-blocking CSS and blocking fonts sit upstream of both metrics, so work spent there is never wasted. If FCP is good and LCP is poor, the problem is specific to your largest element, usually an unoptimised hero image or one the preload scanner discovers too late.

The pattern worth recognising is the inverse: a poor FCP with an acceptable LCP. That means the browser sat idle before painting anything and then caught up quickly, which is almost always a blocking resource in the head rather than a weight problem. It is also the cheapest of the three situations to fix.