First Contentful Paint (FCP)

TL;DR — First Contentful Paint (FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital.) is the moment a visitor sees the first bit of your page — any text, image, or graphic — instead of a blank white screen. Faster is better; under 1.8 seconds is the “good” mark. It’s a useful speed check, but it is not one of the metrics Google uses for ranking.

What FCP actually is

When someone clicks a link to your page, there’s a short stretch where they’re staring at nothing — a blank screen — while the browser fetches and processes your page. First Contentful Paint is the instant that blank screen turns into something real: a headline, a logo, a photo, anything the visitor can actually see.

That’s the whole idea. FCP answers one simple question: “How long until the user sees the page is alive and doing something?” A page that paints content in half a second feels fast. A page that sits blank for three seconds feels broken — and people leave.

What counts as “content”

FCP fires when the browser draws any of these onto the screen:

• Text (a heading, a paragraph, a nav link)
• Images, including background images
• <svg> graphics
• A non-white <canvas> element

A plain background color by itself does not count — that’s a different, earlier thing called First Paint. FCP only counts when real content shows up.

What’s a good score?

Google’s bands, measured across real visitors:

You’ll see your FCP in tools like PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. and LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. — the same reports that show your Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data..

Does FCP affect my Google rankings?

No — not directly. This is the part most people get wrong. The metrics Google actually uses for ranking are the three Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data.: LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.. FCP isn’t one of them.

But here’s why it’s still worth watching: the things that make FCP slow — a sluggish server, big stylesheets and scripts that block the page from drawing — are often the same things that hurt Largest Contentful Paint (LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good.), which is a ranking signal. So fixing FCP’s root causes frequently helps LCP too — but it’s not a guarantee, since LCP has causes of its own (the size and load priority of its specific largest element). Think of FCP as the smoke alarm: worth checking, but not proof the fire’s out.

The quick fixes

If your FCP is slow, the usual suspects (and what to do):

• Render-blockingRender-blocking resources are CSS and synchronous JavaScript files a browser must download and process before it can paint any visible content. They sit on the critical rendering path and delay First Contentful Paint and Largest Contentful Paint. files. CSS and JavaScript in your page’s <head> can stop the browser from drawing anything until they finish loading. This is the #1 cause.
• A slow server. If your server takes a long time to respond (high Time to First Byte), the browser can’t paint until the bytes arrive.
• Fonts that hide your text. Some font setups leave text invisible for up to three seconds while a web font loads. Switching the rule to font-display: swap shows fallback text immediately.

Want the technical version — the lab-vs-field gap, the FCP/LCP diagnostic chain, and the full fix list? Switch to the Advanced tab.

TL;DR — FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. is the time from navigation start to when any page content (text, image, <svg>, or non-white <canvas>) first renders. It is not a Core Web Vital — it’s a supplementary, lab-and-field diagnostic metric, and a building block of LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. (FCP happens at or before LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good.). Field thresholds (p75): Good ≤ 1.8 s, needs-improvement ≤ 3.0 s, poor > 3.0 s. In LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. 10 it’s 10% of the Performance score. Because FCP’s clock starts at navigation — it includes redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. time, connection setup, and TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. — lab (LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal.) and field (CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.) numbers often diverge. Fix it where it lives: render-blocking CSSRender-blocking resources are CSS and synchronous JavaScript files a browser must download and process before it can paint any visible content. They sit on the critical rendering path and delay First Contentful Paint and Largest Contentful Paint./JS first, then TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good., then fonts.

What FCP measures (precisely)

Google’s definition, from Philip Walton’s web.dev article, is the accuracy spine here: “First Contentful Paint (FCP) measures the time from when the user first navigated to the page to when any part of the page’s content is rendered on the screen.” “Content,” per the same doc, means “text, images (including background images), <svg> elements, or non-white <canvas> elements.”

The word that does all the work is any. FCP doesn’t care what renders — a 40-pixel logo counts the same as a full hero image. It’s the “is anything on screen yet?” signal, which is exactly why it’s an early indicator rather than a completion metric.

One detail that’s easy to miss and changes how you read the number: FCP’s clock starts at navigation, so it bundles in everything that happens before your HTML is even parsed. Google’s own Key Point: “FCP includes any unload time from the previous page, connection set up time, redirect time, and Time To First Byte (TTFB) which can be significant when measured in the field.” A server that takes 1.5 s to respond has already burned most of your 1.8 s budget before the browser has processed a single byte.

FCP is NOT a Core Web Vital

Let me be blunt about this because most pages hedge it: FCP is not a Core Web Vital and is not part of Google’s ranking signals. The Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. are LCP, INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. — and FCP isn’t mentioned anywhere on Google’s Search ranking Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. page.

What FCP is, in Google’s taxonomy, is an “Other Web Vital” — a supplementary metric that’s useful for diagnosis. web.dev puts it this way: “the metrics Time to First Byte (TTFB) and First Contentful Paint (FCP) are both vital aspects of the loading experience, and are both useful in diagnosing issues with LCP (slow server response times or render-blocking resourcesRender-blocking resources are CSS and synchronous JavaScript files a browser must download and process before it can paint any visible content. They sit on the critical rendering path and delay First Contentful Paint and Largest Contentful Paint., respectively).”

So the honest framing for stakeholders is two-sided, and you should state both halves without flinching:

• FCP does not affect rankings directly. Don’t optimize FCP “for SEO.”
• FCP is a great diagnostic for LCP, which does affect rankings. Render-blocking resources show up in FCP first.

FCP vs First Paint (FP)

These get conflated constantly:

• First Paint (FP) fires when the browser paints anything at all — including a bare background color with no actual content.
• FCP fires only when eligible content renders: text, images (including background images), <svg> elements, or non-white <canvas> elements. That’s a specific, spec-defined list — not a loose “any DOM content” rule — and it’s worth keeping precise, since a background image counts even though it isn’t text in the DOM.

So FP ≤ FCP, always. On most pages they’re nearly identical, because painting a background color with no content on top is rare. When there is a meaningful gap, it usually means a cosmetic background painted before any real content did. The Paint Timing API returns both first-paint and first-contentful-paint entries — but FCP is the one worth analyzing; FP rarely tells you anything actionable.

FCP vs LCP

The other pair people merge:

• FCP = when any content paints. Fires early. Could be a tiny logo or a nav link.
• LCP = when the largest element in the viewport renders. Fires at or after FCP.

Google’s wording: FCP measures when any content is painted and LCP when the main content is painted, so LCP is intended to be more selective. Read that as “more selective,” not “certified correct” — neither metric proves the page’s actual main content is complete or useful to the visitor. FCP just confirms something eligible painted; LCP confirms the largest eligible candidate did. A page can have a fast FCP (logo at 0.5 s) and a slow LCP (hero image at 4 s) — that gap is itself a useful diagnostic. And if your FCP is close to your LCP, that’s often a good sign: it means the first thing painted is also the largest one, with no wasted early-paint on chrome that doesn’t matter to the user.

One measurement oddity worth knowing: because of security restrictions on cross-origin image timing, the browser API can in rare cases report LCP earlier than FCP. That’s a measurement artifact, not something that physically happened.

Thresholds — and why lab and field disagree

Field thresholds (CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program., p75): Good ≤ 1.8 s · needs improvement ≤ 3.0 s · poor > 3.0 s. Google’s guidance is to measure at the 75th percentile of page loads, split across mobile and desktop.

But Lighthouse desktop uses different, stricter cutoffs — green is roughly 0–0.9 s, orange 0.9–1.6 s, red over 1.6 s — because the lab runs a clean, throttled Chrome on a simulated device, not real-world conditions. (Those bands, like the score weights below, are Lighthouse-version-specific — this reflects the current audit doc as of this writing.) The Lighthouse FCP score is “a comparison of your page’s FCP time and FCP times for real websites, based on data from the HTTP Archive.”

This is the single most common source of FCP confusion, so internalize it:

The 1.8 s “good” line is the field (CrUX p75) threshold. Lighthouse desktop’s “green” line is ~0.9 s. They are different scales for different jobs.

Field and lab numbers diverge mainly because they sample different populations, not because one is universally “more true.” Lighthouse runs a single clean session on fixed device/network conditions. Field/CrUX aggregates real devices, real networks, cache states, and navigation types — including back/forward-cache restores and prerendered pages, which don’t automatically get a fresh FCP the way a normal navigation does; they need their own lifecycle handling (the web-vitals library does this for you). On most sites the field number does read higher — real users carry redirect chainsA → B → C instead of A → C. Each hop loses link equity and adds latency., previous- page unload time, and cold connections a lab run skips — but that’s a tendency, not a rule. Before reading a lab/field gap as a problem, check you’re comparing like-for-like (same device class, same network conditions). Use field dataPerformance metrics captured from real users, not lab tests. for your real-world number and Lighthouse for diagnosis.

Where FCP sits in the Lighthouse score

In Lighthouse 10 — the current version as of this writing, not a permanent figure — FCP is 10% of the Performance score. The full weighting:

The Performance score is a weighted average of the individual metric scores, and Google notes the weightings change over time as their research evolves — FCP has held at 10% from Lighthouse 8 through 10, but confirm against whatever version you’re running before treating “10%” as timeless. The practical read: a perfect FCP can only move your Lighthouse number so far — and a bad FCP often points at a bad LCP too (they share root causes), though that’s an overlap worth checking, not something the score guarantees.

What causes a slow FCP

In rough priority order:

1. Render-blocking resources — the #1 killer. CSS and synchronous JS in <head> force the browser to wait: it can’t build the CSSOM and render tree, so it can’t paint anything, until those files are downloaded and parsed.
2. High TTFB — FCP can’t fire before bytes arrive. A slow server is the first domino, and it’s inside the FCP measurement.
3. Redirect chains — every redirect is a full round-trip added before the first byte.
4. Webfont loading strategy — font-display: block (or no rule) can leave text invisible for up to ~3 seconds. Even if paint technically fires on a background, the user sees nothing useful.

How to fix it

The full list, but with a priority order the docs don’t give you. These are the common levers, not universal ones — check your own trace or filmstrip first to see which resource or phase is actually delaying your FCP candidate before reaching for fixes (preconnect, preload, a font-display change) that may not apply to your page:

Do these first (biggest wins):

• Eliminate render-blocking CSS and JavaScript. Inline the critical, above-the-fold CSS directly in <head>; load the rest asynchronously; add async/defer to non-critical scripts. Repositioning a <link> tag does not help — the browser won’t paint until all CSS is loaded and parsed regardless of where the tag sits.
• Reduce TTFB (server response time). Caching, a CDN, a faster origin — anything that gets the first byte out sooner directly shaves FCP.
• Fix font loadingFont loading is how a browser fetches, applies, and renders custom web fonts — and specifically what it shows while the font file downloads. Those choices, controlled mainly by the CSS font-display property, directly affect two Core Web Vitals: LCP and CLS.. Use font-display: swap (shows fallback text immediately, swaps in the web font when ready) or font-display: optional (skips the web font if it isn’t already cached). Avoid font-display: block for critical text — it’s the worst for FCP.

Then tidy up the rest:

• Preconnect to required origins with <link rel="preconnect"> — establishing early connections to important third-party origins can save 100–500 ms.
• Preload key requests (<link rel="preload">) for a critical font or the LCP image.
• Minify CSS, remove unused CSS, remove unused JavaScript — smaller files parse and unblock paint faster.
• Avoid multiple redirects, avoid enormous network payloads, serve static assets with an efficient cache policy, avoid an excessive DOM size, and minimize critical request depth. General payload hygiene that all feeds first paint.

The FCP → TTFB → LCP diagnostic chain

This is how I’d actually use FCP, and it’s the framing the docs gesture at but don’t develop. Treat the three loading metrics as one workflow:

1. FCP is high → check for render-blocking resources (CSS/JS in <head>). That’s the most common cause and the fastest win.
2. Also check TTFB — because FCP includes it, a slow server inflates FCP before any render-blocking even enters the picture. web.dev’s guidance: because TTFB precedes both FCP and LCP, your server should respond fast enough that the 75th percentile of users hit a “good” FCP.
3. These same problems often cascade into LCP — the metric that’s actually a ranking signal — because FCP and LCP frequently share root causes. That’s an overlap worth checking, not a guarantee: LCP has factors of its own (the size, priority, and load path of its specific largest element), so fixing FCP’s causes doesn’t promise a fixed LCP. It’s the right first place to look, not the last step.

That’s the value of FCP for an SEO: it’s a cheap, early read on whether the loading path is healthy, before the more selective LCP measurement even completes.

AI summary

A condensed take on the Advanced version:

• FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. = time from navigation start to when any content first renders — text, images (incl. background), <svg>, or non-white <canvas>. It’s the “is anything on screen yet?” signal.
• FCP is NOT a Core Web Vital. The ranking signals are LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.. FCP is a supplementary, lab-and-field diagnostic metric — not a direct ranking factor.
• It’s a building block of LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. (FCP happens at or before LCP), so it often catches the same render-blocking resourcesRender-blocking resources are CSS and synchronous JavaScript files a browser must download and process before it can paint any visible content. They sit on the critical rendering path and delay First Contentful Paint and Largest Contentful Paint. and slow TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. that hurt LCP — which does affect rankings — but fixing FCP’s causes doesn’t guarantee LCP is fixed; LCP has factors of its own.
• Field thresholds (CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. p75): Good ≤ 1.8 s · needs improvement ≤ 3.0 s · poor > 3.0 s.
• Lab ≠ field, and “field is always higher” is a tendency, not a rule. LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. desktop’s ~0.9 s “green” line is stricter than the 1.8 s field threshold because it’s one clean run on fixed conditions; field/CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. aggregates real devices, networks, cache states, and navigation types (including bfcacheThe back/forward cache (bfcache) is a browser feature that freezes a whole page in memory when you navigate away, so pressing Back or Forward can restore it instantly — no reload, no re-render, no network requests — as long as the browser hasn't evicted that frozen page first. It's a browser optimization, not a search ranking factor. restores and prerendered pages). Match populations before reading a gap as a problem — use field for your real-world number, lab for diagnosis.
• FCP vs FP: First Paint fires on any paint (even a background color); FCP needs eligible content (text, images incl. background images, SVG, non-white canvas). FP ≤ FCP always.
• FCP vs LCP: FCP = any eligible content; LCP = largest eligible candidate. Neither proves the page’s real main content is complete or useful — they’re proxies. Fast FCP + slow LCP is a real, common gap.
• LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. 10 (current as of this writing) weight: 10% — TBTTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital. 30%, LCP 25%, CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. 25%, FCP 10%, Speed IndexSpeed Index measures how quickly content is visually displayed during page load — the average time at which visible parts of the page appear, scored in seconds (lower is better). It's a lab-only Lighthouse metric, not a Core Web Vital and not a ranking factor. 10%; weights shift between Lighthouse versions.
• Top fixes, in order: eliminate render-blocking CSS/JS → reduce TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. → fix fonts (font-display: swap/optional) → preconnect/preload → minify/cache/DOM hygiene.

Official documentation

Primary-source documentation on FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. from Google.

web.dev (Google)

• First Contentful Paint (FCP) — Philip Walton’s canonical definition, the “what counts as content” list, the 1.8 s threshold, the Key Point about TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good./redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't., and how to measure FCP with the Paint Timing API and the web-vitals library.
• Web Vitals — where FCP sits: an “Other Web Vital,” supplementary to the Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. (LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.), useful for diagnosing LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good..
• Largest Contentful Paint (LCP) — the FCP-vs-LCP distinction and how the two relate.
• Time to First Byte (TTFB) — why TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. precedes (and is included in) FCP.
• User-centric performance metrics — FCP’s classification as both a lab and a field metric.

LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. / Chrome Developers

• First Contentful Paint audit — the LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. desktop rating bands (green ≤ 0.9 s) and how the FCP score is computed against HTTP Archive data.
• Lighthouse performance scoring — the metric weights, including FCP at 10% of the Performance score in Lighthouse 10.

Google Search Central

• Core Web Vitals & Google Search — the ranking page; lists LCP, INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.. FCP is not on it, which is the point.

Quotes from the source

On-the-record statements from Google’s documentation. Each link is a deep link that jumps to the quoted passage on the source page.

web.dev — the definition

• “First Contentful Paint (FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital.) measures the time from when the user first navigated to the page to when any part of the page’s content is rendered on the screen.” — Philip Walton, First Contentful Paint (FCP), web.dev (updated Dec 6 2023). Jump to quote

web.dev — the threshold

• “sites should strive to have a First Contentful Paint of 1.8 seconds or less.” — same source. Jump to quote

web.dev — what FCP includes (the Key Point)

• “FCP includes any unload time from the previous page, connection set up time, redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. time, and Time To First ByteTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. (TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good.) which can be significant when measured in the field.” — same source.

web.dev — FCP’s role relative to the Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data.

• “the metrics Time to First Byte (TTFB) and First Contentful Paint (FCP) are both vital aspects of the loading experience, and are both useful in diagnosing issues with LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. (slow server response times or render-blocking resourcesRender-blocking resources are CSS and synchronous JavaScript files a browser must download and process before it can paint any visible content. They sit on the critical rendering path and delay First Contentful Paint and Largest Contentful Paint., respectively).” — Web VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors., web.dev. Jump to quote

LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. — how the FCP score is computed

• “Your FCP score is a comparison of your page’s FCP time and FCP times for real websites, based on data from the HTTP Archive.” — First Contentful Paint audit, developer.chrome.com.

LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. — how the Performance score works

• “The Performance score is a weighted average of the metric scores.”
• “The weightings have changed over time because the Lighthouse team is regularly doing research and gathering feedback to understand what has the biggest impact on user-perceived performance.” — Lighthouse performance scoring, developer.chrome.com.

Slow-FCP triage checklist

When FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. is high, work down this list in order — it’s roughly biggest-win-first:

• Check the field number, not just LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal.. Read CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program./PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. p75 for the real FCP; use LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. only to diagnose.
• Hunt render-blocking resourcesRender-blocking resources are CSS and synchronous JavaScript files a browser must download and process before it can paint any visible content. They sit on the critical rendering path and delay First Contentful Paint and Largest Contentful Paint.. CSS and synchronous JS in <head> are the #1 cause — Lighthouse’s “Eliminate render-blocking resourcesRender-blocking resources are CSS and synchronous JavaScript files a browser must download and process before it can paint any visible content. They sit on the critical rendering path and delay First Contentful Paint and Largest Contentful Paint.” audit lists them.
• Inline critical above-the-fold CSSCritical CSS is a performance technique that extracts the styles needed to render a chosen above-the-fold view, inlines them in the <head>, and defers the rest of the stylesheet. It speeds up first paint but is an advanced, optional optimization — Google says most sites don't need it — and carries real production risks around caching, CSP, and page state.; load the rest asynchronously.
• Add async/defer to non-critical scripts; move third-party tags after first paint.
• Measure TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good.. It’s inside FCP — a slow server inflates FCP before anything else. Add cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency. / a CDN / a faster origin.
• Kill redirect chainsA → B → C instead of A → C. Each hop loses link equity and adds latency. — each hop is a full round-trip before the first byte.
• Fix fonts: use font-display: swap or optional; never block for critical text. Preload the critical font file.
• Preconnect to required third-party origins; preload the LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. image / key requests.
• Trim payload: minify CSS, remove unused CSS/JS, efficient cache policy, smaller DOM, shorter critical request depth.
• Re-check LCP afterward — the same fixes should have moved it, and LCP is the one that affects rankings.

FCP cheat sheet

Field thresholds (CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program., 75th percentile)

LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. desktop rating (lab — note: stricter than field)

LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. 10 Performance-score weights (current as of this writing — weights shift between Lighthouse versions)

The three loading metrics, untangled

Order of events: FP ≤ FCP ≤ LCP.

What counts as “content” for FCP text · images (incl. background images) · <svg> elements · non-white <canvas> elements

Fast facts

• FCP’s clock starts at navigation — it includes redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. time, connection setup, and TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good..
• FCP is measurable in both lab and field.
• font-display: use swap/optional; avoid block (invisible text up to ~3 s).
• PreconnectResource hints are <link> elements (or equivalent HTTP Link headers) that tell the browser to do network work — DNS lookups, connection setup, or fetching a resource — earlier than it would discover the need on its own. The main ones are dns-prefetch, preconnect, preload, modulepreload, and prefetch. to third-party origins can save 100–500 ms.

Tools for measuring FCP

Field (real-user) data

• PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. — shows your URL’s CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. p75 FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. (field) alongside a LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. (lab) run.
• Chrome User Experience Report (CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.) — the real-user dataset behind the field numbers, via the API or BigQuery.
• web-vitals JavaScript library — drop onFCP(console.log) (or send it to your analytics) to capture FCP from your own visitors; it handles bfcacheThe back/forward cache (bfcache) is a browser feature that freezes a whole page in memory when you navigate away, so pressing Back or Forward can restore it instantly — no reload, no re-render, no network requests — as long as the browser hasn't evicted that frozen page first. It's a browser optimization, not a search ranking factor. and background-tab edge cases.

Lab (simulated) data

• LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. — in Chrome DevTools, PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking., or the CLI. Use it to diagnose FCP (the “Eliminate render-blocking resourcesRender-blocking resources are CSS and synchronous JavaScript files a browser must download and process before it can paint any visible content. They sit on the critical rendering path and delay First Contentful Paint and Largest Contentful Paint.” audit is the key one).
• Chrome DevTools Performance panelThe Performance panel is Chrome DevTools' built-in, local profiler for recording and analyzing how a page loads and runs — CPU, main-thread work, rendering, network, and live Core Web Vitals. The recorded trace is local, lab data from your own browser — not what Googlebot sees — though the panel can optionally show real-user CrUX field data alongside it. — see exactly when first paint and first contentful paint fire on a recorded load.

Measure it yourself with the Paint Timing API

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntriesByName('first-contentful-paint')) {
    console.log('FCP candidate:', entry.startTime, entry);
  }
}).observe({type: 'paint', buffered: true});

Or use the web-vitals library (recommended)

import {onFCP} from 'web-vitals';
onFCP(console.log);

A few caveats the raw API doesn’t handle that the web-vitals library does: it ignores FCP fired for background tabs, still reports FCP when a page is restored from the back/forward cache (a fresh navigation event doesn’t automatically fire for a bfcache restore, so it needs explicit handling), and uses activationStart rather than navigation start as the clock origin for prerendered pages. Cross-origin iframeHTML element that displays one webpage inside another — how embeds work. paint timing remains a known gap — a page whose main content renders inside one can show a misleadingly fast FCP.

FCP mistakes that hide the real bottleneck

• Treating FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. as a Core Web Vital. FCP is a useful diagnostic, but LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. are the Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. used in Google’s ranking systems. Use FCP to investigate the blank-screen phase, not as a substitute for field CWV data.
• Optimizing a tiny logo because it becomes the first paint. An earlier but meaningless paint can improve FCP while the useful page content still arrives late. Check LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. and the filmstrip alongside FCP so the change improves what a visitor actually sees.
• Starting with image compression when the page is blank. If nothing can paint, the usual blockers are server response timeTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good., render-blocking CSSRender-blocking resources are CSS and synchronous JavaScript files a browser must download and process before it can paint any visible content. They sit on the critical rendering path and delay First Contentful Paint and Largest Contentful Paint., synchronous JavaScript, or fonts. Follow the request waterfall before changing unrelated assets.
• Comparing unrelated LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. runs. Device emulation, network conditions, cache state, and run-to-run variation all move a lab FCP. Compare repeated runs under the same settings and confirm the result with field dataPerformance metrics captured from real users, not lab tests. where available.

The blank-screen budget

Break FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. into three consecutive questions instead of treating the final number as one problem:

1. How long before the HTML arrives? Inspect TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good.. A slow response means the browser cannot begin useful work, so start with the server, cache, redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't., or connection setup.
2. How long before the browser can render? Inspect render-blockingRender-blocking resources are CSS and synchronous JavaScript files a browser must download and process before it can paint any visible content. They sit on the critical rendering path and delay First Contentful Paint and Largest Contentful Paint. stylesheets, synchronous scripts, and font behavior. The HTML may be present while the main thread or render path is still blocked.
3. What actually becomes the first content? Use a filmstrip or trace to confirm that the first paint is meaningful text or imagery, not a tokenA token is the smallest unit of text (or image/audio/video) an LLM processes — roughly 4 characters, or about ¾ of an English word. A context window is the maximum number of tokens (input plus output) a model can hold at once, like its short-term memory. element that makes the metric look better without improving the experience.

The framework keeps fixes in order: delivery first, renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. second, usefulness third. Re-run the same lab profile after each change so you know which phase moved.

Test yourself: First Contentful Paint

Five quick questions on what FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. measures and how to diagnose it. Pick an answer for each, then check.

Resources worth your time

Google / web.dev

• First Contentful Paint (FCP) — the canonical reference: definition, thresholds, measurement code, and the full optimization list.
• Web Vitals — how FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. relates to the Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. and why it’s a diagnostic metric.
• Largest Contentful Paint (LCP) — the metric FCP helps you diagnose, and a Core Web Vital.
• Time to First Byte (TTFB) — the server-response metric that lives inside FCP.

LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal.

• First Contentful Paint audit — desktop rating bands and how the score is computed.
• Lighthouse performance scoring — the metric weights, FCP at 10%.

My related writing

• The Beginner’s Guide to Technical SEO — where page speed fits in the bigger picture.
• Core Web Vitals: What They Are & How to Improve Them — the ranking-signal metrics FCP feeds into.

From around the industry

• First Contentful Paint (FCP) — Philip Walton’s canonical Google article: definition, thresholds, Paint Timing API code, and the full optimization list.
• Web Vitals — Google’s framework explaining where FCP sits (an “Other Web Vital,” supplementary to the Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data.) and its role in diagnosing LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good..
• First Contentful Paint audit — Chrome Developers doc covering LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. desktop rating bands and how the FCP score is computed against HTTP Archive data.
• Time to First Byte (TTFB) — Google’s guide on why TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. precedes and is included in FCP, and how a slow server eats your FCP budget before the browser paints a single pixel.
• Eliminate render-blocking resources — Chrome Developers guide on the #1 FCP killer: CSS and synchronous JS in <head> that block the browser from painting.
• Ensure text remains visible during webfont load — Chrome Developers audit explaining font-displayFont loading is how a browser fetches, applies, and renders custom web fonts — and specifically what it shows while the font file downloads. Those choices, controlled mainly by the CSS font-display property, directly affect two Core Web Vitals: LCP and CLS. values and why block delays FCP while swap or optional keeps text visible.
• First Contentful Paint — NitroPack’s practical FCP guide with CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms.-specific optimization tips and a clear field-vs-lab explanation.

Stats worth citing

• Good FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. = ≤ 1.8 s at the 75th percentile of real users; needs-improvement up to 3.0 s; poor beyond that (field/CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. thresholds). Source
• LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. desktop is stricter: ~0–0.9 s is “green,” because the lab runs a throttled, simulated environment rather than real-world conditions. Source
• FCP is 10% of the LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. 10 Performance score (current as of this writing — weights shift between Lighthouse versions) — alongside TBTTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital. 30%, LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. 25%, CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. 25%, and Speed IndexSpeed Index measures how quickly content is visually displayed during page load — the average time at which visible parts of the page appear, scored in seconds (lower is better). It's a lab-only Lighthouse metric, not a Core Web Vital and not a ranking factor. 10%. Source
• Preconnecting to third-party origins can save 100–500 ms of load time by establishing early connections. Source

FCP

First Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital.

Related: Core Web Vitals, TTFB, LCP

FCP

First Contentful PaintFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. (FCP) measures the time from when the user first navigates to a page to when any part of that page’s content is first rendered on screen. “Content” here means text, images (including background images), <svg> elements, or non-white <canvas> elements — so FCP fires the moment the user sees anything real, even a logo or a single line of text.

FCP is not a Core Web Vital. It’s a supplementary, diagnostic metric that Google measures in both the lab (LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal., PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking., DevTools) and the field (CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.). Its main job is to help diagnose Largest Contentful PaintLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. (LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good.) problems caused by render-blocking resourcesRender-blocking resources are CSS and synchronous JavaScript files a browser must download and process before it can paint any visible content. They sit on the critical rendering path and delay First Contentful Paint and Largest Contentful Paint. — FCP always happens at or before LCP, so it’s the early-warning signal in the loading sequence. The three Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. that actually feed Google’s ranking systems are LCP, INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good..

The field thresholds, measured at the 75th percentile of real users: Good ≤ 1.8 s, Needs improvement ≤ 3.0 s, Poor > 3.0 s. In LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. 10 (current as of this writing — weights shift between versions), FCP is worth 10% of the Performance score. The biggest fixes are eliminating render-blocking CSS/JS, reducing Time to First Byte (TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good.), inlining critical CSSCritical CSS is a performance technique that extracts the styles needed to render a chosen above-the-fold view, inlines them in the <head>, and defers the rest of the stylesheet. It speeds up first paint but is an advanced, optional optimization — Google says most sites don't need it — and carries real production risks around caching, CSP, and page state., using font-display: swap, and preconnecting to required origins — but check your own trace to confirm which of these is actually the bottleneck on your page.

Related: Core Web Vitals, TTFB, LCP

Changelog