Why is your small business website slow?

Your website is almost certainly slow for one of 4 reasons - oversized images, too many third-party scripts, slow hosting, or no caching - and the fix is usually changing a setting or compressing a file, not rebuilding the site. This page is the plain-English layer you read after running a free speed test: it turns a confusing report full of red bars into a short list of things to actually do, and tells you which of them are yours to fix and which belong to your developer or your host.

We will say this plainly up front, because it shapes everything below: the tools that measure website speed - Google's PageSpeed Insights, GTmetrix and the rest - are excellent and free, and we are not trying to replace them. Run the tool first. Then come back here when the result is a wall of numbers you do not recognise. That is the gap this page fills.

Why small-business websites are slow

A slow site almost never has an exotic cause. At 1-30 staff, it is nearly always one of the same 4 culprits, often more than one at once.

Oversized images. This is the single most common cause, by a distance. Someone uploaded a photo straight off a phone or a stock site - 4,000 pixels wide, 6 megabytes - and the page now ships that full file to every visitor's phone, where it is displayed 400 pixels wide. The browser downloads the whole thing and then shrinks it. A site with 8 hero and gallery images like this can be carrying 30 megabytes of pictures it does not need. The fix is properly sizing images - exporting them at the dimensions they are actually shown - and image lazy loading so the ones below the fold do not load until someone scrolls to them. Neither requires a rebuild; both are routine.

Too many third-party scripts and plugins. Every chat widget, analytics tag, booking embed, cookie banner, font loader and "social proof" popup is code loaded from someone else's server, and your page often waits for all of it before it finishes. On a WordPress site this usually arrives as plugins - 30 of them, each adding its own scripts, half of them no longer used. The page is not slow because it is complicated; it is slow because it is fetching a dozen things from a dozen places before it lets the visitor read anything.

Slow hosting. Before your site can show anything at all, the visitor's browser asks your server for the page and waits for the first byte to come back. That wait is Time To First Byte, and on cheap shared hosting - where your site sits on one overloaded machine alongside hundreds of others - it can be a second or more before the server even starts replying. No amount of image compression fixes a slow TTFB, because the delay happens before the images are even requested. This is the cause owners most often miss, because it is invisible in the page itself.

No caching or CDN. Without browser caching, a returning visitor re-downloads your logo, fonts and stylesheets on every visit instead of reusing the copy already on their device. And without a CDN - a network of servers around the world that keep copies of your files close to visitors - someone loading your Brisbane business's site is pulling every file from wherever your single server physically lives, which might be Sydney, might be Texas. Both are settings-and-configuration fixes, not code rewrites.

What to check yourself

You do not need to guess which of those 4 causes is yours. A free test will tell you in about a minute. Open PageSpeed Insights, type in your address, and read the Mobile tab - not Desktop, because most of your visitors are on phones and the mobile result is always the harsher, truer one. Our plain-English guide to running it (and the other free tools) is how to test website speed free.

The report will throw a lot at you. Ignore most of it. There are 2-3 numbers that matter:

Largest Contentful Paint (LCP). How long until the biggest thing on screen - usually your hero image or headline - appears. Google calls under 2.5 seconds "good". If yours is well above that, this is your headline problem, and the cause is almost always oversized images or slow hosting.

The overall Performance score (the big circle). Green (90+) is good, orange (50-89) is "needs work", red (under 50) means visitors are leaving. This score is produced by Lighthouse, the engine inside PageSpeed Insights - knowing the name helps when a developer mentions it.

Time To First Byte, shown lower down. If this is high - over about 0.8 seconds - the problem is your hosting, and no amount of image work will fix it. This single number is the fastest way to separate a hosting problem from a code problem, which is the most useful distinction this whole page contains.

Read those three, and you have gone from a confusing report to a diagnosis: a high LCP with a low TTFB means images and scripts (fixable on the site); a high TTFB means hosting (a different conversation, below).

What to ask your developer

If someone built your site or maintains it, you do not need to learn how to fix any of this - you need to ask the right four questions so the answers are specific and you can tell whether they landed. Send them your PageSpeed Insights link and these:

• "Can you compress and correctly size the images on the homepage and main landing pages?" This is the highest-impact, lowest-effort fix, and there is no good reason to decline it.
• "Are we lazy-loading images below the fold?" If the answer is no, it is usually a single setting or plugin.
• "Can we turn on browser caching and a CDN?" Many hosts include both - Cloudflare's free tier is the common answer - and it is a configuration job, not development.
• "What's our Time To First Byte, and is it the hosting?" This is the question that flushes out whether the real problem is something they can fix in the code at all.

A good developer will give you a concrete answer and a rough number of hours. Be wary of anyone who responds to a slow-site report by quoting you a full rebuild - that is occasionally the honest answer, but far more often the slow site just needs its images compressed and caching switched on. The walkthrough we point our own readers to first is why our own first speed walkthrough, which covers what a reasonable fix list looks like.

When speed is a hosting problem, not a code problem

This is the distinction that saves the most wasted effort, so it gets its own section. Image compression, caching and trimming scripts all happen in the website. But if your Time To First Byte is high, the delay is happening before the website does anything - at the server, before a single image is even requested. You can compress every photo to nothing and the page will still crawl, because the visitor is waiting on a slow machine to start replying.

You can spot this yourself: a PageSpeed result with a poor score but a low TTFB is a site problem (fixable by your developer); a poor score with a high TTFB is a hosting problem. The fix for a hosting problem is not code - it is moving to a faster host, or a better plan with your current one. The cheapest shared-hosting tiers are the usual offenders, because your site is sharing one server with hundreds of others. A CDN can partly mask a slow host by serving cached copies of your static files from elsewhere, which is one more reason it is worth turning on, but it does not fix a slow server for the pages that have to be freshly generated.

The practical move: if your TTFB is consistently above a second and your host's support cannot improve it, the answer is a different host, and that is a switch a competent developer or your new host's migration team handles routinely. It is not a rebuild of your site - the same files move to a faster machine.

When it's time to bring in outside help

For most small-business sites, speed is a half-day job for whoever maintains the site: compress the images, switch on caching and a CDN, remove the plugins you stopped using. You read the test, you hand over the four questions, it gets fixed. That is the common case, and it does not need a specialist.

Bring in outside help when one of three things is true. First, when you have run the test, sent the questions, and the numbers have not moved - that means the cause is deeper than the obvious four, and a performance-focused developer can profile it properly. Second, when the problem is structural: a site built on a bloated theme with 40 plugins sometimes really is faster to rebuild cleanly than to patch, and an honest developer will tell you when you have crossed that line. Third, when speed is costing you measurable money - an e-commerce site where a slow checkout is visibly losing carts justifies a proper performance engagement in a way a brochure site does not. Google's own web.dev performance guide is the reference these specialists work from, and it is free to read if you want to understand what they will be doing.

The thing to avoid is paying for a specialist before you have run the free test and tried the obvious fixes. The median site at grade D does not have a hard problem - it has uncompressed images and no caching, and that is a settings change, not a project.

What we don't do

We measure and explain the public speed signal - we do not rebuild or re-host your site. When you run a scan, the Speed category reports the same outside-visible numbers a tool like PageSpeed Insights surfaces - your mobile LCP, your performance grade, your Time To First Byte - and scores them against the Australian small business baseline so you can see whether your site is ahead of or behind its peers, continuously, rather than the one time you happened to run a test. That is the layer we add: the plain-English reading and the tracking-over-time, sitting on top of the same measurement the free tools provide.

What we do not do is the fixing. We do not compress your images, write your caching rules, install a CDN, or move you to a faster host - that is your developer's job, or your host's, and the four questions above are how you get it done. We are not a web-performance agency and this is not a pitch dressed as one. If speed is hurting more than your patience - if you are wondering whether it is dragging your Google ranking down - that is a related but separate question, covered in whether speed is hurting your Google ranking. Our role stops at telling you, clearly and on a schedule, exactly where your site stands.