Watch a slow page load closely and you will notice it does not arrive all at once. There is a white screen, then suddenly a header, a menu, a line of text, and only later the big photo and everything else. That first flicker of content, the moment the screen stops being blank, is what First Contentful Paint records.
This is first contentful paint explained for people who look after a website rather than build browsers: what FCP measures, how it differs from LCP, what holds the first paint back, and a few cases where the number misleads. If you have been asking “what is FCP and should I care”, the short answer is that it is a useful early-warning metric, not a target in its own right.
First contentful paint explained: what it records
FCP is the time from when the visitor starts loading the page until the browser first paints any content from the page. “Content” here means text, an image (including a background image), an SVG graphic, or a drawn canvas element. A plain white or coloured background does not count; there has to be something from your page on the screen.
For the visitor, FCP is the reassurance moment. Before it, they are staring at a blank tab and wondering whether the link worked. After it, they know something is coming.
Google treats FCP as a diagnostic metric, not one of the Core Web Vitals. As a rough guide, web.dev suggests a good FCP is 1.8 seconds or less at the 75th percentile. It appears alongside the Core Web Vitals in PageSpeed Insights field data and in Lighthouse, which is why people often assume it is one of them. The three that are Core Web Vitals, LCP, INP and CLS, are covered in our introduction to Core Web Vitals.
FCP vs LCP: the first thing and the main thing
The two are easy to mix up because both are about painting. The difference is which paint they record.
| First Contentful Paint | Largest Contentful Paint | |
|---|---|---|
| Records | The first content painted | The largest content painted in the visible area |
| Typical element | Logo, menu text, a heading | Hero image, banner, large heading or paragraph |
| Visitor’s feeling | “It’s started” | “It’s here” |
| Core Web Vital? | No, diagnostic | Yes |
| Can it be later than the other? | Never later than LCP | Equal to or later than FCP |
FCP can never be later than LCP, because the largest piece of content is still a piece of content. Sometimes they are the same moment: if the first thing painted is also the largest, the two numbers match.
Reading the gap between FCP and LCP
Looking at the two numbers together tells you more than either one alone. Three patterns are common.
Early FCP, much later LCP
The page starts quickly, but the main content takes a long time to appear. The server and the first stylesheets are probably fine. The delay is in the LCP element itself: a large hero image, one discovered late, one that is lazy-loaded, or a slider that waits for its script. The diagnosis is the one set out in finding which part of LCP is slow.
Late FCP, LCP close behind
Nothing appears for a long time, then the page arrives nearly complete. The browser is being held up before it can paint anything at all. That points to the server response or to files that block rendering, discussed below.
Late FCP and a big gap after it
Both problems at once: something holds up the first paint, and the main content is slow too. Fix the first-paint delay first, because it pushes everything else back with it.
What first contentful paint is waiting for
Before the browser can paint anything, a few things have to happen. Any one of them can be the bottleneck.
The HTML has to arrive
The browser cannot paint a page it has not received. Everything in Time to First Byte, including redirects, DNS, connection, encryption and server time, comes before FCP. If the first byte takes a long time, FCP will too. That chain is broken down in what makes up time to first byte.
Stylesheets in the head have to load
By default, a browser will not paint until it has downloaded and processed the CSS files linked in the page head. It does this to avoid showing an unstyled page that then jumps into shape. A theme that loads several large stylesheets, or a builder that loads CSS for every widget it offers, delays FCP while all of them download.
Scripts in the head may have to run
A normal script tag in the head, without defer or async, stops the browser reading the rest of the page until the script has downloaded and run. Several of those in a row, especially from other domains, can hold the first paint back noticeably on mobile.
CSS and scripts that hold up painting are called render-blocking resources. What to do about them, and in what order, is the subject of our guide to render-blocking CSS and JavaScript, so we will not repeat the techniques here.
Fonts may hide the text
If your text is set in a web font and the browser is told to keep text invisible until that font arrives, the text is not painted, and it does not count towards FCP until it shows. On a slow connection this can mean a page with a visible layout but no words. How many font files you load, and from where, makes a difference; see how Google Fonts can slow a page down.
When FCP misleads you
Because FCP counts the first content of any kind, a few common site features can make it look better or worse than the real experience.
Page loaders and spinners
Some themes show a full-screen loading animation, a spinning logo or progress bar, while the real page loads behind it. The loader is content, so FCP fires early and looks excellent. The visitor, meanwhile, is still watching an animation instead of your page. LCP and a filmstrip of the load tell the true story. On most small business sites, removing the loader improves the real experience.
Page-hiding snippets
Some A/B testing and personalisation tools ask you to add a snippet that hides the page until their script has decided what to show, to prevent a flash of the original version. That hide delays FCP for every visitor, even those not in a test. If you no longer run experiments, remove the snippet along with the tool.
Consent banners painted first
If a cookie banner is the first thing painted on a first visit, FCP may look quick while the content behind it is still on its way. That is not wrong, exactly, but it is worth knowing what element you are measuring.
Mistakes people make chasing a faster first paint
- Loading every stylesheet asynchronously. The browser paints sooner, but it paints an unstyled page that then snaps into shape, which looks broken and can cause layout shift.
- Adding a loader “to make it feel faster”. It improves the number and worsens the wait, for the reason described above.
- Celebrating FCP while LCP stays slow. A quick header followed by a long wait for the main content is still a slow page to the visitor.
- Testing only on a fast office connection. Render-blocking files cost little on fibre and a great deal on patchy mobile data, so the delay may be invisible to you and obvious to customers.
The aim is a first paint that shows something genuinely useful, the page’s own layout and words, as early as the network and server allow.
How to see FCP for your own pages
- PageSpeed Insights shows FCP in both sections: field data from real visitors if your site has enough traffic, and the lab test below it.
- Chrome DevTools Performance panel marks FCP in its timings track when you record a page load, so you can see what was painted and what was still loading at that moment.
- Filmstrip views in tools such as WebPageTest show screenshots at intervals during loading. They make it obvious whether the first paint was useful content or just a loader or a header.
Test both mobile and desktop, and test a few page types. A blog post, a product page and the homepage can have quite different first paints.
FCP is one of the earliest signals in the whole loading process. For how it connects to hosting, caching, images and scripts, the guide to improving website speed brings the parts together.
Frequently asked questions
Why is my FCP good but my PageSpeed score still low?
FCP is only one of the measurements behind the lab score. A page can start painting quickly and still have a slow LCP, a lot of main-thread blocking from JavaScript, or layout shifts, each of which pulls the score down. Look at the other metrics in the same report to see where the time is going after the first paint.
Does a white background colour count as first contentful paint?
No. A background colour on its own is not counted as content. FCP needs something from the page itself to be painted, such as text, an image, an SVG or a canvas element. That is why a page can show a coloured screen for a moment before its FCP is recorded.
Can caching improve FCP?
Often, yes. A page cache shortens the server part of the wait, so the HTML arrives sooner and the browser can start on everything else earlier. Browser caching of stylesheets and fonts helps returning visitors, who no longer need to download those files before the first paint. First-time visitors still depend on how much has to load up front.
A blank screen that lasts too long usually has one or two causes, not ten. Tracing them, from the first byte through to the main content, is where the audit in our website speed optimisation service starts.
