What Is First Contentful Paint (FCP)? Complete Guide (2026)
Hi, I'm Saar - a software engineer, SEO specialist, and lecturer who loves building tools and teaching tech.
View author profile →What Is First Contentful Paint?
First Contentful Paint (FCP) measures the moment anypiece of DOM content — text, an image, an SVG, or a non-blank canvas — first renders to the screen after a navigation begins. It's the metric that answers the user's subconscious question "is this page actually loading, or did I click a broken link?"
Key Facts (TL;DR)
- Good FCP: ≤ 1.8 seconds — Google's threshold for fast first paint.
- Needs Improvement: 1.8 – 3.0 seconds — visitors begin to perceive the page as slow.
- Poor: > 3.0 seconds — Google research shows 53% of mobile users abandon a page that takes longer than 3 seconds to start showing content.
- Performance score weight: FCP contributes approximately 10% of your overall web performance score.
- Not a Core Web Vital: FCP is a Web Vital but not one of the three Core Web Vitals (LCP, INP, CLS). It is, however, a strong leading indicator — a slow FCP almost always means a slow LCP.
- Business impact: Mobify reported a 1.11% lift in session-based conversion for every 100 ms of homepage speed improvement (BigCommerce/Mobify case study).
Think of FCP as the moment a waiter sets a glass of water on the table. The meal hasn't arrived yet (that's LCP), but the visitor knows they've been seen. Without that signal, many leave.
Why FCP Matters for Engagement and Rankings
- Bounce rate: Google's research shows the probability of a mobile bounce increases 32% as page load goes from 1s to 3s, and 90% by 5s. FCP is the moment that timer mentally stops for the user.
- Page Experience signal:While FCP itself isn't a Core Web Vital, it correlates strongly with LCP — and LCP is part of Google's ranking algorithm. Optimizing FCP usually pulls LCP along with it.
- Performance score: FCP carries ~10% of the weight in standard performance audits. Combined with LCP (25%), Speed Index (10%), TBT (30%), and CLS (25%), you get the full performance picture.
- AI search visibility: Generative search engines preferentially cite pages that already rank well. Slow FCP drags down rankings, which drags down AI citation odds.
- Conversion correlation: Cross-industry data consistently shows a few hundred milliseconds of FCP improvement translates to 1–7% conversion lift.
FCP vs LCP vs TTFB — How They Relate
FCP sits between two other timing metrics on the page-load timeline. Understanding the order helps you diagnose which one to fix.
| Metric | What It Measures | Good Threshold | Order on Timeline |
|---|---|---|---|
| Time to First Byte (TTFB) | Server response time — first byte of HTML reaches the browser | ≤ 800 ms | 1st |
| First Contentful Paint (FCP) | First DOM content renders to screen | ≤ 1.8 s | 2nd |
| Largest Contentful Paint (LCP) | Largest visible element finishes rendering | ≤ 2.5 s | 3rd |
Diagnostic shortcut: If TTFB is high, fix the server first — nothing downstream can be fast until the browser receives HTML. If TTFB is fine but FCP is slow, the issue is render-blocking CSS/JS. If FCP is fine but LCP is slow, the issue is the hero image or main content asset.
How to Check Your FCP Score
- Greadme's deep scan — surfaces FCP alongside every other Web Vital and pairs each issue with an AI-generated fix or one-click GitHub PR. Recommended starting point.
- Greadme's crawler scan — measures FCP across every indexable page so you can identify which templates are slowest to start rendering.
- Google Search Console → Core Web Vitals report — uses real-user data (CrUX) to flag slow URLs across mobile and desktop.
- Browser developer tools → Performance tab — record a load locally; the "Timings" lane shows the FCP marker.
8 Proven Ways to Improve FCP
1. Cut Time to First Byte (TTFB)
FCP cannot start until the browser receives HTML. If your TTFB is over 800 ms, no amount of front-end optimization will save your FCP.
Fix: Enable server-side caching, move dynamic rendering to the edge, upgrade slow database queries, or switch to faster hosting. For static content, a CDN with edge caching can drop TTFB to under 100 ms.
2. Eliminate Render-Blocking Resources
CSS and synchronous JavaScript in the <head> block FCP entirely — the browser will not paint anything until they finish parsing.
Fix: Inline only the critical CSS needed for above-the-fold content; load the rest asynchronously. Add defer or async to non-critical script tags. Audit every blocking <link rel="stylesheet"> and challenge whether it must block.
3. Inline Critical CSS
Extracting the CSS needed for above-the-fold content and inlining it in <head> removes one round-trip from the critical path — a typical savings of 300–800 ms on FCP.
<head>
<style>/* Critical above-the-fold CSS here, ~10–14 KB max */</style>
<link rel="preload" href="/styles/main.css" as="style"
onload="this.onload=null;this.rel='stylesheet'">
</head>4. Preconnect and DNS-Prefetch Critical Origins
If your fonts, CSS, or hero image are served from a different origin (a CDN, a font host), the browser pays a TLS handshake cost before it can fetch them.
Fix: Add <link rel="preconnect" href="..."> for each critical origin in <head>, ideally as the first lines after <meta charset>.
5. Use a CDN with Edge Caching
Serving HTML and static assets from an edge node geographically close to each user is one of the highest-leverage FCP optimizations available — typically 30–50% improvement for distant users.
6. Compress and Cache HTML
Brotli or gzip compression on HTML responses can shrink the payload by 70–80%. Combined with proper Cache-Control headers, repeat visitors can hit a fully primed cache and get sub-100 ms FCP.
7. Avoid Long-Running Inline Scripts in <head>
Even an inline script that runs "quickly" blocks parsing. A 200 ms inline analytics snippet in the head is 200 ms added directly to FCP.
Fix: Move inline scripts to the end of <body> or load them with defer. For critical telemetry, use a tiny stub that buffers events and flushes after FCP.
8. Eliminate Long-Running Font Blocking
Web fonts loaded with the default font-display: auto can hide text for up to 3 seconds while the font downloads — delaying FCP for any text that uses the font.
Fix: Set font-display: swap in your @font-face rules so text paints immediately in a fallback font. Pair with size-adjust overrides to minimize the visual swap.
Common FCP Problems and Fixes
Problem: TTFB Is Over 1 Second
What's happening: The server is slow to generate HTML — usually because of uncached database queries, slow third-party APIs in the render path, or under-provisioned hosting.
Fix: Cache rendered HTML at the edge. For dynamic apps, cache page fragments and database queries aggressively. Anything in the request path that takes > 100 ms should be cached.
Problem: Multiple Blocking Stylesheets
What's happening: The page loads several large CSS files in <head>, each adding a round-trip before paint can begin.
Fix: Consolidate into one critical inline stylesheet plus an async-loaded main stylesheet. Remove unused CSS — most sites ship 60–80% CSS that never applies to the page being viewed.
Problem: Mobile FCP Much Worse Than Desktop
What's happening: The mobile network round-trip and CPU processing penalize render-blocking resources far more than desktop.
Fix: Focus on cutting bytes (smaller CSS, smaller HTML) and reducing the number of blocking requests. Mobile is where every saved round-trip pays off most.
Problem: FCP Is Fine on First Load, Bad on Repeat Visits
What's happening: Caching is misconfigured — assets are being re-fetched instead of served from the browser cache.
Fix: Set long Cache-Control headers (1 year + content hashing) on static assets. Use a service worker for offline-first caching of HTML where it makes sense.
FAQ
What is a good FCP score?
Google defines a good FCP as 1.8 seconds or lessat the 75th percentile of real-user page loads. Anywhere between 1.8s and 3.0s "needs improvement," and over 3.0s is poor — the threshold at which mobile abandonment rates climb sharply.
Is FCP a Core Web Vital?
No. The three Core Web Vitals are LCP (loading), INP (interactivity), and CLS (visual stability). FCP is classified as a "Web Vital" but is not part of the Core Web Vitals trio that Google uses as a direct ranking signal. It is, however, a strong leading indicator — when FCP is slow, LCP almost always is too.
What's the difference between FCP and LCP?
FCP marks when the first piece of any visible content paints — even a tiny logo or a header bar. LCP marks when the largestvisible content element finishes painting. FCP says "the page is alive," LCP says "the main content is here." A page can have a fast FCP and a slow LCP if a small element appears quickly but the hero image takes 4 seconds.
How is FCP measured — lab or field?
Both. Lab tools measure FCP under simulated network conditions; field measurement uses the Chrome User Experience Report (CrUX) to capture real-user FCP across actual devices and connections. Google uses field data for ranking-relevant decisions; lab data is faster for diagnosing fixes during development.
Why is render-blocking CSS the biggest cause of slow FCP?
Browsers will not paint any content until they have built the CSSOM (CSS Object Model) for the page. Every <link rel="stylesheet"> in the head adds a network round-trip before the browser is allowed to paint. Inlining critical CSS short-circuits this chain.
Does FCP affect AI search engines like ChatGPT and Perplexity?
Indirectly. AI-driven search systems preferentially cite pages that already rank well in traditional search, and slow FCP correlates with slow LCP, which is a confirmed Google ranking signal. Additionally, slow pages are crawled less frequently by AI bots, which can reduce how current your content appears in generative results.
Can a fast FCP make up for a slow LCP?
Partially. A fast FCP keeps users engaged long enough for the LCP element to arrive — but if LCP is over 4 seconds, even a sub-second FCP won't prevent abandonment. Treat FCP and LCP as a sequence: optimize FCP to keep users on the page, then optimize LCP to deliver the value they came for.
Conclusion
FCP is the moment your page goes from "blank tab" to "something's loading" in the user's mind. Hit the ≤ 1.8 second threshold by attacking three things in order: cut TTFB with caching and a CDN, eliminate render-blocking CSS by inlining the critical subset, and defer everything that doesn't need to run before paint.
FCP also tends to predict the rest of your performance profile — fix it and LCP, Speed Index, and TBT usually improve with the same changes. Run a Greadme deep scan to see your FCP, identify which resources are blocking it, and get a prioritized fix list.