Timestamp when the browser renders the first piece of content on a web page.
Web developers and performance auditors reading about website optimization and user experience metrics.
01What it is and how it works
FCP is a Core Web Vital that captures the time from navigation start to the moment the browser paints any visible DOM node. The measurement includes text nodes, images, SVGs, and canvas elements that become part of the layout. It does not include resources that do not affect the visual rendering, such as hidden elements or loading spinners. Modern browsers expose FCP via the PerformanceObserver interface, allowing JavaScript libraries to record and report the metric in real time.
FCP tells you the moment the page shows something you can see. It is the first visual clue that the page is loading.
02What to do about it
To improve FCP you can: inline critical CSS so the above‑the‑fold content renders without waiting for external stylesheets; use responsive images with appropriate sizes and picture elements; lazy‑load offscreen images to reduce initial resource load; reduce server response time by optimizing backend queries and using a CDN; minify and defer non‑critical JavaScript; and cache static assets aggressively. These actions typically shave hundreds of milliseconds off the first paint.
03How it is measured or noticed
You can see FCP in several tools: the Performance panel in Chrome DevTools (look under the Timeline), Lighthouse audits (available via the Audits tab), and PageSpeed Insights which reports the metric in its Core Web Vitals section. The Web Vitals JavaScript library can be added to a page to capture FCP programmatically. For field data, Chrome User Experience Report (CrUX) aggregates FCP for real users and is accessible via Google Search Central.
04Common mistakes
- Ignoring render‑blocking CSS/JS that delay the first paint.
- Placing large hero images before the fold without optimization.
- Not caching static resources, causing repeated downloads.
- Measuring FCP on pages that load content via AJAX after initial render.
- Focusing on average FCP while ignoring the 75th percentile user experience.
05Limits
FCP does not apply to single‑page applications that load content dynamically after the initial page load; the metric will reflect only the first static paint. It also does not capture later visual changes, so a page that updates a chart after 2 seconds will still have an early FCP. Confusing FCP with Largest Contentful Paint (LCP) is a common error; LCP measures the largest visible element, while FCP measures the very first visible element.
06Worked example
"If a page loads a 200 KB hero image after 800 ms, the FCP is 800 ms. Any text that appears earlier would set the FCP to that earlier timestamp."
Frequently asked questions
How is First Contentful Paint different from Largest Contentful Paint?
FCP marks the moment any visible content first appears on screen, while LCP waits for the largest single element to render. FCP is about how quickly users see something; LCP is about how quickly the main content finishes loading. Both are Core Web Vitals but they answer different questions about perceived speed.
What counts as the "first content" for FCP?
Any visible DOM element painted by the browser qualifies: text, images, non‑blank <canvas> elements, or even SVGs. Background colors and changes to an already‑painted element do not count. The browser simply records the timestamp of the first qualifying paint after navigation begins.
Should I optimize FCP even if my LCP is already good?
Usually yes, because FCP and LCP reflect different stages of the loading experience. A fast LCP can still feel slow if users stare at a blank screen waiting for the very first byte of content. Improving FCP reassures users that the page is actually working, which reduces bounce rates on slow connections.
What is a good FCP score to aim for?
Google classifies an FCP of 1.8 seconds or less as good, between 1.8 and 3.0 seconds as needing improvement, and over 3.0 seconds as poor. These thresholds come from real‑user performance data collected via the Chrome User Experience Report.
Can I measure FCP without deploying RUM (Real User Monitoring)?
Yes. Lab tools like Lighthouse and the Chrome DevTools Performance panel report FCP for a single simulated load. For real users, you need the Web Vitals JavaScript library or a RUM provider that reads the paint-timing entries and reports them back to your analytics endpoint.
Asked out loud
spoken, not typedThe same term in the words somebody uses speaking to an assistant rather than typing into a box — written from the situation, which is why each one carries the situation it came from.
Lighthouse runs a single simulated load on a fast machine, so it can miss what real visitors on slow networks experience. Open Chrome DevTools and throttle the network to Slow 4G while recording a Performance trace, and watch when the first text or image actually appears. That timestamp is your FCP, and if it is past about 1.8 seconds your visitors are staring at a blank screen even though the lab score looks green.
First Contentful Paint is usually blocked by render‑path work, not by the HTML itself: the server has to send a response that the browser can start painting immediately, the critical CSS has to be inlined, and web fonts have to be set up so they don't hide the text. Ship the above‑the‑fold CSS inline, preload the font files, and serve images in modern formats with explicit width and height, and you will see the FCP drop on the next test run.
Yes, FCP is still a Core Web Vital and still appears in Search Console and CrUX, so ignoring it would mean losing a signal you can act on. INP replaced FID, not FCP, and the two metrics measure different things: FCP is loading speed, INP is interactivity after the page is up. You need both because a page can render quickly and still feel sluggish to click, or feel snappy to click but leave users staring at a blank screen for two seconds.