How Much Is Your Slow Website Costing You?

Every service-business owner I have ever audited has one number they cannot put a value on: the customers who almost called and then closed the tab. They never appear on the books. They do not bounce out of a CRM. The phone simply does not ring as much as it could, and the silence is invisible.

That silence has a price. It is not as fuzzy as people assume. The math is rough, but the order of magnitude is honest. This post walks through how to actually quantify what your current website is costing you in unbooked work, and why the answer almost always justifies a custom build several times over.

Step 1: how many people leave because of speed?

Google has been publishing data on this for over a decade. The number is consistent across studies: every additional second of mobile load time loses roughly 7–10% of mobile visitors before they read a word. Not "they bounce eventually", they leave during the load.

The way to measure where you sit:

1. Run your homepage through pagespeed.web.dev. Note the mobile score.
2. If the score is 95+, you are at roughly 1 second of mobile load time. Skip to step 2.
3. If the score is 50, you are at roughly 4–5 seconds.
4. If the score is below 30, you are at 6+ seconds, which means a measurable share of mobile visitors give up before the hero image even appears.

The bounce-rate cost: roughly 1.5% additional mobile bounce per PageSpeed point below 95. That is conservative; real-world studies on flaky cellular connections suggest higher. A site at PageSpeed 55 (the typical Wix score) is losing approximately (95 - 55) × 1.5% = 60% of mobile bounces over the floor, capped at the actual mobile-bounce ceiling, which is usually around 60%.

Translation: if you have 1,000 monthly visitors and 70% are on mobile, you have 700 mobile visits. A site at 55 is losing roughly 35–50% of those before they engage. Three hundred mobile visitors per month who never had a chance to become customers.

Step 2: what would those visitors have done?

The visitors who DID stay tell you the conversion rate. Pull from your form-submission count or call-tracking number:

Conversion rate = (form submissions + tracked calls) / total monthly visitors

For service-business websites, the typical range is 1.5–3.5%. If your form has good intake fields and a clear CTA, expect the high end. If your form is "Name / Email / Message" the conversion rate is closer to the low end, the visitor stares at the empty Message field and gives up.

Apply that conversion rate to the visitors you LOST: 300 lost mobile visitors × 2% conversion = 6 missed leads per month, or 72 per year.

Step 3: what is each lead worth?

Two numbers:

• Lead-to-close rate. Of the qualified leads who do reach you, what percentage become paying customers? Most service businesses run 30–55%. Use 40% if you are not tracking it.
• Average job value. The dollar value of a typical close. A roofing job, an HVAC install, an inspection report, a landscape design contract.

Continue the example:

• 72 missed leads × 40% close rate = 29 missed jobs per year.
• 29 missed jobs × $500 average job value = $14,500 of revenue per year.
• Or, if your average job is $5,000: $145,000 of revenue per year.

That is the silent line item. It does not appear on a P&L because it is the customers who almost called and then closed the tab.

The honest caveats

This math is rough on purpose. Several things I am NOT counting:

• Lower local-pack ranking from generic schema. A real custom site moves you up in the Google Maps three-pack, which has more conversion impact than any other single factor for service-business search. The calculator does not estimate this.
• Better forms. A trade-specific intake form (real fields, real urgency routing) converts measurably better than a generic Name/Email/Message form. The lift is typically 1.5–2×. Not in the calculator.
• Long-tail organic traffic from real city pages. Doorway service-area pages do not rank. Real, indexable city pages with local content compound over time. Not in the calculator.
• Retention impact of a maintained site. A custom site does not break, does not get hacked, does not regress when WordPress pushes an update. Stability is a real revenue protector. Not in the calculator.

So the number you arrive at is the floor, the page-speed line alone, not counting any of the other levers a custom-coded site moves at the same time.

Pull the actual lever

Three ways to apply this:

1. The interactive calculator. Plug in your real numbers (visitors, mobile share, current PageSpeed, conversion rate, average job value, close rate). Get the annual leakage estimate in 30 seconds. Numbers run in your browser; nothing leaves your device.
2. The return-on-investment page. The calculator on this post handles the speed-and-conversion lever. The ROI page walks through all four levers a well-built site moves — speed, local search, conversion path, maintenance — with the worked-example math and the cost-side comparison against the standard plan.
3. The free 5-point audit. If you would rather have me run real Lighthouse numbers and a real schema check on your URL and write up the findings, that takes five business days, costs nothing, and the deliverable is a written report you can act on with or without me.
4. The discovery call. Twenty minutes. Bring the numbers from the calculator. We will talk through where they come from and what a custom build would actually change.

The thing nobody puts on a website

Most agencies will not write this post. The reason is simple: if a $1,800 Wix subscription is leaking $14,500 a year, the agency that recommended Wix has some explaining to do. The number does not flatter anyone except the alternative.

The math is the math. The hardest line on a service-business P&L to see is the one that does not appear, revenue that never happened because the website never gave a fair-shot mobile visitor a chance to become a customer. Quantifying that line is the work this post and the calculator are trying to make easier. Once you can see it, the budget conversation gets a lot simpler.

If you would rather check the site yourself first, the 12-point self-audit takes ten minutes and catches the obvious problems. If the audit says the site needs more than a patch, the rebuild-or-patch decision framework is the right next read.