What is FCP (First Contentful Paint)?
FCP marks the point when the browser renders the first piece of content. Learn what it means, how it differs from LCP, and how to speed it up.
First Contentful Paint (FCP) marks the point when the browser renders the first piece of DOM content — text, an image, an SVG, or a non-white canvas element. It’s the first signal to users that something is actually loading.
FCP is not a Core Web Vital, but it’s a key diagnostic metric. It sets the baseline for all other loading metrics — if FCP is slow, LCP will almost certainly be slow too.
FCP vs LCP: What’s the Difference?
Both measure loading speed, but they measure different things:
FCP — When does the browser show anything? LCP — When does the browser show the main content?
FCP might trigger when a navigation bar or loading spinner appears. LCP triggers when the hero image or headline loads. On a well-optimized page, the gap between FCP and LCP is small. A large gap suggests the main content is loading much slower than the initial page skeleton.
FCP Thresholds
| Score | Time |
|---|---|
| Good | Under 1.8s |
| Needs improvement | 1.8s – 3.0s |
| Poor | Over 3.0s |
What Causes a Slow FCP?
Render-blocking resources
CSS and synchronous JavaScript in the <head> block rendering. The browser won’t paint anything until these have been downloaded and processed.
<!-- Render-blocking: browser waits for this before painting -->
<link rel="stylesheet" href="styles.css" />
<script src="app.js"></script>
<!-- Better: preload critical CSS, defer non-critical JS -->
<link rel="preload" href="critical.css" as="style" />
<script src="app.js" defer></script>Slow TTFB If the server takes 2 seconds to respond, FCP can’t happen before 2 seconds. A slow TTFB is a floor on all loading metrics.
Large initial HTML An HTML document that’s 500KB+ takes longer to parse. Server-side rendering with efficient HTML helps.
Too many redirects
Each redirect adds a full round-trip. www → non-www → HTTPS → final URL can add 300–600ms.
No critical CSS inlining External stylesheets block rendering. Inlining the CSS needed for above-the-fold content allows the browser to paint immediately without waiting for the external file.
How to Improve FCP
Eliminate render-blocking resources This is the highest-impact fix. Defer JavaScript and inline critical CSS.
Reduce TTFB Use caching, a CDN, and optimized server-side code. Every millisecond of TTFB delays FCP by the same amount.
Inline critical CSS
Extract the CSS rules needed to style above-the-fold content and inline them in a <style> tag in the <head>. Load the full stylesheet asynchronously.
Use <link rel="preconnect"> for external resources
If your page loads fonts or scripts from external origins, establish the connection early:
<link rel="preconnect" href="https://fonts.googleapis.com" />
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />Reduce initial HTML size
Remove comments, unnecessary whitespace, and unused markup from the critical rendering path. Use server-side rendering to avoid empty <div id="app"> pages.
Minimize redirects Serve the final URL directly. Configure your web server to skip unnecessary redirect hops.
Interpreting FCP in Context
FCP tells you when the browser first starts painting. If FCP is fast but LCP is slow, the issue is with the main content loading (usually the hero image or a large text block). If FCP is slow, everything else is too — focus on TTFB and render-blocking resources first.
Run a speed test on debugutils.dev to see your FCP alongside LCP, TTFB, and the full request waterfall in one report.