Fixing Slow First Contentful Paint (FCP)

What counts as the first contentful paint

The browser records FCP the first time it draws any content from the page's DOM. Text counts, as long as it is actually visible. So do images, including CSS background images, SVG elements and canvas elements that have been drawn on. A plain background colour does not count, and neither does text that the browser is holding back while a web font downloads.

Google's guidance rates FCP like this, using the 75th percentile of visits:

FCP appears in the Chrome UX Report and in PageSpeed Insights, but it is a diagnostic measurement. Search Console's Core Web Vitals report is based on LCP, INP and CLS, not FCP. The reason to fix FCP is what it tells you: if nothing at all appears for three seconds, the largest element cannot possibly appear within 2.5, and visitors on slow connections may leave before they see anything.

What must happen before anything is painted

Between the click and the first paint, the browser works through a fixed sequence. Every item on this list adds to FCP, and any one of them can be the slow part:

1. Redirects. Each hop, for example from an advert's tracking link to http, then https, then the www version, is a full round trip before your page is even requested.
2. Connection and server response. DNS lookup, connection set-up, TLS, and then the time your server takes to produce the HTML. Together these make up Time to First Byte.
3. Downloading and parsing the HTML head. The browser reads the head from top to bottom. A very large head, packed with inline scripts, tracking tags and inline SVG sprites, takes longer to arrive and to read.
4. Render-blocking stylesheets. Every <link rel="stylesheet"> that applies to the current screen must be downloaded and parsed before anything is drawn. Stylesheets pulled in with @import are worse, because the browser only finds them after reading the first file.
5. Parser-blocking scripts. A <script src> without defer or async in the head stops the browser reading the HTML until the script has downloaded and run.
6. Something visible to paint. If the body is empty until JavaScript builds it, or is hidden by a style rule, or all its text is waiting for a font, the browser has nothing to show even when it is ready.

A fast site keeps this path short: one quick response, one small stylesheet or inlined critical rules, no blocking scripts, and real text in the HTML.

Finding your blocker

Run the page through the Core Web Vitals checker and note FCP from the field data and the lab run, alongside TTFB. Subtract TTFB from FCP. What remains is time the browser spent after the HTML started arriving, and that is time you can usually win back in the front end.

In Chrome DevTools

1. Open the Network panel, tick Disable cache, and set throttling to a slow 4G profile.
2. Reload and look at the first few requests. Redirects show as 301 or 302 rows before the document. Look for stylesheets and scripts requested from the head, and note which have Highest or High priority.
3. Switch to the Performance panel and record a reload. The FCP marker appears in the Timings track. Everything on the main thread and the network before that marker is a candidate blocker.
4. Open the Coverage tab from the command menu and reload. It shows how much of each CSS and JavaScript file was actually used for the first view. A 300 KB stylesheet with 90% unused code is a strong sign that critical CSS will help.

Lighthouse lists the specific offenders in its render-blocking diagnostics, with an estimate of the time each one costs. Treat the estimates as a guide to priority rather than an exact saving.

A quick test for hidden content

Load the page with JavaScript switched off in DevTools settings. If you get a blank screen, the page relies on scripts to show anything, and FCP can never be earlier than the time those scripts take to download and run. If you see content but it is invisible when JavaScript is on, look for a hiding snippet.

Critical CSS in practice

Critical CSS means the small set of rules needed to draw the first screenful: the header, navigation, hero area and the typography of the opening text. Put those rules inline in the head, then load the full stylesheet without blocking rendering.

<head>
  <style>
    /* critical rules for header, hero and first text block only */
    body{margin:0;font-family:system-ui,sans-serif;color:#1d2433}
    .site-header{display:flex;align-items:center;height:64px;padding:0 16px}
    .hero h1{font-size:2rem;line-height:1.2;margin:24px 16px}
  </style>
  <link rel="preload" href="/css/site.css" as="style">
  <link rel="stylesheet" href="/css/site.css" media="print" id="site-css">
  <script>
    const css = document.getElementById('site-css');
    css.addEventListener('load', () => { css.media = 'all'; });
  </script>
  <noscript><link rel="stylesheet" href="/css/site.css"></noscript>
</head>

The media="print" trick makes the browser fetch the stylesheet at low priority without blocking the screen render, and the tiny script switches it on for screens once it has loaded. The noscript fallback keeps the page styled for visitors without JavaScript. Keep the inline block small, ideally a few kilobytes, because inlined CSS cannot be cached between pages.

• Replace any @import inside stylesheets with separate link tags, or combine the files at build time.
• Give stylesheets that only apply to print or to wide screens a matching media attribute so they do not block small screens.
• Serve CSS from your own domain where you can. Each extra host needs its own connection before the file can download.

Scripts, hiding snippets and fonts

Scripts in the head

<!-- blocks parsing and rendering -->
<script src="/js/app.js"></script>

<!-- downloads in parallel, runs after the HTML is parsed, in order -->
<script src="/js/app.js" defer></script>

<!-- downloads in parallel, runs as soon as it arrives, order not kept -->
<script src="https://analytics.example.com/tag.js" async></script>

Use defer for your own scripts that depend on each other, and async for independent third-party tags. Modules loaded with type="module" are deferred by default.

Anti-flicker and page-hiding snippets

Some A/B testing and personalisation tools ask you to add a snippet that hides the whole page, often by setting the body's opacity to zero, until the experiment script has loaded, with a timeout of several seconds as a safety net. On a slow connection the visitor stares at a blank screen for the full timeout. If you must keep such a tool, shorten the timeout, hide only the element being tested rather than the whole page, or run experiments on the server so no hiding is needed.

Web fonts

By default, most browsers hide text for a short period while a web font downloads. If all the visible content is text in that font, nothing counts as painted. Set font-display: swap so fallback text is drawn at once, preload the one or two font files used in the first screen, and self-host fonts so they come from the same connection as the page.

@font-face{
  font-family:"Harbour Sans";
  src:url("/fonts/harbour-sans-600.woff2") format("woff2");
  font-weight:600;
  font-display:swap;
}

Platform notes

• WordPress. Optimisation plugins can generate critical CSS, delay scripts and add font-display for you. Turn features on one at a time and check the result, because combining minification, delay and critical CSS from two plugins at once often breaks layouts. Page builders tend to load large stylesheets on every page; check the Coverage tab.
• Shopify. Apps can add scripts and stylesheets to the theme head. The theme's own CSS is usually well structured, so look first at app embeds and snippets added to theme.liquid.
• Single-page apps. A React, Vue or Angular app that renders only in the browser sends an empty body, so FCP waits for the whole bundle. Server-side rendering or static pre-rendering is the real fix; a lightweight HTML loading state is a stopgap.
• Static sites. You have full control. Inline critical CSS at build time, defer everything else, and serve from a CDN so TTFB stays low.

The fix, step by step

Keeping the first paint fast

• Set a head budget. Agree a limit on how many blocking files the head may contain, for example one stylesheet and no synchronous scripts, and check new templates against it.
• Review every new tag. Marketing, chat and testing tools are the most common way blocking scripts creep back. Ask whether each one can load with async, after consent, or after the first interaction.
• Regenerate critical CSS. When a template's header or hero design changes, regenerate its critical rules as part of the build rather than leaving stale ones in place.
• Watch FCP alongside LCP. In your real-user monitoring, record FCP and TTFB as well as the Core Web Vitals, so you can see immediately whether a regression is in the server, the head or the hero.

For deeper coverage of the files themselves, see the render-blocking resources guide, and for the server side, the Time to First Byte guide.