You click a link and stare at a blank white screen. One second passes. Two seconds. Then suddenly text appears, an image pops in, and the page starts to feel real. That moment, when the browser renders the first piece of content from the page's document object model, is called First Contentful Paint. It is the first signal your brain receives that something is actually happening.
Google measures this moment as a performance metric, and it feeds into how users perceive your site's speed. A page can have a fast server response and still feel slow if nothing paints for three seconds.
This guide explains what First Contentful Paint measures, what causes slow scores, and the practical fixes that move the needle. You do not need to be a performance engineer to apply most of them.
First Contentful Paint, usually shortened to FCP, marks the timestamp when the browser first renders any content from the DOM. "Content" here means text, images (including background images), SVG elements, or non-white canvas elements. If the browser paints only the background color, that does not count. The moment the first headline, paragraph, or image appears, FCP is recorded.
FCP is measured in seconds: under 1.8 seconds is good, 1.8 to 3.0 needs improvement, and over 3.0 is poor. These thresholds apply to the 75th percentile of real-user experiences, meaning three-quarters of visitors should hit "good" for the metric to pass.
It is worth distinguishing FCP from its close relatives. First Paint fires when the browser renders anything at all, even a background color change, so it is less meaningful. Largest Contentful Paint (LCP) measures when the biggest visible element finishes rendering, usually after FCP.
FCP is not a direct Google ranking factor on its own, but it is part of the page experience signals that influence how Google evaluates your site. More importantly, it correlates strongly with user behavior. Studies consistently show that perceived load time drives bounce rates: when users see content quickly, they wait for the rest. When they see nothing, they leave.
The psychology is simple. A blank screen gives the brain no information, so every additional millisecond feels longer. A screen with a headline and a layout gives the brain something to process, which makes the remaining load time feel shorter. This is why skeleton screens and progressive rendering feel so much faster than blank-then-everything approaches, even when total load time is identical.
For content sites and blogs, FCP is often the metric with the biggest gap between perception and reality. The article text might be ready in the initial HTML, but render-blocking stylesheets, web fonts, and JavaScript can delay its appearance by seconds. Fixing FCP is usually about removing obstacles between the browser and that first paint, not about making the server faster.
Slow FCP almost always comes down to a handful of culprits. Here are the most common, roughly in order of impact.
By default, the browser will not paint anything until it has downloaded and parsed all stylesheets in the document head. A single 200 KB CSS file on a slow connection can delay FCP by a full second or more. JavaScript files without async or defer attributes behave similarly, blocking parsing until they download and execute.
The fix is to separate critical CSS from the rest. Inline the styles needed for above-the-fold content directly in the head, and load the full stylesheet asynchronously. For scripts, add defer to anything that does not need to run before rendering. This one change is often the biggest FCP win available.
Nothing can paint until the browser receives the first bytes of HTML. If your Time to First Byte (TTFB) is over 600 milliseconds, FCP cannot possibly be good. Slow databases, uncached dynamic pages, and distant servers all inflate TTFB.
Enable full-page caching where possible, use a CDN to serve content from near your visitors, and optimize the queries behind your slowest pages. TTFB improvements flow directly into FCP improvements, one for one.
Custom fonts are a classic FCP killer. If your CSS tells the browser to wait for a web font before rendering text, visitors stare at invisible text until the font arrives. This is called Flash of Invisible Text, and it is miserable on slow connections.
Use font-display: swap in your @font-face declarations so the browser renders fallback text immediately and swaps in the custom font when it arrives. Preload your most important font files so the browser discovers them early. Consider whether you really need four weights of the same typeface.
A two-megabyte hero image will delay FCP because the browser prioritizes it. Compress hero images aggressively, serve modern formats like WebP or AVIF with fallbacks, and make sure the image dimensions in the HTML match the displayed size so the browser can lay out the page without waiting.
You need both lab data and field data. Lab data comes from controlled tests and is great for debugging. Field data comes from real users and is what Google actually evaluates.
When debugging, always test the same page before and after each change. FCP can vary between runs, so take two or three measurements and compare medians rather than single runs.
Avoid stuffing every third-party script into the head: tag managers, analytics, heatmaps, and chat widgets each add network requests before first paint. Load them after the page renders, or at least defer them. Likewise, skip massive background videos above the fold unless you have measured their cost; they look impressive on fast office wifi and terrible on real mobile connections.
Finally, do not chase a perfect score at the expense of user experience. An FCP of 1.2 seconds with jarring layout shift is worse than 1.9 seconds of stable, progressive rendering. Optimize FCP alongside the other Core Web Vitals, not in isolation.
Under 1.8 seconds is considered good by Google, measured at the 75th percentile of real user visits. Between 1.8 and 3.0 seconds needs improvement, and anything over 3.0 seconds is poor. Aim for the good range on your most important templates, especially mobile.
Not directly on its own, but it contributes to the page experience signals Google uses in ranking. More importantly, slow FCP increases bounce rates and reduces engagement, which indirectly hurts the user satisfaction signals search engines care about.
Mobile devices have slower CPUs, less memory, and often slower networks than desktops. The same page that paints in 1.2 seconds on a desktop can take 3.5 seconds on a mid-range phone. Always optimize for mobile first, since that is where most users are and where the thresholds are hardest to meet.
Lazy loading below-the-fold images helps FCP indirectly by freeing bandwidth for above-the-fold resources. But never lazy-load the hero image or any above-the-fold content. Doing so delays exactly the resources FCP is waiting for and will make your score worse.
FCP measures when the first content appears, while LCP measures when the largest visible element finishes rendering. FCP always happens first. A page can have good FCP but poor LCP if the hero image or main headline loads late. Optimizing shared bottlenecks like render-blocking CSS usually improves both.
First Contentful Paint is the moment your page stops being a blank screen and starts being a website. Most slow scores come from a short list of fixable problems: render-blocking CSS and JavaScript, slow server responses, and unoptimized fonts. Work through them in order, measure after each change, and watch the perceived speed transform. To see your current score and get specific recommendations, run your URL through Seovaro's free PageSpeed Insights checker and start with whatever it flags first.
