Core Web Vitals Are Cash: The Milliseconds Killing Your Conversion Rate

The exchange rate between milliseconds and money

Performance has one of the best-quantified ROI stories in all of web. The numbers are consistent across independent studies. Per aggregated Core Web Vitals research, every 100ms of delay can cut conversions by up to 7% (Akamai), and a Deloitte study for eBay found each 100ms LCP improvement lifted session-based conversions by 1.11%. The rule of thumb that falls out, ~1% of conversions per 100ms, is enough to do the math your CFO cares about.

The real-world case studies are not marginal. Vodafone Italy improved LCP 31% and saw 8% more sales. Ray-Ban's optimizations drove mobile conversion up 101% and desktop up 156%. Nykaa's 40% LCP improvement yielded 28% more organic traffic from smaller cities. These aren't edge cases, they're what happens when a measurable bottleneck gets removed.

The three vitals, and what each one costs you

LCP, Largest Contentful Paint (load)

How long until the main content is visible. Target under 2.5s. The usual culprits, unoptimized hero images, slow server response (TTFB), and render-blocking CSS/JS, are all scannable. LCP is where most of the conversion money lives because it's the metric the user feels as "is this thing loading?"

INP, Interaction to Next Paint (responsiveness)

Replaced FID in 2024 and it's stricter. INP measures how quickly the page responds to taps and clicks. Target under 200ms. Heavy JavaScript and long main-thread tasks make every interaction feel laggy, the "I tapped the button and nothing happened" experience that kills mobile checkout.

CLS, Cumulative Layout Shift (stability)

How much the page jumps as it loads. Target under 0.1. Unsized images, late-loading fonts, and injected ads cause buttons to move just as the user taps, producing misclicks and abandoned carts. CLS is a pure, fixable conversion leak.

Field data, not lab data

One critical distinction teams get wrong: lab scores lie about real users. A Lighthouse run on your fast laptop over fast wifi is not what your customer on a mid-range Android over LTE experiences. Google ranks on field data (the Chrome User Experience Report), so a scan that emulates real mobile conditions, throttled CPU and network, is the one that predicts both rankings and revenue.

# Scan with mobile field conditions, not desktop lab conditions
const result = await lighthouse(url, {
  formFactor: 'mobile',
  throttling: {
    rttMs: 150, throughputKbps: 1638,   // ~regular 4G
    cpuSlowdownMultiplier: 4,           // mid-range device
  },
  onlyCategories: ['performance'],
});

const cwv = result.lhr.audits;
const report = {
  LCP: cwv['largest-contentful-paint'].numericValue,
  INP: cwv['interaction-to-next-paint']?.numericValue,
  CLS: cwv['cumulative-layout-shift'].numericValue,
};

// Gate: a deploy that regresses LCP past budget fails CI
const LCP_BUDGET_MS = 2500;
if (report.LCP > LCP_BUDGET_MS) {
  console.error(`LCP ${Math.round(report.LCP)}ms exceeds ${LCP_BUDGET_MS}ms budget`);
  process.exit(1);
}

The fixes are mostly known, finding them is the work

Once a scan localizes the problem, the remediations are well-trodden: serve next-gen image formats and size them explicitly, defer non-critical JavaScript, preconnect to critical origins, set font-display and reserve space to kill CLS, and attack TTFB at the server or CDN layer. The hard part was never the fix, it was knowing precisely which of these is costing you, on which template, under real mobile conditions. That's the scan's job.

The bottom line

Core Web Vitals convert directly into money at a roughly 1%-per-100ms rate, more than half of sites fail the thresholds, and the gaps are localizable with a mobile-emulated scan and fixable with known techniques. Scan under real field conditions, translate the result into a revenue figure leadership can act on, fix LCP first, and gate deploys against a performance budget so you don't pay for the same milliseconds twice.