What Is First Contentful Paint (FCP)?
First Contentful Paint measures how long a visitor stares at a blank screen before the first text or image appears. It's a supporting loading metric — not an official Core Web Vital — but it's the first clue when a page feels slow to start.
First Contentful Paint (FCP) measures the time from the moment a page starts loading to the moment the first piece of content appears on screen — the first line of text, the first image, an SVG, anything that isn't a blank background. In plain terms: it's how long a visitor stares at nothing before they see something. It's the first reassurance that the page is actually loading and not broken.
FCP is a supporting metric, not a Core Web Vital
This is the part older guides get wrong, so it's worth being clear. FCP is not one of the three official Core Web Vitals. The current three are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS) — and INP replaced First Input Delay (FID), which was retired in March 2024.
FCP is a diagnostic metric. You'll see it reported in Lighthouse and PageSpeed Insights, and its main job is to help you understand why your LCP is slow. If FCP is poor, the page is slow to render anything — so LCP, which waits for the biggest element, can't possibly be fast. Fix FCP and you've usually moved LCP in the right direction too. Think of FCP as the early-warning light and LCP as the metric Google actually scores.
What counts as "good"
Lighthouse uses these thresholds for FCP:
| Rating | First Contentful Paint |
|---|---|
| Good | ≤ 1.8s |
| Needs work | 1.8 – 3.0s |
| Poor | > 3.0s |
As with the real Core Web Vitals, what matters most is the experience of real visitors on real connections — not a single fast result on your own fast laptop.
What affects FCP
A slow FCP almost always traces back to one of three things:
- Server response time (TTFB). Before the browser can paint a single pixel it has to receive the HTML. A slow host, no caching, or a sluggish database query means the browser is sitting idle, waiting. This is the big one.
- Render-blocking CSS and JavaScript. The browser won't paint until it has
processed the stylesheets and scripts in the page
<head>. Heavy or badly-ordered resources hold the first paint hostage. - Web font loading. If text is hidden until a custom font downloads, your first paint waits on that font — sometimes for a full second or more.
How to improve it
- Get the HTML out faster. Server-level caching and a quick host shrink TTFB so the browser starts painting sooner.
- Trim render-blocking resources. Inline critical CSS, defer non-essential JavaScript, and stop loading scripts the first screen doesn't need.
- Tame your fonts. Use
font-display: swapso text shows immediately in a fallback font, then swaps to the custom one once it loads. - Use a CDN. Serving assets from a location near the visitor cuts the round-trip that delays the first paint.
A lot of this — caching, TTFB, the speed of the box your site runs on — is hosting work, not something you tweak in your content. That first paint arrives sooner when the server behind it is fast and properly configured, which is exactly the part a managed host should be handling so you can get on with the business.
Let Site Schema handle this for you.
Managed WordPress hosting with the hard parts done for you.
Faster hosting means a quicker first paint