First Contentful Paint (FCP)

FCP measures how quickly the first piece of content appears on the screen— text, an image, or a canvas element. It is one of the clearest signals of how "fast" your site feels to real users.

By keeping FCP low, you reduce the perceived loading time and prevent users from abandoning the page before it even starts to render.

Optimize Your FCP Test Your Site

FCP Benchmarks

Good < ~1.8s
Needs improvement ~1.8s – 3.0s
Poor > 3.0s

These ranges are rough practical targets. The lower your FCP on real user devices, the better the perceived performance.

What exactly does FCP measure?

First Contentful Paint is the moment when the browser renders the first bit of DOM content from your page. This could be a heading, logo, hero image, or even a simple loading message.

FCP does not guarantee that the page is usable yet, but it tells you when the page stops being blank and starts giving feedback to the user that something is happening.

  • 1 Your HTML, CSS, and critical JavaScript are downloaded and parsed.
  • 2 The browser can finally paint the first visible element to the screen.
  • 3 The user sees something — and is less likely to think the site is broken.

Example loading sequence

// Simplified loading timeline
HTML download        ───────────────┐
Critical CSS         ──────────┐    │
Fonts                 ─────┐   │    │
Non-critical JS          ───────────┐
First Contentful Paint          ★   │
User can see the UI                │
Full interactivity             (later)

FCP happens as soon as there is something visible, even if scripts are still loading.

How to improve FCP on your site

The biggest gains usually come from reducing the amount of work the browser must do before it can paint something useful.

Prioritize critical CSS

Inline the minimal CSS required for above-the-fold content and defer the rest. This lets the browser render basic layout before all styles are downloaded.

  • Remove unused CSS
  • Split critical / non-critical styles
  • Avoid large blocking CSS frameworks

Eliminate render-blocking JS

Defer or lazy-load scripts that are not required for the initial view. Heavy third-party scripts are a common reason for slow FCP.

  • Use <script defer>
  • Load analytics after main content
  • Audit tag managers regularly

Use fast hosting & CDN

A slow server increases the time before the browser can even start downloading assets. Use a modern stack with caching and a CDN close to your users.

  • Enable full-page caching
  • Serve static assets from a CDN
  • Use HTTP/2 or HTTP/3 where possible

Where to see your FCP score

Combine lab data (synthetic tests) with real-user monitoring to get a complete picture.

PageSpeed Insights

Enter any URL and view FCP for both mobile and desktop, plus optimization suggestions based on Lighthouse.

GTmetrix & WebPageTest

Run detailed synthetic tests with waterfalls and video playback to see exactly when content appears for users.

Field data (RUM)

Use real-user monitoring tools or the Chrome User Experience report to see how FCP behaves for actual visitors on different devices and networks.

Common causes of slow FCP

FCP improves when the browser can render something useful quickly. These are the most common blockers to address first.

Render‑blocking CSS

Large CSS files (or too many) can delay the first paint. Prioritize critical CSS and defer the rest.

  • • Remove unused CSS
  • • Split critical vs non‑critical styles
  • • Avoid loading multiple heavy frameworks

Blocking JavaScript

Scripts in the critical path can prevent the browser from painting quickly. Defer non‑essential scripts.

  • • Use defer when possible
  • • Delay third‑party widgets
  • • Audit tag managers regularly

Slow server response

If the first byte arrives late, the browser can’t paint early. Improve TTFB with caching and better hosting.

  • • Enable page caching
  • • Use a CDN for assets
  • • Reduce backend work per request
TTFB guide →

FCP quick checklist

Use this list to plan small, safe changes. Each item is easy to verify with a re-test.

Rendering

  • • Inline or prioritize critical CSS for above‑the‑fold content
  • • Defer non-critical JavaScript and third-party scripts
  • • Avoid loading large fonts late (use sensible font strategies)

Delivery

  • • Enable caching for HTML where possible
  • • Serve static assets from a CDN
  • • Compress images and avoid oversized assets above the fold
Speed Test LCP guide Best Tools

FAQ: improving FCP

Short answers to common questions about diagnosing and improving First Contentful Paint.

Is FCP the same as LCP?

No. FCP is the first visible content, while LCP is the largest visible element. Both are useful—FCP for “blank screen” issues, LCP for main content speed.

What usually slows FCP the most?

Render-blocking CSS/JS and slow server response are common culprits. Fixing these often improves multiple metrics, not just FCP.

Can a tool fix FCP automatically?

Tools can help by deferring scripts and improving caching, but you should still verify the results and avoid breaking critical UI.

Should I optimize fonts for FCP?

Fonts can affect perceived rendering. Keep the approach simple: avoid unnecessary font files and verify that text appears quickly.

How do I confirm improvements?

Re-test the same URL, compare multiple runs, and if possible verify with real-user data. Start with the Speed Test.

What’s the safest first fix?

Optimize your largest above-the-fold image and remove obvious blocking scripts. These changes are usually easy to verify and low-risk.

Ready to fix FCP on your site?

Start by measuring your current scores, apply a few targeted fixes, and then re-test. Small, focused changes often lead to dramatic improvements.

Run a speed test Back to Core Web Vitals