First Contentful Paint (FCP) is the time between a visitor starting to load a page and the browser drawing the first piece of content on screen, such as a line of text, a logo or an image. It measures the moment a visitor sees that something is happening, rather than a blank white screen.
How FCP works
The clock starts when the browser begins navigating to the page and stops at the first render of any text, image, SVG or non-blank canvas element. Background colours alone do not count. Google’s thresholds, measured at the 75th percentile of visits, are:
- Good: 1.8 seconds or less.
- Needs improvement: between 1.8 and 3 seconds.
- Poor: over 3 seconds.
Several things sit between the click and that first paint. The server has to respond, which is measured separately as time to first byte. Any redirects add a round trip each. The browser then has to download and process stylesheets and some scripts before it can draw anything, because they block rendering. Web fonts can hold text back if the site tells the browser to wait for them.
FCP is not one of the three Core Web Vitals. It is a supporting metric that feeds into the Lighthouse performance score and helps explain why the Core Web Vital for loading, Largest Contentful Paint, is slow. A page cannot paint its largest element before it paints anything at all.
Why it matters
A blank screen is when visitors give up. Someone tapping your result from a mobile search on a train with weak signal will wait a second or two for something to appear, but not much longer, and they will hit back and choose the next listing. A fast FCP reassures them the page is coming even if the full content takes a little longer.
It is also a useful early warning. If FCP is slow, the cause almost always sits in the first part of the loading process: hosting, redirects, or code that blocks rendering. That narrows down the fix. If FCP is fast but LCP is slow, the problem is more likely a heavy hero image or content loaded late by JavaScript.
Common mistakes
- Cheap or overloaded hosting. A slow server response delays everything, and no front-end tuning fully makes up for it.
- Redirect chains on entry. http to https to www to a trailing slash can add several hundred milliseconds before the page even begins.
- Loading every stylesheet and script in the head. Page builders and plugins often add files that block rendering on pages that do not use them.
- Hidden text while fonts load. Without font-display set to swap or optional, text can stay invisible until the web font arrives.
- Testing only on fast office broadband. FCP that looks instant on a desktop can be slow on a mid-range phone over 4G.
How to act on it
Run your main templates through PageSpeed Insights and look at both the field and lab FCP figures. The diagnostics list will flag render-blocking resources, server response time and redirects. Start with the server and redirects, since those delay everything that follows.
Then reduce what blocks the first render: inline the small amount of critical CSS needed for the top of the page, defer scripts that are not needed straight away, and use preload and preconnect for fonts and third-party origins the page needs early. Remove plugins you no longer use. Finding and fixing these loading bottlenecks is part of my technical SEO service.