A Back-of-Napkin Way to Work Out What a Slow Website Costs You in Enquiries

01 September 2026·4 min read

Quick answer: You don't need a developer to estimate what page speed is costing you — you need two numbers you probably already have (monthly visitors and current load time) and one industry rule of thumb about how conversion rates fall as load time climbs. Multiply it out and you get a rough monthly enquiry loss, then turn that into dollars using your own close rate and average job value. It's a back-of-napkin estimate, not a lab result — but it's usually enough to make speed a real priority instead of a nice-to-have. 📈

Most page-speed advice stops at "Google says fix it" and a score out of 100 that means nothing to anyone signing off the invoice. What actually moves a business owner is a dollar figure — so here's a rough, honest way to put one on your own slow website using numbers you can pull in five minutes. 💖

What most businesses get wrong

Treating speed as an abstract score — a "73/100" on a speed test doesn't tell anyone what it's actually costing.
Benchmarking against nothing — "our site feels fine" usually means "fine on the office wifi, on a decent laptop", not fine on a customer's phone on 4G.
Fixing speed and never measuring the payoff — without a before-and-after number, speed work gets deprioritised again the next time budget's tight.
Only testing on desktop — most enquiry-driving traffic for a service business arrives on mobile, where load times are almost always worse.

The back-of-napkin formula

Grab two numbers, then apply one rule of thumb:

Step 1: Monthly website visitors (from Google Analytics).
Step 2: Your mobile load time (from Google PageSpeed Insights — use the real "Field Data" if it's shown, not just the lab score).
Step 3: Subtract 2 seconds (a reasonable benchmark) from your load time to get "seconds over".
Step 4: [Seconds over] × 4.42% ≈ the relative drop in conversion rate an often-cited ecommerce study links to each extra second.
Step 5: Visitors × your normal enquiry conversion rate × that relative drop = enquiries likely lost per month. Multiply by your close rate and average job value for a dollar figure.

Three worked examples

A local service business: 1,800 monthly visitors, mobile load time 6 seconds (4 over benchmark), usual enquiry conversion rate 3%. Relative drop ≈ 4 × 4.42% = 17.7%, pulling conversion down to roughly 2.47%. That's about 9-10 enquiries a month walking away. At a $650 average job and 40% close rate, that's roughly $2,500-2,600 a month sitting in lost speed alone.

A B2B firm with a long sales cycle: Only 600 monthly visitors but each enquiry is worth a lot. Load time 5.5 seconds (3.5 over), baseline conversion 2.5%. Relative drop ≈ 15.5%, costing roughly 2 enquiries a month. At an $18,000 average deal and 25% close rate, that's about $9,000 a month at risk from two missing enquiries — low volume, high stakes.

A local business with a seasonal spike: Traffic triples to 6,000 visitors in peak month, and the extra load tips the site out to 7 seconds (5 over). Relative drop ≈ 22%, on a normal 4% conversion rate — roughly 53 enquiries lost in that one month alone. Speed problems bite hardest exactly when traffic, and the stakes, are highest.

Where to actually pull your two real numbers

In Google Analytics (GA4), monthly visitors sits under Reports → Life cycle → Acquisition, or the top-line "Users" figure for the date range. For load time, run your homepage and your main enquiry page through PageSpeed Insights on mobile — if there's enough traffic, it'll show real "Field Data" from actual visitors, which is more honest than the simulated lab score. For your conversion rate, don't guess — count enquiries (form fills, calls, bookings) against sessions over the same period, or use whatever your booking or CRM tool already tracks.

💡 Heads up: the 4.42%-per-second figure comes from older ecommerce research, and it's an average across many very different sites — not a guarantee for yours. Its real value here isn't precision, it's giving you a rough, defensible number to justify fixing speed at all. Re-run the calculation after you fix things and compare your own before-and-after; that's the number that actually matters.

Mistakes to avoid

Testing speed only in the office — on fast wifi and a new laptop, when most visitors are on mobile data.
Confusing "loads fine for me" with population-level results — your experience isn't representative.
Fixing speed and never re-measuring conversion — you lose the ability to prove the fix was worth it.
Chasing a perfect 100 speed score — instead of the load time your actual visitors experience, which matters far more.

Frequently asked questions

Is the 4.42%-per-second rule accurate for my business?

Honestly, not precisely — it's an average from ecommerce studies, and B2B or high-consideration purchases often behave differently to impulse retail buys. As a back-of-napkin exercise it's directionally useful for making the case that speed matters; it's not a lab-grade forecast for your specific business.

What actually counts as "slow"?

As a rough guide, mobile load times creeping past 3 seconds is where drop-off tends to accelerate. Check yours via PageSpeed Insights rather than guessing from how it feels on your own device.

Will fixing speed alone fix my enquiry numbers?

No — speed removes friction, it doesn't create demand or fix a weak offer, unclear copy, or a confusing enquiry form. Treat it as one lever in the mix, not the whole strategy.

How often should I re-run this calculation?

Quarterly is a sensible rhythm, or straight after any big design, platform, or hosting change — that's when load times most often quietly blow out again.