Your page takes longer than 1.8 seconds to paint its first pixel of real content, and the fix is almost always the same: get HTML to the browser faster and stop render-blocking CSS and JavaScript from standing in the way.
What this check flags
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: text, an image, an SVG, or a non-white canvas element. It is the "is anything happening?" moment. Before FCP fires, your visitor is staring at a blank screen wondering whether the link is broken, their connection died, or your site simply does not care. FCP is one of the supporting Web Vitals, not a Core Web Vital itself.
The thresholds, per Google's web.dev guidance, are straightforward: 1.8 seconds or less is good, anything over 3.0 seconds is poor, and the zone in between needs improvement. Google evaluates this at the 75th percentile of page loads, split across mobile and desktop. This audit fired because your page crossed the 1.8 second line. And honestly, three seconds of blank white screen is a hell of a long time in user perception. People bail.
FCP vs LCP: first paint vs main content
These two get confused constantly. FCP marks the first render of any content at all. Largest Contentful Paint (LCP) marks when the largest text block or image in the viewport has rendered, which is Google's proxy for "the main content is here." FCP says the page started; LCP says the page arrived.
By definition, FCP always happens at or before LCP. That makes FCP the floor under your LCP score: every millisecond of FCP delay is baked directly into LCP. Fix FCP and LCP usually follows, because the bottlenecks overlap heavily, slow servers, render-blocking resources, bloated CSS. Once FCP is healthy, anything still wrong with LCP is specific to the hero element itself, which is covered in our LCP complete guide.
Read the waterfall: symptom to cause to fix
Nearly every FCP diagnosis comes down to two numbers, Time to First Byte and the gap between it and first paint. This table maps what you see to what's wrong:
| What the waterfall shows | Likely cause | The fix |
|---|---|---|
| TTFB alone is over ~800ms | Slow server, no page cache, missing CDN | Full-page caching, CDN, faster hosting |
| TTFB fine, long gap before FCP | Render-blocking CSS / JS in the head | Defer scripts, inline critical CSS |
| Large CSS download before paint | Bloated theme / page-builder stylesheet | Trim unused CSS, split per template |
| Many small requests to other origins | Synchronous third-party scripts | Async/defer them, self-host fonts |
| Text assets far larger than expected | No gzip / Brotli compression | Enable text compression at the server |
The usual suspects
Slow Time to First Byte
The browser cannot paint what it has not received. If your server takes a second to even start responding, FCP inherits that delay before a single byte of HTML arrives. Slow hosting, no page caching, sluggish database queries, and missing CDN coverage all live here.
Render-blocking CSS and JavaScript in the head
Every stylesheet and every synchronous script in your <head> must be downloaded, parsed, and executed before the browser paints anything. A large gap between TTFB and FCP usually means the browser is choking on a pile of these. See our check on eliminating render-blocking resources for the full breakdown.
Huge CSS bundles
Shipping 300 KB of CSS when the visible viewport needs 15 KB means the browser waits on the whole bundle before painting. Theme frameworks and page builders are notorious for this.
Synchronous third-party scripts
Tag managers, chat widgets, A/B testing snippets, fonts loaded from a third-party origin: each synchronous one adds a DNS lookup, a connection, and a download to your critical path, on a server you do not control.
No text compression
HTML, CSS, and JS without gzip or Brotli compression are several times larger over the wire than they need to be. This one is pure negligence, it costs nothing to enable.
Quick wins, in priority order
1. Fix TTFB first. Enable full-page caching, use a CDN, upgrade hosting if your server is the bottleneck. Nothing downstream matters until HTML arrives quickly.
2. Enable Brotli or gzip compression for all text assets. On Apache or LiteSpeed this is a few lines of config.
3. Defer non-critical JavaScript. Move scripts out of the critical path:
<script src="analytics.js" defer></script>
<script src="chat-widget.js" async></script>4. Inline critical CSS and load the rest asynchronously. Put the styles needed for above-the-fold content in a <style> block, then load the full stylesheet without blocking:
<link rel="preload" href="main.css" as="style"
onload="this.onload=null;this.rel='stylesheet'">5. Fix font loading. Host fonts locally and use font-display: swap so text renders immediately in a fallback font instead of staying invisible.
6. Trim unused CSS and split per-template if your bundle is bloated.
How to detect it
- PageSpeed Insights. Read both panels: the field data (CrUX) tells you what real users experience; the Lighthouse lab run tells you why. The "Eliminate render-blocking resources" audit names the exact files sitting in your path.
- CrUX. Pull the Chrome UX Report to see your 75th-percentile FCP for real Chrome users, segmented by phone and desktop, the number Google actually grades.
- Chrome DevTools. The Performance panel shows the FCP marker on the timeline; the Network panel (sorted by waterfall) shows precisely which requests sit between navigation and first paint. If TTFB is already slow, it is the server; if TTFB is fine but FCP lags, it is render-blocking resources.
- The web-vitals library. Google's
web-vitalsJS library exposes anonFCP()callback so you can log first paint from real visitors and watch it move after a deploy. - Search Console. While the Core Web Vitals report focuses on LCP, INP, and CLS, a bad FCP almost always drags LCP into the failing bucket there, use it to find which templates are affected.
How to fix it
Follow the symptom-to-fix table top to bottom: get TTFB under control first (cache plus CDN), enable compression, then unblock the render path by deferring non-critical JS and inlining critical CSS. Fix font loading last. Re-measure in the lab immediately, then let the field data catch up over the next month.
Common mistakes
Optimizing images to fix FCP. Images rarely block first paint; that work helps LCP, not FCP. Deferring everything blindly. Defer a script your above-the-fold layout depends on and you trade a slow paint for a broken one. Chasing lab scores only. Lighthouse on your fiber connection is not your user on a mid-range phone; trust field data. Stacking five optimization plugins. They fight each other and often add their own render-blocking payloads.
FAQ
Is FCP a Core Web Vital?
No. The Core Web Vitals are LCP, INP, and CLS. But FCP is an official supporting metric, and because it is the floor under LCP, a bad FCP almost guarantees a bad LCP.
Can FCP and LCP be the same value?
Yes. On simple pages the first thing painted is also the largest thing, so both metrics fire on the same render. That is usually a good sign.
My FCP is fine on desktop but fails on mobile. Why?
Slower CPUs and slower networks amplify every byte of render-blocking CSS and JS. Google segments thresholds by device, so optimize for mobile first and desktop takes care of itself.
Does a CDN really move FCP that much?
When your TTFB is the bottleneck, yes. A CDN serves cached HTML from an edge node near the user, cutting the round trip that FCP inherits before the browser can paint anything at all.
Need a full technical audit?
SEO ProCheck runs deep crawls that catch issues like this across your whole site.
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.
Subscribe to our newsletter!
