First Contentful Paint (FCP)
How long until the browser renders the first piece of content — any text, image, or non-blank pixel — after a visitor requests the page.
Vanity Risk
A fast FCP can mask a slow experience: painting a spinner or an empty layout quickly improves FCP without improving when the visitor can actually use the page. FCP is only meaningful read alongside LCP — first paint without meaningful paint is a vanity improvement.
What it measures
The end of the blank screen. FCP is the first sign of life — the moment a visitor knows the page is working at all. It is a supporting diagnostic metric rather than one of the three official Core Web Vitals, but it is a leading indicator for LCP: a slow FCP guarantees a slow LCP, so it is where load-performance debugging usually starts. A fast FCP followed by a slow LCP isolates the problem to the primary content asset rather than the critical rendering path.
Benchmarks
- Good: ≤ 1.8s at P75
- Needs improvement: 1.8s–3.0s at P75
- Poor: > 3.0s at P75
- Thresholds: Google web.dev (field data, 75th percentile; FCP is a diagnostic metric, not an official Core Web Vital)
Figures reviewed June 2026. Benchmarks vary by source and drift over time — treat as directional and verify against your own data.
What to watch
- Above 1.8s at P75: The critical rendering path is blocked. Render-blocking stylesheets and synchronous scripts in the document head are the classic causes, followed by a slow TTFB — the browser cannot paint anything until the first bytes arrive.
- FCP good but LCP poor: The shell paints fast but the main content lags. The bottleneck is the largest element (usually a hero image or a client-rendered block), not the page framework. Focus optimization on LCP, not FCP.
- FCP and TTFB both poor: The problem is upstream of the browser entirely. Fix server response time first; FCP cannot be faster than the bytes it is waiting on.
In practice
A single-page app showed FCP at 3.4s at P75 with users reporting a long white screen. The entire UI was deferred behind a JavaScript bundle that had to download, parse, and execute before anything rendered. Adding a server-rendered shell with a meaningful loading state cut FCP to 1.2s. Total time to interactive barely moved — but the perceived wait collapsed, because visitors saw something immediately instead of nothing.
Illustrative scenario — a representative composite, not a specific company.
Related: Largest Contentful Paint — FCP is the first pixel, LCP the meaningful one; debug FCP first, then close the gap to LCP.; Time to First Byte — FCP is bounded below by TTFB; rule out the server before blaming the front end.; Bounce Rate — a long blank screen is one of the earliest points at which a visitor decides to leave.