First Contentful Paint(FCP)

Long definition

FCP marks the first visible feedback the user gets that their navigation worked. The blank page is over; something has been painted. The metric is timed from navigation start to the first frame containing any text or image, including SVGs and non-white canvases. The browser's own loading spinner doesn't count — content from the response does.

FCP sits between TTFB and LCP in the loading sequence. A bad TTFB guarantees a bad FCP; a good TTFB makes good FCP achievable but not automatic. The gap between TTFB and FCP is where render-blocking resources — synchronous CSS and JS in the head — do most of their damage. Eliminate or defer those, and FCP follows TTFB closely.

Google's thresholds on web.dev (75th percentile, field data):

• Good — under 1.8s
• Needs improvement — 1.8s to 3s
• Poor — above 3s

FCP is reported in Lighthouse, PageSpeed Insights, CrUX, and the PerformanceObserver API in browsers. It is not a Core Web Vital — Google replaced FCP-style thinking with LCP for ranking purposes — but FCP remains the cleanest diagnostic for "is the request-to-first-paint pipeline healthy".

Typical wins that move FCP without touching anything else: inline critical CSS, defer or async non-critical JS, preconnect to required origins, reduce server-side redirect chains, and eliminate web fonts blocking text rendering (use font-display: swap).

Common misconceptions

• "FCP is when the page looks done." It's when the first content paints — usually a header or background, not the hero. The "page looks done" metric is closer to LCP or Speed Index.
• "FCP is a ranking factor." Google ranks on Core Web Vitals (LCP, CLS, INP). FCP is diagnostic — it shows up in tools and helps debug why LCP is slow, but Google does not rank on it directly.
• "Improving FCP improves LCP proportionally." Sometimes. If your LCP element is the first painted content (text headline), they move together. If LCP is a hero image loaded after FCP, improving FCP alone doesn't move LCP.