First Contentful Paint (FCP)

The time from when the page starts loading to when any part of the page's content is rendered on the screen.

Detailed Explanation

FCP measures the user's perception of loading speed. Content here includes text, images (including backgrounds), or non-white `<canvas>` or SVG. A fast FCP (under 1.8 seconds) reassures the user that the site is actually working. Improving FCP involves optimizing server response time (TTFB) and eliminating render-blocking resources (CSS and JS).

Quick Summary

FCP is the moment the user first sees *anything*, the "is this site working?" signal. It's downstream of TTFB and upstream of LCP, so it's a useful checkpoint for diagnosing where load time goes.

Key Takeaways

Target: under 1.8s at the 75th percentile.
Bottleneck stack (in order): DNS + connect → TTFB → critical CSS download → render.
Render-blocking resources (synchronous `<script>`, blocking CSS) push FCP out the most.
Server-side rendering and edge rendering close the gap between TTFB and FCP.
FCP is not a Core Web Vital itself, but it's the canary for what's slowing LCP downstream.

Use Cases

When to use it

Diagnosing whether slow page load is server-side (high TTFB) or client-side (low TTFB, high FCP).
Performance budgeting on landing pages where bounce rates spike with delays.
Identifying render-blocking third-party scripts (analytics, A/B testing) that push FCP out.
Tracking improvements after CDN, SSR, or CSS inlining changes.

Watch out

Common Mistakes

Big render-blocking CSS bundles loaded synchronously, defer non-critical CSS or inline the critical path.
Synchronous third-party tags above the fold; load them async or defer them.
Web fonts blocking text rendering for seconds; use `font-display: swap` with a fast fallback.
Server-rendered pages with high TTFB; even a perfect frontend can't compensate.

FAQ