What FCP tells you#
FCP marks the moment a visitor first sees something — text, an image, an SVG or a non-white canvas — after clicking a link. Until then, they’re staring at a blank screen and wondering whether the page works. It isn’t one of the three Core Web Vitals, but it’s a key diagnostic: a slow FCP almost always means a slow LCP too.
Thresholds#
| Good | Needs improvement | Poor |
|---|---|---|
| ≤ 1.8 s | 1.8 – 3 s | > 3 s |
What delays FCP#
- Slow server response — see TTFB.
- Render-blocking CSS — large stylesheets the browser must download before painting.
- Synchronous JavaScript in the head.
- Web fonts that hide text until they load.
- Redirects before the final page.
Improving FCP#
- Fast hosting, full-page caching and a CDN.
- Inline the small amount of CSS needed for above-the-fold content; load the rest normally.
- Add
deferto scripts that don’t need to run before the page shows. - Use
font-display: swapso text appears immediately in a fallback font. - Preconnect to critical third-party origins (e.g. font CDNs).
Related: page speed, CSS performance tips, defer vs async.