Professor Sloth

Feature Release

Announcing Unified Web Performance: automatic lab testing, real user monitoring, and Google SEO scores.

You ran Lighthouse and got flagged for a slow First Contentful Paint. The score is orange (or worse, red), and the help text says something about “the time at which the first text or image is painted.”

But what does that actually mean for your users? And why should you care?

What Lighthouse Is Telling You

First Contentful Paint (FCP) measures the time from when a user starts navigating to your page until the browser renders the first piece of actual content. That content could be text, an image, an SVG, or even a non-white canvas element.

Lighthouse is checking: “How long did users stare at a blank screen before seeing something?”

Google considers FCP scores under 1.8 seconds good. Anything between 1.8 and 3.0 seconds needs improvement. Over 3.0 seconds is poor, and your users are probably already reaching for the back button.


Good:         0 - 1.8 seconds
Needs Work:   1.8 - 3.0 seconds
Poor:         > 3.0 seconds

Why It Matters

FCP is about trust. When users click a link or type your URL, they need confirmation that something is happening. A blank screen feels broken. A fast FCP tells users: “I got your request, content is coming.”

This matters for three reasons:

User perception. Studies show users perceive sites as “fast” when they see content within 1-2 seconds, even if the page isn’t fully loaded yet. FCP is that first reassurance.

Bounce rates. Every extra second of blank screen increases the chance users will bail. They don’t know if your server is slow, their connection dropped, or your site is just dead.

SEO rankings. Google includes FCP in its Core Web Vitals assessment. Poor FCP scores can hurt your search rankings, especially on mobile where Google prioritizes page experience signals.

The good news? Everything you do to improve FCP also helps your Largest Contentful Paint (LCP) score. Two birds, one optimization.

How to Fix It

FCP includes all the time spent waiting for your server to respond, downloading HTML and CSS, and processing render-blocking resources. To speed it up, you need to attack each of these.

Speed up your server. Your server needs to respond fast. If you’re running WordPress, use a caching plugin. If you’re making database calls for every request, cache those results. The goal is to get bytes flowing back to the browser as quickly as possible.

Reduce render-blocking resources. The browser can’t paint anything until it has downloaded and parsed your CSS. Inline your critical CSS, defer non-essential stylesheets, and eliminate any synchronous JavaScript in the <head> that isn’t absolutely necessary.

Use compression. Enable gzip or brotli compression on your server. Smaller files download faster. This is table stakes in 2025.

Leverage a CDN. Serve your content from servers physically closer to your users. A CDN can shave hundreds of milliseconds off FCP by reducing network round-trip time.

Optimize your fonts. Web fonts are sneaky FCP killers. Use font-display: swap so text renders immediately with a fallback font while your custom font loads. Better yet, use fewer fonts.

For a complete breakdown of optimization tactics, check out our FCP Cheat Sheet.

Common Mistakes

Ignoring Time to First Byte (TTFB). FCP can’t be faster than your server response time. If your TTFB is 2 seconds, your FCP will be at least 2 seconds. Fix the server first.

Loading too much CSS. Every kilobyte of CSS delays FCP. That 500KB framework you imported for a few utility classes? It’s costing you. Audit your CSS and remove what you don’t need.

Chaining CSS imports. Using @import statements inside CSS files creates a waterfall of requests. The browser can’t start downloading the imported stylesheet until it finishes downloading the first one. Avoid @import and link stylesheets directly in your HTML.

Forgetting about mobile. Lighthouse simulates slower connections and devices. Your FCP might be great on your developer machine and terrible for real users on 3G. Test with throttling enabled.

Focusing only on Lighthouse. Here’s the thing: Lighthouse runs a synthetic test with simulated conditions. Your real users might have completely different experiences. A good Lighthouse score doesn’t guarantee good real-world performance. Learn more about Lighthouse’s limitations.

Keep Improving

FCP is one piece of the performance puzzle. Once you’ve optimized it, you’ll want to look at LCP (when the main content loads), CLS (how much the page jumps around), and INP (how responsive it is to interaction).

For a deeper dive into what FCP measures and how to track it with code, read our guide on Using First Contentful Paint.

The best way to know if your optimizations actually help real users is to set up Real User Monitoring. Lighthouse tells you what might be slow. RUM tells you what is slow for your actual audience.