What is FCP? How to improve First Contentful Paint

What FCP measures

FCP is the time from the start of the page load until the browser draws the first piece of content. Content here means text, an image (a background image counts), an SVG, or a canvas that is not white. Until that moment the visitor sees a blank page, or the page they just left.

FCP counts the first piece, not the main one. A logo in the header can paint at 0.9 seconds while the large photo under it arrives at 3 seconds. Your FCP is then 0.9 seconds and your LCP is 3. That is why the two numbers can tell different stories about the same page. FCP says "something is happening"; LCP says "the main thing is here".

What counts as a good FCP

These marks are for real visits. Google judges a page at the 75th percentile of its visits: the value that three out of four visits meet or beat. A page whose typical visit paints at 1.2 seconds but whose slowest quarter takes 3.5 seconds is rated by that slow quarter.

How Lighthouse scores FCP

In a lab test, Lighthouse measures one load on a simulated device and network, and FCP counts for 10 of the 100 points of the performance score. The score for the metric itself comes from two control points: a time that earns a score of 90, and a time that earns 50.

The mobile numbers are the same as Google's field marks. The desktop numbers are stricter, because desktop machines and networks are faster. The same 1.8 seconds that earns a 90 on mobile earns about a 38 on desktop. When a report shows a good mobile FCP and a poor desktop one, the page did not get slower: the bar moved.

The path from click to first paint

FCP is measured from the moment the visitor starts the navigation, so it contains every step before the first pixel:

1. Redirects. Each redirect is a full extra round trip before the real page is even requested.
2. Connection. The browser looks up the domain name, opens a connection and sets up encryption (TLS).
3. Server response. The wait for the first byte of the HTML, the time to first byte. FCP can never be earlier than this.
4. Download and parse. The browser reads the HTML. A very large page takes longer, and text files that are not compressed make it worse.
5. Blocking files. Stylesheets in the head hold the first paint until they have loaded. Scripts without defer or async stop the parser until they have run. See render-blocking resources.
6. Fonts. If a web font is still downloading, the browser may hold the text back, depending on the font-display setting.

The first three steps are the visitor's wait before the page has a chance to do anything. If TTFB alone takes 1.5 seconds, a good FCP is already out of reach.

What to fix, in order

1. Make the server answer faster. Caching, a CDN and better hosting move the first byte. Check the TTFB in your report before touching anything else, because every later fix starts from it.
2. Remove redirects. Link to the final address. A common chain is http:// to https://, then bare domain to www. Send people to the final version in one step.
3. Connect early to the origins you need. If your page loads fonts or scripts from another domain, a preconnect hint lets the browser open that connection while it is still reading the HTML (example below).
4. Stop CSS from blocking the first paint. Put the styles the first screen needs inline in the head, and load the rest of the stylesheet without blocking. Details in the critical CSS guide.
5. Load scripts without blocking. Add defer to scripts that the first paint does not need.
6. Show text right away. Set font-display: swap on web fonts so the browser paints the text in a fallback font and swaps when the font arrives. The cost is a small layout shift if the two fonts differ in size, which the guide to layout shift explains how to avoid.
7. Compress and trim. Serve HTML, CSS and JavaScript compressed (Brotli or gzip; see text compression), and keep the HTML itself small.

The preconnect hint from step 3 goes in the head, before the stylesheets that use the origin. The crossorigin attribute is needed for fonts, which the browser always fetches in cross-origin mode:

<link rel="preconnect" href="https://fonts.example.com" crossorigin>

FCP, LCP and Speed Index

FCP, LCP and Speed Index all describe the loading experience, from different angles. FCP is the first sign of life. LCP is when the main content is in place. Speed Index summarizes how quickly the whole first screen fills in. A page can pass one and fail another. If FCP is good and LCP is poor, the first paint is fine and something big, usually the main image, is slow. If FCP is over 3 seconds, LCP is at least that slow, because LCP can never come before FCP.

What FCP does not tell you

FCP says nothing about whether the page can be used. A page can paint at 1 second and then freeze for three seconds while scripts run; Total Blocking Time and INP catch that. It also says nothing about whether the page is stable, which is what CLS measures.

Check your own page

Run the free audit and compare the First Contentful Paint value with the Largest Contentful Paint value. If both are slow, look at the server response and the render-blocking requests first. If only LCP is slow, the first paint is fine and the main content is what you need to speed up.

Sources

• First Contentful Paint (FCP) on web.dev: the definition, the marks and how it is measured.
• First Contentful Paint in the Lighthouse documentation: how Lighthouse reports it.
• font-display on MDN: block and swap periods.