siux studio

Core Web Vitals, explained in dollars

Core Web Vitals are the three numbers Google uses to judge how a page feels to real visitors: how fast it shows up, how fast it reacts, and how still it stays. Here is what each one measures, the thresholds that matter, how to fix them, and what they are worth.

Updated

Thresholds

The thresholds at a glance

Google rates each metric at the 75th percentile of real visits, on mobile and desktop separately. A page passes when all three Core Web Vitals are good.

MetricMeasuresGoodNeeds workPoor
LCPLargest Contentful Paint≤ 2.5 s2.5 – 4 s> 4 s
INPInteraction to Next Paint≤ 200 ms200 – 500 ms> 500 ms
CLSCumulative Layout Shift≤ 0.10.1 – 0.25> 0.25
TTFBsupportingTime to First Byte≤ 0.8 s0.8 – 1.8 s> 1.8 s
FCPsupportingFirst Contentful Paint≤ 1.8 s1.8 – 3 s> 3 s

Metric by metric

What each one measures, and how to fix it

LCPCore Web Vital

Largest Contentful Paint

How long it takes for the largest thing in the viewport to appear: usually the hero image, the product photo or the headline.

It is the moment a visitor sees what they came for. Until then, paid clicks and search visits are waiting on a blank or half-built page, and many leave.

What slows it down

  • Large images that are not resized or compressed
  • Slow server responses on uncached pages
  • CSS, fonts and scripts that block rendering
  • The main image loaded late, lazily or by JavaScript

How to fix it

  • Serve the main image in WebP or AVIF, at the size it is shown
  • Give that image fetchpriority="high", and never lazy-load it
  • Cache pages and serve them from a CDN
  • Inline critical CSS and defer scripts that are not needed to paint

Example reading

+8%

more sales at Vodafone after improving LCP by 31%.

Source: web.dev

INPCore Web Vital

Interaction to Next Paint

How long the page takes to respond visually after a tap, click or key press, taken across the whole visit. It replaced First Input Delay in March 2024.

Slow responses land on the buttons that make money: add to cart, plan toggles, filters and checkout. A tap that seems to do nothing gets tapped again, or abandoned.

What slows it down

  • Long JavaScript tasks that block the main thread
  • Third-party scripts: chat, reviews, analytics, A/B tests
  • Large re-renders after every interaction
  • Heavy work done before the screen updates

How to fix it

  • Break long tasks up and yield to the main thread
  • Load third-party scripts after the page is interactive, or drop them
  • Update the screen first, then do the rest of the work
  • Keep the DOM small so each update is cheap

Example reading

+80–100%

mobile conversion at Redbus after cutting blocking time and layout shift.

Source: web.dev

CLSCore Web Vital

Cumulative Layout Shift

How much the page moves around while it loads and while people use it: content jumping as images, banners or fonts arrive late.

A button that moves right as someone taps it sends them to the wrong place, or makes them give up. It also makes a store feel less trustworthy.

What slows it down

  • Images and embeds without width and height
  • Banners, cookie notices and widgets injected above content
  • Web fonts that swap in with different metrics
  • Animations that change layout instead of using transforms

How to fix it

  • Set width and height, or aspect-ratio, on every image and embed
  • Reserve space for banners and widgets before they load
  • Use fallback fonts with matching metrics
  • Animate with transform and opacity only

Example reading

TTFBSupporting metric

Time to First Byte

How long the server takes to start sending the page. It is not a Core Web Vital, but it sets the floor for everything that follows.

Every millisecond here is added to LCP. Slow themes, apps and uncached pages usually show up here first.

What slows it down

  • Pages built on every request with no cache
  • Slow hosting or a server far from visitors
  • Chains of redirects

How to fix it

  • Cache full pages and serve them from a CDN
  • Move hosting closer to visitors, or upgrade it
  • Remove redirect chains

Example reading

FCPSupporting metric

First Contentful Paint

When the first text or image appears. Also not a Core Web Vital, but the first sign to a visitor that something is happening.

A blank screen for seconds is when people hit the back button, before they see anything you want them to see.

What slows it down

  • Render-blocking CSS and fonts
  • Slow server responses
  • Content that only appears after JavaScript runs

How to fix it

  • Inline critical CSS and preload key fonts
  • Render the page on the server
  • Cut what has to load before the first paint

Example reading

Measuring

Lab data and real-visitor data are not the same

PageSpeed Insights shows two kinds of numbers, and they often disagree.

  • Lab data

    One simulated visit on a throttled device. Useful to debug a page, but it is one moment, on one device, with no real users. This is the score most tools show first.

  • Real-visitor data

    What real Chrome visitors experienced over the last 28 days, from the Chrome UX Report. This is what Google uses, but only for pages and sites with enough traffic.

  • Your visitors, next to your sales

    SIUX Studio measures your own visitors on every page, even low-traffic ones, and puts each metric next to the revenue that page makes.

SEO

Do Core Web Vitals affect Google rankings?

Yes, but lightly. They are part of the page experience signals Google’s ranking systems use, and relevance still comes first: a fast page with the wrong content will not outrank a slower page with the right one. The bigger effect is on people. Visitors who wait leave before they read, and the ones who stay convert less.

The research behind the maths

More retail conversions from a site just 0.1 s faster on mobile.

+8.4% conversionsDeloitte × Google

Higher average order value in the same study, same 0.1 s.

+9.2% order valueDeloitte × Google

More sales at Vodafone after improving LCP by 31%.

+8% salesweb.dev

Better mobile conversion at Lazada with a 3× faster LCP.

+16.9% mobileweb.dev

FAQ

Core Web Vitals questions

Talk to a person

Nothing here is a chatbot. Write to us and a founder answers, usually the same day.

Write to us
What are the three Core Web Vitals?
Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). They measure loading, responsiveness and visual stability.
What are good Core Web Vitals scores?
LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less, measured at the 75th percentile of real visits.
What replaced First Input Delay?
Interaction to Next Paint (INP) replaced First Input Delay (FID) as a Core Web Vital in March 2024. INP looks at every interaction in a visit, not just the first.
Why does PageSpeed Insights show a different score from my real data?
The score comes from one simulated lab visit, while the Core Web Vitals assessment uses 28 days of real Chrome visits. Google uses the real-visitor data.
Are TTFB and FCP Core Web Vitals?
No. Time to First Byte and First Contentful Paint are supporting metrics. They help find the cause of a slow LCP, but Google does not assess them as Core Web Vitals.
How much revenue can faster Core Web Vitals bring?
It depends on the site. In the Deloitte and Google study, a 0.1 second faster mobile site lifted retail conversions by 8.4%. The only reliable number for your site comes from your own visitors and sales.

still guessing?

See what your Core Web Vitals cost you, page by page

Not ready for a report? Leave your email for early access to the dashboard.