Page speed and conversion
Loading speed influences whether visitors stay and convert, and Google's Core Web Vitals formalise field metrics for it (LCP, INP, CLS). The direction is well established, but the magnitude is specific to each site and audience — borrowed 'every 100ms costs X%' figures are not yours to cite. This page explains the measurable link and how to study it honestly.
What the standards measure
Core Web Vitals are Google's user-centric performance metrics: Largest Contentful Paint (loading), Interaction to Next Paint (responsiveness), and Cumulative Layout Shift (visual stability). They are reported as field data from real visitors, which is the relevant signal for conversion, not lab scores alone.
- LCP — perceived load speed
- INP — responsiveness to interaction
- CLS — visual stability
Direction is known, magnitude is not
It is well documented that slower pages tend to lose users, and Google treats page experience as a factor. But the exact conversion cost of a given delay depends on your audience, devices, and content. Quoting a generic 'X% per 100ms' figure as if it were your number is exactly the kind of borrowed benchmark to avoid.
Studying it on your site
Treat speed as a testable lever: ship a real performance improvement to a randomised group and measure the conversion difference, or correlate field vitals buckets with outcomes over time. Either way the magnitude comes from your own data, with the usual caveat that confounders (device mix, network) must be considered.
How it appears in analytics and logs
A page with poor field LCP or INP and a high drop-off is a candidate for a speed experiment — but only your data tells you how much conversion the latency actually costs.
Diagnostic use case
Measure your own Core Web Vitals against your own conversion data rather than quoting generic speed-uplift numbers, then experiment on real performance fixes.
What WebmasterID can help detect
WebmasterID can correlate first-party performance signals with conversion events on the same site, so the speed-to-outcome relationship you act on is measured, not assumed.
Common mistakes
- Quoting a generic speed-uplift statistic as your own.
- Optimising lab scores while ignoring real-user field data.
- Crediting speed for a conversion gain without a controlled test.
Privacy and accuracy notes
Core Web Vitals are collected as aggregate field measurements. They describe performance, not people, and need no personal identifiers.
Related pages
- Mobile conversion gaps
Mobile and desktop frequently show different conversion rates, but a lower mobile number is not automatically a defect. The gap can be real friction (small targets, slow pages), different intent (browsing versus buying), or a measurement artefact (consent, tracking loss). Diagnosing which one applies is the work. This page lays out the causes and how to tell them apart.
- Drop-off analysis
Drop-off analysis measures, step by step, how many users fail to advance to the next stage of a funnel and where the largest losses occur. By isolating the single biggest leak it directs limited optimisation effort to the step with the most upside, instead of guessing or polishing stages that already convert well.
- Confounding variables in conversion
A confounding variable is a third factor that affects both the thing you changed and the outcome you measured, producing a spurious association. Confounders are why 'we shipped X and conversions rose' is weak evidence — a campaign, a season, or a price change could be the real cause. Randomised experiments neutralise confounders by design. This page explains the concept and the defence.
- Website observability
Watch first-party performance alongside outcomes.
Sources and verification notes
- web.dev — Core Web VitalsLCP, INP, CLS definitions and field measurement.
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.