What is First Contentful Paint (FCP), and why does it matter?

What is First Contentful Paint?

First Contentful Paint is a performance metric that tracks how long it takes the browser to render the first piece of document object model (DOM) content after a user navigates to a page. W3C specifications note that measuring page performance often involves measuring the time required to render text or images to the screen. First Contentful Paint marks the specific moment when that initial content becomes visible to the user.

According to web.dev and Chrome for Developers, content eligible for this metric includes text, raster images, background images, SVG elements, and non-white canvas elements. Anything rendered inside an iframe is explicitly excluded from DOM content calculations. MDN Web Docs notes that capturing the timing of these paint operations helps document how quickly a page delivers visible feedback.

How does FCP differ from First Paint and LCP?

First Contentful Paint differs from both First Paint (FP) and Largest Contentful Paint (LCP) in how content rendering is defined. W3C standards state that First Paint marks the very first time the browser renders anything for a document, such as a background color change. By contrast, FCP requires the browser to render actual image or text content from the DOM.

While FCP captures the very beginning of the loading experience by measuring when any content is painted, LCP measures when the main content is rendered. Because LCP is designed to be more selective, web.dev explains that FCP heuristics may consider elements like placeholder images or full viewport images even if they are ineligible to be LCP candidates. This difference in measurement heuristics can occasionally lead to situations where web APIs report LCP as occurring earlier than FCP.

Why does FCP matter for performance scores?

Chrome for Developers documents that FCP is one of six metrics tracked in the Performance section of a Lighthouse report. Lighthouse gathers raw performance metrics in milliseconds and converts each raw value into a metric score from 0 to 100 based on a log-normal distribution. This scoring distribution is derived from real website performance data stored in the HTTP Archive, and the final Performance score is calculated as a weighted average of these individual metric scores.

Your page's FCP score reflects a direct comparison between your measured FCP time and real website performance data across the web. MDN Web Docs highlights that decreasing the time until key paint moments occur makes websites feel significantly more engaging and responsive. To deliver a good user experience, web.dev and Chrome for Developers recommend achieving an FCP of 1.8 seconds or less and aiming for an overall Lighthouse performance score between 90 and 100.

How is FCP measured in web APIs and lab tools?

MDN Web Docs explains that browser performance APIs expose timing details through the PerformancePaintTiming interface. W3C specifications define two primary attributes within this timing interface: paintTime, which represents the timestamp at the end of the rendering loop update, and presentationTime, which represents an implementation-specific timestamp marked when the frame is presented to the user.

Field measurements of FCP capture real-world network and navigation delays that lab tools might not reflect. web.dev notes that field FCP includes unload time from the previous page, connection setup time, redirect time, and Time To First Byte (TTFB). Font load time is also particularly important for FCP performance, as delayed fonts block text rendering.

When gathering API measurements, specific page conditions must be accounted for. Performance APIs dispatch entries for pages loaded in background tabs, but guidelines specify those entries should be ignored when calculating FCP. Conversely, APIs do not report entries when a page is restored from the back or forward cache, but FCP should still be measured in those cases because users experience them as distinct page visits.

How do you diagnose and troubleshoot FCP issues?

Diagnosing slow FCP requires reviewing network setup factors, DOM element eligibility, font delivery paths, and measurement conditions in browser APIs.

1. 01Analyze server and connection metrics including Time To First Byte, redirect chains, and connection setup times to identify initial network bottlenecks.
2. 02Audit custom font loading performance and styling rules to ensure render-blocking fonts do not delay the initial text paint timestamp.
3. 03Inspect early page elements to ensure that initial visible content comes directly from the document DOM rather than inside an iframe.
4. 04Filter performance monitoring data to exclude entries from pages loaded in background tabs while ensuring page restores from the back or forward cache are tracked.

Common questions