Your Core Web Vitals score is costing you customers. Here's how to estimate how much.
What the research actually says about speed and abandonment, a four-step way to estimate what slowness costs your business, and the fixes that usually matter most.
By BIGWEB6 min read
Many teams treat Google's Core Web Vitals as an SEO checkbox. They are better read as a measure of how long buyers wait, and how much the page fights them while they try to act. Speed affects rankings a little; it affects behaviour a lot.
What the research actually says
- Slow pages lose visits. Google's 2016 mobile research found that 53% of mobile site visits are abandoned when a page takes longer than three seconds to load. (Google / DoubleClick, "The Need for Mobile Speed", 2016.)
- Bounce risk climbs with each second. Google's 2017 benchmark found that as load time goes from one second to three, the probability of a bounce rises by 32%. (Google / SOASTA Research, 2017.)
- Small delays matter at scale. An often-cited 2006 Amazon experiment, described by former engineer Greg Linden, found that every 100 ms of added delay reduced sales by about 1%. It is one company's internal test from two decades ago, so treat it as direction, not a rate you can apply to your own site.
None of these numbers will tell you what speed is worth to your business. Your own data will.
How to estimate what slowness costs you
- Find your slow share. In Google Search Console (Core Web Vitals report) or PageSpeed Insights field data, note the share of mobile visits rated "poor" or "needs improvement".
- Compare conversion by speed. In your analytics, compare the conversion rate of sessions on fast pages with sessions on slow ones, for the same page type and traffic source.
- Do the arithmetic. Slow sessions per month × (fast conversion rate − slow conversion rate) × average order or lead value = the monthly revenue at stake.
- Confirm with a test. Fix one template, then compare the same metric for four weeks before and after. That is the number to plan around, not an industry average.
What Core Web Vitals measure, in plain terms
Largest Contentful Paint (LCP) — how quickly the main content (usually the hero image or headline) appears. Google's "good" threshold is 2.5 seconds or less.
Interaction to Next Paint (INP) — how quickly the page responds when someone taps, clicks or types. It replaced First Input Delay in 2024. "Good" is 200 milliseconds or less.
Cumulative Layout Shift (CLS) — how much the page jumps around while it loads. "Good" is 0.1 or less.
Thresholds: web.dev, "Defining the Core Web Vitals metrics thresholds".
The fixes that usually matter most
- Images. Serve modern formats (WebP or AVIF) at the size each device needs, set width and height so nothing shifts, and lazy-load what sits below the first screen. Oversized hero images are the most common cause of a slow LCP.
- JavaScript. Remove scripts that don't run on the page, and defer analytics, chat and tag-manager code until the page is usable. Heavy third-party scripts are the most common cause of a slow INP.
- Fonts. Preload the one or two fonts the first screen needs, use
font-display: swap, and subset to the characters you use. - Delivery. Serve pages and assets from a CDN close to your buyers, and cache what doesn't change, so the first byte arrives quickly.
What we offer
Our Core Web Vitals rescue diagnoses and fixes LCP, INP and CLS on up to five templates, for a fixed, published price. See it on the pricing page. We measure before and after with field data and report what changed; we don't promise a traffic or revenue figure in advance, because your result depends on your traffic and your offer.