Why your website is slow — and the fixes that actually work
The common reasons small-business sites load slowly — images, render-blocking code, hosting, caching, third-party scripts — each with a free way to confirm it and a plain fix.
Most slow small-business sites are slow for one of a short list of reasons, and a free speed test points straight at yours:
- Oversized images — the single most common cause.
- Render-blocking CSS and JavaScript — files that must load before anything appears.
- Slow hosting — a server that is slow to respond before the page even draws.
- No caching or compression, and too many third-party scripts — each adds avoidable weight.
Every one has a free way to confirm it and a plain fix, and most sites only have two or three. Run Google PageSpeed Insights on your busiest page — the cause is usually at the top of the opportunities list.
Most slow small-business websites are slow for one of a short, predictable list of reasons: oversized images, render-blocking CSS and JavaScript, sluggish hosting, missing caching or compression, too many third-party scripts, or serving everything from a single distant server with no CDN. The encouraging part is that every one of these has a free way to confirm it and a plain fix, and most sites only suffer from two or three. The fastest way to find yours is to run Google PageSpeed Insights on your busiest page — the cause is usually sitting right at the top of the opportunities list. This guide walks through each common culprit, how to confirm it is the problem on your site, and what to actually do about it, in plain terms a non-developer can act on or hand to whoever maintains the site.
First, measure — don't guess
Before changing anything, get a real reading. Open PageSpeed Insights, paste in the URL of your busiest page (often a services or product page, not the homepage), and read the mobile results first — that is how most people visit and how Google ranks. You will get a score, your Core Web Vitals, and a prioritised list of "Opportunities" and "Diagnostics". That list is your map for everything below. If you want a deeper lab report, press F12 in Chrome on any page and run the Lighthouse tab — it is the same engine.
Keep one thing in mind as you read: a low mobile score next to a high desktop score is completely normal. The mobile test uses a deliberately modest phone and a throttled connection on purpose. Don't be reassured by a green desktop number.
The six common causes — and the fix for each
1. Oversized images
This is the single most common cause of a slow small-business site, full stop.
How to confirm it: look for "Properly size images" or "Efficiently encode images" in your PageSpeed report. If they are there, you have oversized images.
What is happening: a photo straight off a phone or a stock library can be 3000 to 5000 pixels wide and several megabytes, displayed in a slot a few hundred pixels across. The browser downloads the entire giant file and then shrinks it on screen — your visitor pays for the full download, then their device does the resizing work.
The fix: resize images to roughly the dimensions they actually display before you upload them, and save them as WebP, which is typically 25 to 35% smaller than JPEG at the same quality and supported in every current browser. Most page builders and image plugins can do both automatically once you turn the setting on. This is frequently the biggest single speed win available, and you usually don't need a developer for it.
2. Render-blocking CSS and JavaScript
How to confirm it: look for "Eliminate render-blocking resources" in the report.
What is happening: certain stylesheet and script files have to be downloaded and processed before the browser can draw anything at all. While it waits on them, your visitor stares at a blank screen. This directly hurts how long until the first content appears (First Contentful Paint) and, by extension, your Largest Contentful Paint.
The fix: this one is usually a developer or theme-settings job. The standard moves are to load only the critical styles up front and defer the rest, and to add the defer or async attribute to scripts that don't need to run immediately. It is a well-documented, well-understood fix — ask your developer to "defer non-critical CSS and JavaScript" and they will know exactly what you mean.
3. Slow hosting (high Time to First Byte)
How to confirm it: check the Time to First Byte figure — Google's threshold for a responsive server is under 0.8 seconds. A high number here means the problem is underneath everything else.
What is happening: Time to First Byte is how long the server takes to even start sending the page after the browser asks for it. Cheap or overloaded shared hosting, a server physically far from your visitors, or a slow database choked by too many plugins all push this up. And because nothing can be drawn until the first byte arrives, a slow server makes every other metric slow too.
The fix: this is an infrastructure fix, not a code one. Options, roughly in order of effort: enable your host's caching, move to better hosting, or put a CDN in front of your origin (see below). If your Time to First Byte is high, no amount of image-tweaking will make the page feel fast — start here.
4. No caching or compression
How to confirm it: look for "Serve static assets with an efficient cache policy" and "Enable text compression" in the report.
What is happening: without caching, every visitor — including ones who were on your site yesterday — re-downloads your logo, stylesheets and scripts from scratch every single time. Without text compression, your HTML, CSS and JavaScript travel as full-size files instead of being squeezed down before sending.
The fix: both are one-time server settings. Set a long cache lifetime on files that rarely change (images, fonts, compiled CSS and JavaScript) so returning visitors reuse their local copies. Turn on text compression — gzip is the universal standard and typically cuts text files by around 70%, while Brotli is slightly more efficient and equally well supported. Both are usually a simple toggle on your host or CDN, they are invisible to visitors, and they shrink every page you serve.
5. Too many third-party scripts
How to confirm it: in the PageSpeed report, look at the "Reduce the impact of third-party code" section, which lists exactly what is loading and how much each costs you.
What is happening: every chat widget, analytics tag, tracking pixel and ad script is code loaded from someone else's server that runs on your visitor's device. Chat widgets are among the heaviest, often dragging in their own frameworks and fonts. Tag managers are sneaky — one tag manager can quietly load a dozen scripts you have long forgotten about. Collectively these are the main cause of a sluggish, unresponsive feel (poor Interaction to Next Paint), where the page has loaded but freezes every time you tap.
The fix: audit what is actually loading and delete anything you are not using right now — the campaign pixel from last year, the second analytics tool, the chat widget you turned off. For what remains, defer it so it loads after the page is usable. Every script you remove is a guaranteed gain, so be ruthless.
6. No CDN
How to confirm it: there is no single warning for this, but a high Time to First Byte combined with visitors spread across the country (or a server hosted overseas) points to it.
What is happening: without a CDN, every visitor is served from one origin server wherever it happens to live. Someone in Perth loading a site hosted in Sydney — or worse, overseas — waits for every file to make the full trip.
The fix: a content delivery network keeps copies of your site on servers around the world (and around Australia), so files are served from one near the visitor. That lowers Time to First Byte, absorbs traffic spikes, and often bundles caching and basic security too. If your whole audience is in one city and your hosting is local, the gain is modest. But if you sell nationally or your server is overseas, a free-tier CDN like Cloudflare is one of the better speed investments you can make.
Put it in order
You don't have to do everything, and you shouldn't try to all at once. Work in this order, re-testing in PageSpeed Insights after each change so you can see the effect:
- Images first — biggest win, usually no developer needed.
- Caching and compression — quick server toggles, set-and-forget.
- Third-party scripts — delete what you don't use.
- Hosting and CDN — if Time to First Byte is still high.
- Render-blocking resources — hand this one to your developer.
Most small-business sites only have a few of these problems, and fixing the top two or three moves the score — and the actual experience — dramatically. Speed isn't only a ranking signal, either; a faster site loses fewer enquiries and sales, so the payoff is bigger than search alone.
For plain-English explanations of any specific warning you run into, Google's web.dev guides are the authority, and our Improve hub gathers short answers to the questions that come up. If you'd rather browse those one at a time, the free questions library is the place to start.