Site Speed and Money: What a Slow Website Actually Costs

Your website feels fast. You open it every day on the office wifi, on a desktop, with everything already cached, and it appears instantly.

Your customer is standing in a driveway on a phone with two bars of coverage, and for them the same page takes six seconds to show anything readable. Most of them will not wait. They go back to the search results, and in your analytics that visit still counts as a session, so the traffic looks healthy while the enquiries do not arrive.

Website speed conversions are linked in a way that is easy to state and hard to see from the inside. Every additional second is another chance for someone to leave, and the loss compounds, because every later step on the site depends on the visitor still being there to take it.

The relationship between speed and enquiries, without the made-up percentages#

You will find a lot of articles quoting a precise figure for how much conversion you lose per second of delay. I am not going to give you one, because the honest answer is that it depends enormously on the device mix and on how badly the visitor wants what you sell. A person whose hot water cylinder just burst tolerates more delay than someone idly comparing landscapers.

What is reliably true is the direction and the mechanism. Slow pages lose visitors before the content renders, and those visitors are disproportionately the mobile ones on poor connections, who for a local service business are often the ones with an urgent job.

You can measure this on your own site rather than borrowing someone else's number. In your analytics, compare the conversion rate of your fastest landing page against your slowest, controlling for traffic source where you can. On most small business sites the gap is obvious enough that you stop needing an industry statistic to justify the work.

Core Web Vitals in business language#

Google publishes three measures of what a page feels like to use. They are worth understanding because they describe the visitor's actual experience rather than a technical abstraction, and because Google uses them as a ranking signal.

Largest Contentful Paint measures how long until the main content appears. Google's threshold for good is under 2.5 seconds. In practice this is almost always your hero image or your headline block, and it is the number that decides whether someone sees your business at all.

Interaction to Next Paint measures how quickly the page responds when someone taps something. Under 200 milliseconds is the good band. A page that takes a full second to react to a tap on the phone number gets tapped again, which on some sites cancels the first action.

Cumulative Layout Shift measures how much the page jumps around while loading, with a good score under 0.1. This is the one that makes someone tap the wrong button because an ad or a late-loading image pushed the content down. It is also the most common cause of a visitor accidentally leaving your page in frustration.

You do not need to memorise the numbers. Google's PageSpeed Insights reports all three, colour codes them, and tells you which element is responsible.

Test it the way your customers experience it#

Two tests, and you need both.

The lab test is PageSpeed Insights. Put in your homepage and your busiest service page, and read the mobile tab. The mobile results are throttled to simulate a mid-range phone on a slower connection, which is why they look so much worse than you expect. That is not the tool being unfair, that is your site.

The field test is you, outside, on your phone with wifi turned off, in a private browsing window so nothing is cached. Count out loud from the moment you tap the link. If you get past three before you can read your own headline, you have a problem that no amount of design work will fix.

Do the field test on the pages your money arrives through, which usually means the service page your ads or your Google Business Profile point at rather than your homepage.

Images are almost always the biggest offender#

On the small business sites I look at, image weight is the single most common cause of slow loading, and it is also the cheapest to fix.

The usual pattern is photos uploaded straight from a phone or a camera at full resolution. A single job photo can be four or five megabytes when the page needs it at a fraction of that size. Stack six of those on a homepage and the page is carrying more weight than a small application.

The fix takes an afternoon. Resize images to the largest size they are ever displayed at, export them in a modern format like WebP, and turn on lazy loading so images below the fold do not download until someone scrolls to them. Most website platforms have a setting or a plugin for all of this, and the difference on a mobile connection is immediate.

While you are there, check for a hero video. Background videos on a homepage look impressive on a desktop and are close to hostile on mobile data.

Third-party scripts are the sneaky one#

The other common cause is everything you have bolted on over the years. Analytics, a heatmap tool from a marketing experiment two years ago, a review widget, a chat widget, two different tracking pixels from campaigns that ended.

Each one is a request to somebody else's server, and your page waits on servers you do not control. Worse, these accumulate invisibly because nobody ever removes one.

Open your site with the browser developer tools network tab, or look at the PageSpeed report, and list every external domain your page loads from. Then justify each one. Anything connected to a campaign that has finished, or a tool nobody has logged into this year, comes off.

This matters when you are adding functionality too. A chat widget earns its weight if it produces enquiries, and does not if it was installed and forgotten. When you add one, configure it properly and measure it from day one, which is the point of the setup steps in adding AI chat to your website.

Hosting sets the floor#

If the server takes a long time to send the first byte, nothing you do to the page fixes it. Cheap shared hosting with hundreds of sites on the same machine, or a server sitting overseas serving mostly New Zealand visitors, both show up as a slow initial response in PageSpeed Insights.

Moving to better hosting, or putting a content delivery network in front of the site so pages are served from somewhere closer to the visitor, is usually a modest monthly cost. It also tends to be the fix that requires a developer, which is why I put it after images and scripts rather than before.

Get the hosting cost into your comparison when you are quoting a new site, because it is one of the ongoing fees that quietly separates two builds that looked the same on paper. There is a breakdown of those in what a business website costs in New Zealand.

The order to work in#

1. Compress and resize every image, and enable lazy loading. Cheapest fix, biggest effect.
2. Remove third-party scripts you cannot justify.
3. Check your hosting response time and upgrade or add a CDN if it is poor.
4. Only then look at code-level work like deferring scripts and trimming unused CSS.

Speed is a floor rather than a strategy. A fast site that does not say what you do or what it costs still will not produce enquiries, and once you have the load time under control the next constraints are the ones in why your website gets traffic and no enquiries.

Run PageSpeed Insights on your two most important pages today, write down the mobile numbers, then do the standing-outside test. Fix the images this week and run both tests again. If the site is still slow after that, you have narrowed the cause to something a developer can find quickly, and you will know it is worth paying for. If you are weighing up a rebuild off the back of it, the wider case for what the site should be doing is in what makes a website smart.