Methodology · technical reference

How BoltAudit calculates Visitor Loss

This page is for the person who wants to know whether the numbers on the dashboard are defensible. They are. Here's the math.

4 minute read Last updated May 2026 Sources: Google, SOASTA, Akamai
TL;DR

Visitor Loss is an estimate of the share of visitors leaving your site because it's too slow. Computed from your site's measured Core Web Vitals — separately for mobile and desktop — mapped through published bounce-probability curves from Google/SOASTA research. Not a revenue prediction. A research-backed estimate, with inputs and curves disclosed below.

How the math works

Three inputs, one curve, one number. The full pipeline:

Step 1 · Inputs
Measured Core Web Vitals
LCP, TTFB, INP from your site. We measure both mobile and desktop profiles in every audit.
Step 2 · Curve
Bounce-probability function
A piecewise curve fit to Google/SOASTA bounce-vs-load-time data. Different for mobile vs desktop.
Step 3 · Output
Visitor Loss %
The estimated share of visitors leaving because the site is slow. Mobile, desktop, total.

The formula, in code:

visitor_loss_% = bounce_probability(measured_LCP) − bounce_probability(target_LCP)

target_LCP is 2.5 seconds — Google's threshold for "good" Largest Contentful Paint.

Bounce probability vs. page load time
Higher load time → more visitors leave. The curve is published; the math is just the curve applied to your site's measurements.
+125% +90% +50% +25% 0 Google "good" target LCP = 2.5s +32% +25% +90% +70% 1s 2.5s 3s 5s 6s 8s 10s+
Mobile bounce probability
Desktop bounce probability
Google "good" threshold (2.5s)

The curve, in tabular form:

Load time Mobile bounce ↑ Desktop bounce ↑ Source
1s → 3s+32%+25%Google / SOASTA
1s → 5s+90%+70%Same
1s → 6s+106%+85%Same
1s → 10s+123%+100%Same

Per-finding Recovery %

Each finding has a measured time-savings estimate (e.g., "+1.4s TTFB"). That time-savings is translated through the same bounce curves, with a layer-specific weight reflecting how that fix hits mobile vs. desktop differently.

Mobile layer weights Mobile Desktop
Infrastructure
1.0× / 1.0×
Database
1.0× / 1.0×
Backend
1.1× / 1.0×
Frontend
1.4× / 1.0×
Why the asymmetry? Mobile has slower CPUs and tighter bandwidth, so frontend fixes (JS, CSS, images) recover more mobile users than desktop. Backend fixes are mildly weighted because mobile feels CPU bottlenecks slightly more. Infrastructure and database hits affect TTFB equally regardless of device.

Why we don't compute "recoverable revenue"

An earlier version of this methodology included a "Recoverable Revenue $/month" metric. We removed it. Three reasons:

Inputs aren't reliable
A credible dollar value needs monthly sessions, conversion rate, and average order value — broken down by device. Most users won't connect GA4 in their first session.
Fix-level attribution is causal modeling, not measurement
"This fix recovers $340/month" implies a counterfactual we can't actually run. The first vocal developer to look closely would publish "BoltAudit's revenue numbers are made up" — and wouldn't be wrong.
Visitor Loss already delivers urgency without guessing
"Losing 33% of visitors — 41% mobile, 22% desktop" is visceral, defensible, and built from measurements we actually have.
Honest disclaimer
Estimates based on industry research from Google, SOASTA, Akamai. Numbers reflect typical bounce-vs-load behavior across mobile and desktop; your visitors' actual tolerance may vary.

If you find a case where the math doesn't hold, email methodology@boltaudit.com.