Digital · 6 min read
Why your website is slow, and why it costs you enquiries
Many small business websites take several seconds to become usable on a phone using mobile data. The people you most want to reach, the ones searching for you while out and about, are the ones who leave.
The cost is not theoretical
Someone who taps your site from a search result has already decided to consider you. If nothing has appeared after a few seconds, many of them go back and tap the next result. You never see it happen, and your analytics records it as a bounce with no explanation attached.
This is the quietest way a business loses work. There is no complaint, no bad review, no lost enquiry to follow up. The person simply went somewhere else.
Four causes, in the order they usually matter
1. Images straight from a phone or a stock site
A modern phone photo is four to eight megabytes. A website needs perhaps 200 kilobytes for the same picture on screen. If a page has six unoptimised images it is asking a visitor to download thirty megabytes to read a paragraph about your opening hours.
This is the single most common cause and the easiest to fix. Resize to the dimensions actually displayed, export as WebP, and the same page becomes ten times lighter with no visible difference.
2. The page builder
Drag and drop builders are convenient because they load a general purpose framework capable of rendering anything you might drag onto the canvas. Your five page brochure site pays for that flexibility on every single page load, usually in the form of several hundred kilobytes of JavaScript that runs before anything appears.
You are not obliged to rebuild. But it is worth knowing what the convenience costs, and it explains why two sites that look similar can perform very differently.
3. Plugins nobody uses
A typical WordPress site accumulates plugins the way a garage accumulates paint tins. A slider nobody scrolls, a form builder replaced two years ago, a social feed for an account you stopped posting to. Each one loads its own scripts and styles on every page, whether it appears there or not.
4. Tracking scripts
Analytics, a pixel, a heatmap tool, a chat widget, a cookie banner from a third party. Individually small, collectively often the largest single block of loading time, and each one is a request to someone else's server that your visitor waits on.
Keep the ones you actually read a report from. Remove the rest. Most businesses are running at least two they have never opened.
How to check yours in five minutes
Open PageSpeed Insights, enter your address, and read the mobile score rather than the desktop one. Desktop is measured on a fast connection and flatters almost everything.
The score itself matters less than the measures underneath it. Google wants the main content to appear within 2.5 seconds, and the page not to jump about while it loads. The next section explains what each number means.
What the three numbers mean
PageSpeed Insights reports Google's Core Web Vitals. These are three measures of how a page feels to a real visitor, each with a published target.
| Measure | What it tracks | Good | Poor |
|---|---|---|---|
| Largest Contentful Paint (LCP) | How long until the main image or block of text appears | 2.5 seconds or less | Over 4 seconds |
| Interaction to Next Paint (INP) | How quickly the page reacts when someone taps a button or opens a menu | 200 milliseconds or less | Over 500 milliseconds |
| Cumulative Layout Shift (CLS) | How much the page jumps about while it loads | 0.1 or less | Over 0.25 |
Anything in between is rated "needs improvement". CLS is a score, not a time. INP replaced an older measure, First Input Delay (FID), in March 2024, so any guide still talking about FID is out of date.
A page passes when each measure is "good" for at least three in every four visits.
Why your result changes every time you test
PageSpeed Insights shows two kinds of result, and they often disagree.
- Field data comes from real Chrome users who visited over the previous 28 days. It is the same data behind the Core Web Vitals report in Google Search Console, Google's free tool for site owners.
- Lab data is one simulated visit, run when you press the button. The score out of 100 comes from this test. It varies between runs, so use it to find problems, not to judge the site.
Many small sites do not get enough visitors for field data, so both tools report no real-user results. That is normal for a low-traffic site, not a fault. Work from the lab test and the list of issues beneath it.
If you do have field data, expect it to lag by about four weeks after a fix. In Search Console, "Start tracking" on the Core Web Vitals report begins a four-week check of the pages you fixed.
A one-afternoon checklist
- Test your home page and your busiest page on mobile. Screenshot the results so you have a "before".
- Note which measure is worst. Slow LCP usually points to large images or slow hosting. Poor CLS usually points to images, adverts or banners arriving late. Poor INP usually points to too much JavaScript, often from plugins and third-party scripts.
- Look for Time to First Byte (TTFB) in the field data, if you have any. It is how long your server takes to start replying. Google's guidance suggests 0.8 seconds or less. Much slower, and your hosting is part of the problem.
- Ask whoever built the site to confirm every image has its width and height set. Without them the browser cannot reserve space, and text jumps when the picture arrives.
- Make sure the main image at the top of the page is not lazy-loaded. Lazy loading waits until someone scrolls, which suits pictures further down and slows the first one they see.
- Swap embedded YouTube videos and Google Maps near the top of a page for a still image that links to them. Each embed loads another company's code, even if nobody presses play.
- Make one change at a time and retest, so you know what helped.
Three common questions
Will a faster site move me up Google?
Possibly, but do not expect miracles. Google says Core Web Vitals are used by its ranking systems. It also says it will still show the most relevant page even when the experience is poor. Speed helps a relevant page. It does not rescue an irrelevant one. The surer gain is the visitors you stop losing.
Do I need a score of 100?
No. Google's own guidance says chasing a perfect score for search reasons may not be the best use of your time. Aim for "good" on all three measures on mobile.
Do I need a new website?
Usually not at first. Images, plugins, embeds and scripts can all be fixed on your current site. A rebuild makes sense when the theme or page builder is itself the bottleneck, which shows when a nearly empty page still tests slowly. If you reach that point, our website design page explains how we approach one.
What we do about it
We hand-write the sites we build rather than assembling them from a page builder, which is mainly why they stay small. No framework loading on a brochure page, images sized to what is displayed, and no third party script unless it earns its place.
The aim is a page that appears in under two seconds on mobile data, which is the measure that matters most to whether someone stays long enough to contact you.
Website underselling you?
Tell us what your business does and who buys from you. We'll come back with a fixed price and a realistic timeline.