Is Your Website Too Slow? A Plain-English Speed Audit for Small Businesses

You don't need to be technical to know your website feels slow, you can tell when you tap your own menu link on your phone and the screen sits blank for a bit too long. What's harder, or what most people assume is harder, is proving it, finding out why, and deciding whether it's worth fixing.

This one is a practical how-to. In about ten minutes, using two free Google tools and the phone already in your pocket, you can run a proper speed audit of your own site and read the results without anyone translating for you. We've written elsewhere about how speed moves money, so if you want the revenue evidence and the case studies, that's in our piece on Core Web Vitals and revenue. Here we'll skip going over all that again and just show you how to check.

First, why a second actually costs you

A quick reminder first, then we'll get on with it. Google's research has long held that 53% of mobile visits are abandoned if a page takes longer than three seconds to load (Think with Google). For a hungry person on the bus searching "Sunday roast near me", three seconds of blank screen is all it takes for them to back out and tap the pub above you instead. They never see your menu, your hours or your booking button, and you never know they were there.

Even a small gain in speed can make a real difference to your takings. Deloitte's "Milliseconds Make Millions" study, run with Google across 37 brands and 30 million sessions, found that a 0.1-second improvement in mobile load time lifted retail conversions by 8.4% and average order value by 9.2%, with travel conversions up 10.1% (Deloitte). So even a tenth of a second is worth chasing, which brings us to your own site.

Step one: the ten-minute Google test

Open a browser and go to pagespeed.web.dev. This is PageSpeed Insights, Google's own free tool. Type in your website address and press Analyze. When the results appear, make sure the Mobile tab is selected at the top, not Desktop. Most of your customers are on a phone, so that's the test that counts.

The screen will throw a lot at you, but you can ignore most of it. There are only two areas worth your attention, and the tool often confuses owners by mixing them up.

Field data versus lab data

Near the top, if your site gets enough traffic, you'll see a panel that says something like "Discover what your real users are experiencing." That's field data: anonymised numbers from people who actually visited your site over the last 28 days, on their own phones and their own networks (Google for Developers). This tells you whether real customers have a problem.

Lower down sits a big number out of 100, with a coloured ring around it. That's lab data: a single simulated test run on a mid-tier phone over a 4G connection (Google for Developers). It didn't happen to a real person, so treat it as a diagnostic that helps explain why your site is slow.

Field data tells you if there's a problem and lab data helps you work out the cause, so don't panic at a low score out of 100 if your field data is green, and don't relax at a high score if the field data is red.

The one number to read

In the field-data panel you'll see a few coloured bars. The one to look at is Largest Contentful Paint, usually shortened to LCP. In plain terms, it's the moment the biggest thing on the screen, almost always your hero photo, finishes loading and the page looks ready.

Google's thresholds are simple (web.dev):

• Under 2.5 seconds: good. A green bar. Leave it alone.
• 2.5 to 4.0 seconds: needs improvement. An amber bar. Worth a look.
• Over 4.0 seconds: poor. A red bar. This is costing you customers.

One detail tends to trip people up. The number is measured at the 75th percentile of real visits, which is a fancy way of saying Google takes the slowest quarter of your visitors and reports their experience. That's on purpose, because it reflects the people having the worst time, the ones most likely to give up, rather than flattering you with the customer on fast home broadband.

Write your LCP down, as that's your headline result.

Step two: the test PageSpeed can't do for you

Most people skip this next part, but it's the most realistic test you can do. Pick up your phone, turn off the wifi, and load your own website on mobile data while standing well away from your router.

This matters because it's how customers actually arrive, on the train, in a car park or walking down the high street. Ofcom's Connected Nations 2024 report found that while 99% of UK premises get outdoor 4G from at least one operator, only 94% of rural premises get it from all of them (Ofcom). If you run a country pub or a rural venue, a real chunk of your customers are browsing on a connection that's patchy at best, and a heavy site simply gives up on them.

Count the seconds out loud and watch what loads first and what makes you wait. Does the text show up quickly, or do you stare at a blank space where the headline should be? Does a big photo crawl in line by line? Does a chat bubble freeze everything for a second? You'll feel the problem before any tool names it, and that feeling is worth trusting, because your customers get the same one and they're under no obligation to wait it out.

Step three: the culprit checklist

So say your LCP is amber or red and the phone test backed that up. What's slowing it down? On a small business or hospitality site, it's almost always one of a handful of usual suspects. Below is how to spot each one, what it's costing you, and the plain-English fix to ask for.

Oversized photos (the number one offender)

Images are the single heaviest thing on a typical web page. In October 2024 the median mobile page weighed 2,311 KB, and images alone accounted for a median 900 KB of that, roughly 39% of the whole page (HTTP Archive Web Almanac). For a restaurant or salon, that's usually a giant hero photo and a gallery of thirty dishes, each one uploaded straight off a camera at full resolution.

How to spot it: in your PageSpeed results, look under "Opportunities" for lines like "Properly size images" or "Serve images in next-gen formats". If they're there, this is your problem.

This is also one of the cheapest fixes. Photos should be resized to the dimensions they actually display at and saved in a modern format like WebP. A 4 MB camera photo can become a 200 KB web photo with no visible difference. Sort this first, as on many sites it alone moves LCP from red into green.

A heavyweight page-builder theme

If someone built your site in WordPress using a "fancy template", it's very likely on a page builder like Divi or Elementor. These are handy for designers, but they're very hard on speed. Divi ships over 400 KB of framework code on every single page whether you use it or not, and can generate page structures of 800 to 1,200+ elements, where Google recommends staying under 1,500 (WP Pro Host). Typical unoptimised Elementor sites show a median mobile LCP between 3.8 and 5.2 seconds (WP Pro Host), which can put you in the red before you've added a single photo.

How to spot it: you probably can't from the outside, but your web person will know in seconds. If your site "is on a fancy template" and it's slow, this is a strong candidate. It's the hardest one to fully fix without a rebuild, so it's where the pay-someone conversation often starts.

Plugin sprawl and third-party scripts

Over the years, bits get bolted on, such as a reviews widget, a social feed, an analytics tag, a booking embed, or an ad pixel someone added for a campaign in 2021 and never removed. Each one loads code from another company's servers. Third-party scripts are collectively responsible for more than half of average page load time, the average page now carries 35 or more of them, and sites running five or more external scripts see a median 1.4-second increase in LCP (DebugBear).

How to spot it: think about what's bolted onto your homepage, because every embed, feed and pixel is a candidate. The fix is to go through them and remove anything that isn't earning its place.

The chat widget

This one gets its own section because owners love it, but it quietly slows the page down. DebugBear's testing found a single chat widget can outweigh the rest of a small page. Zendesk's widget downloads 533 KB and adds 991 milliseconds of processing, Intercom adds 301 KB and 514 milliseconds, and Tawk.to pulls in 749 KB, much of it a 500 KB graphic the widget doesn't even use (DebugBear).

How to spot it: do you have a "Chat with us" bubble in the corner? Think about whether anyone actually answers it, because if it sits unmanned, it's only costing you. Removing it, or setting it to load only after the rest of the page is ready, is a quick win.

Autoplay video and unoptimised fonts

There are two smaller ones to check as well. An autoplay background video in your hero section is enormous and almost never worth it on mobile, so swap it for a still image.

Then there are fonts. If your headings flash up blank for a second before the text appears, that's a font loading badly. It's called a flash of invisible text, and the fix is a one-line setting called font-display: swap, which tells the browser to show readable text in a backup font immediately and swap in your brand font when it's ready (Chrome for Developers). It's a small change with a visible payoff, and a good example of a fix worth asking a developer for by name.

When to stop fiddling and pay someone

You can do a fair bit of this yourself, especially if your site's on a platform with a settings panel. Resizing photos, deleting a dead chat widget, removing the reviews plugin nobody reads: that's a productive afternoon with no developer involved, and it might be all you need.

So when should you call someone? Stop and ring a developer when the fix has a technical name you'd have to look up, when it lives in the site's code rather than a settings screen, or when you've done the easy wins and your LCP is still red. That covers a font-display change, anything to do with how the page builder generates its code, server response time, or a rebuild off a bloated theme. There's no shame in that, and trying to hand-edit a WordPress theme file you don't understand is how small sites end up broken on a Saturday night.

When you do hire help, you're now the informed client, which is worth real money. You can hand over your PageSpeed report, point at the red LCP bar, and say "this is 4.6 seconds on mobile, the opportunities list flags oversized images and render-blocking scripts, and the hero text flashes blank, can you sort it and get me under 2.5." That's a clear brief that's easy to test, and you'll get a better job for less, because you've done the diagnosis and you can check the result yourself by re-running the same test.

Why this is worth your time

Every second your site makes someone wait, you're asking a customer to sit through the delay just to choose you, and most won't. The diner bounces before the menu loads, the enquiry never gets sent, and the table you'd have filled goes to the place that loaded first. None of that shows up in your books as a loss, which is why it can go unfixed for years.

Luckily, finding the problem doesn't need a developer. It takes ten minutes with a free Google tool and your own phone away from the wifi. You don't have to fix it all yourself, and for the deeper jobs you shouldn't, but it's well worth having a look so you know what you're dealing with. So why not run the test now, while it's fresh in your mind, and write down the LCP number you get back?

References

• Largest Contentful Paint (LCP), web.dev (Google)
• About PageSpeed Insights, Google for Developers
• Page Weight, Web Almanac 2024, HTTP Archive
• How Do Different Chat Widgets Impact Site Performance?, DebugBear
• How To Reduce The Impact Of Third-Party Code, DebugBear
• Milliseconds Make Millions, Deloitte with Google and 55
• Connected Nations UK Report 2024, Ofcom
• Mobile site speed importance, Think with Google
• Ensure text remains visible during webfont load, Chrome for Developers
• WordPress Page Builder Performance Compared, WP Pro Host
• Online booking systems for small businesses: what the data says, LibraBit