Why Is My Website Slow? (And How to Fix It)
Slow sites lose enquiries, and the cause is almost never mysterious. Here are the ten things that actually make Australian small business websites crawl, ranked by how often each one turns out to be the real problem, with a way to check each and a realistic fix.
Most slow small business websites in Australia are slow for the same short list of reasons: huge uncompressed images, oversubscribed shared hosting, a pile of plugins doing overlapping jobs, a heavy multipurpose theme, and no caching. Images are the culprit more often than everything else put together. Aim for your main content appearing within 2.5 seconds on a mid range phone, not a perfect score.
The rest of this page is about working out which of those is true for your site.
We have been maintaining WordPress sites for Australian businesses since 2004 and the pattern barely shifts. Someone runs a speed test, sees a red number, panics, and installs three optimisation plugins. The site gets slower. The real problem was a 6MB hero image sitting on a $4 a month hosting plan.
What are the most common causes of a slow website?
Ten things cause nearly every slow site we see. The order reflects how often each is the real bottleneck, not how often it gets talked about online. Fixing number seven while ignoring number one is how people lose a weekend and gain nothing.
| Cause | How to check it | Typical fix | Difficulty |
|---|---|---|---|
| Oversized, uncompressed images | Open the page in Chrome, press F12, go to the Network tab, reload, sort by size. Anything over 300KB is suspect | Resize to the width it actually displays at, convert to WebP, compress, lazy load anything below the fold | Easy |
| Cheap oversubscribed shared hosting | Look at time to first byte in PageSpeed Insights. Over 600ms with caching already on points at the server, not the site | Move to a host that caps how many accounts share a machine | Easy for you, the host does the work |
| Too many plugins, several doing the same job | List your active plugins. Look for two caching plugins, two SEO plugins, two form plugins, two slider plugins | Consolidate down to one of each, delete the losers, and remove deactivated ones entirely | Moderate |
| Bloated multipurpose theme | Check the theme name under Appearance. Avada, Divi, BeTheme and similar load a large framework on every single page | Optimise around it, or rebuild on a lighter base like Hello Elementor or GeneratePress | Hard |
| No caching | Load a page twice and watch the second load. If there is no caching plugin and your host does not cache at server level, every visit rebuilds the page from scratch | Server level caching where available, otherwise WP Rocket or LiteSpeed Cache | Easy |
| No CDN for interstate and overseas visitors | Run a speed test from Perth, then from Singapore. If the gap is large, distance is costing you | Put the site behind Cloudflare, the free plan covers most small business needs | Easy |
| Render blocking CSS and JavaScript | PageSpeed Insights flags it directly as render blocking resources, with the file names | Defer non critical JavaScript, inline the CSS needed for the top of the page, load fonts with font-display swap | Moderate |
| Third party scripts | In the Network tab, count requests going to domains that are not yours. Chat widgets, tracking, review embeds, ad pixels | Delete what nobody uses, delay the rest until the visitor interacts with the page | Easy to moderate |
| Unoptimised database | Check post revision count and autoloaded options size. Autoloaded data over 1MB is a genuine drag | Clear old revisions and expired transients, cap revisions in wp-config.php, drop orphaned tables from removed plugins | Moderate |
| Old PHP version | WordPress admin, Tools then Site Health. It will tell you outright | Test on staging, then ask your host to move you to PHP 8.2 or 8.3 | Easy |
Why are images almost always the first thing to check?
Because a photo off a phone or a stock library is usually 3000 to 6000 pixels wide and weighs between 2MB and 8MB. Your page displays it at maybe 800 pixels. The browser still downloads the whole file. Put four on a home page and you have asked a customer on patchy mobile reception to pull down 20MB before they see anything useful.
The fix is boring and it works. Resize to roughly the width it displays at, convert to WebP, compress at around 80 per cent quality. A 4MB tradie job photo routinely comes out at 150KB to 250KB with no visible difference on a phone. ShortPixel, Imagify and Smush do this in bulk across an existing media library for a few dollars a month.
Two catches. WordPress lazy loads images by default now, but exclude the hero image, because delaying the one picture the visitor is waiting on makes the page feel slower even while the score improves. And background images set inside a page builder often skip optimisation plugins entirely, so check those by hand.
Is my hosting the problem, or is it my website?
Time to first byte tells you: how long the server takes to send the first scrap of the page. Above 600ms consistently, with caching already switched on, the server is your bottleneck. Under 300ms and the page still feels slow, the problem is what you are sending, not where it comes from.
Hosting at $3 to $8 a month exists because hundreds of accounts share one machine. When somebody else on that box gets hammered by a bot at 2pm on a Tuesday, your site slows down and you never find out why. The tell is inconsistency: fine in the morning, sluggish at lunch, the admin taking eight seconds to save a page.
Properly resourced hosting for a small business WordPress site runs roughly $20 to $50 a month excluding GST, which is the range our Australian WordPress hosting plans sit in. Be honest about what that buys. Better hosting fixes server response time and nothing else; a 6MB image is still 6MB on a fast server.
How many plugins is too many?
The count is close to meaningless. Thirty five well built plugins will outrun twelve badly built ones every time. What matters is how much each loads, and whether it loads on pages where it does nothing.
What we find most often: two plugins doing the same job (a site running both WP Super Cache and W3 Total Cache, fighting each other), a slider plugin loading 400KB of JavaScript on every page when the slider only appears on the home page, and contact form assets loading site wide for a form that exists once.
To test, copy the site to staging and deactivate one plugin at a time, measuring as you go. Never on the live site during business hours; we have watched someone deactivate a plugin at 11am and take the booking form down until close.
Deactivated plugins are not harmless. The code still sits on the server and can still be exploited if it carries a known vulnerability, so it does nothing for speed and something bad for security. Not using it? Delete it, and keep a note of the name.
What are Core Web Vitals and what should I aim for?
Three measurements Google takes from real Chrome users. In plain terms: how long until the main thing appears, how fast the page reacts when you tap it, and how much the layout jumps about while loading.
- LCP (Largest Contentful Paint) is the time until the biggest visible element, usually your hero image or main heading, is drawn. Target under 2.5 seconds. Hosting and images control this one.
- INP (Interaction to Next Paint) measures the delay between someone tapping a button and the screen responding. Under 200 milliseconds. Heavy JavaScript is the usual cause.
- CLS (Cumulative Layout Shift) scores how much content jumps about while the page loads. Under 0.1. Late loading fonts and images with no width and height attributes are the usual offenders.
Google uses the 75th percentile of real visits over a rolling 28 day window, so three quarters of your visitors need to hit those numbers and any improvement takes weeks to show in Search Console. Low traffic sites often have no field data at all, so you are reading a simulation instead.
Do I need a CDN if all my customers are in Australia?
Usually yes, though not for the reason most people assume. A visitor in Perth loading a site hosted in Sydney pays roughly 50 milliseconds each way on every single file requested. Multiply that by 60 or 70 requests. Add anyone in Auckland, Singapore or the UK and it gets worse fast.
A CDN keeps copies of your images, CSS and JavaScript on servers worldwide and serves each visitor from the nearest one. Cloudflare’s free plan covers most small business sites and brings bot filtering with it, which quietly reduces server load. If your whole audience sits in one city and your host is there too, the gain is modest. Take the free plan anyway.
What about chat widgets, tracking and other third party scripts?
Every one is a request to somebody else’s server, and their bad day becomes yours. A live chat widget commonly weighs 300KB to over 1MB. Add a Meta pixel, a Tag Manager container carrying fifteen tags nobody has audited since 2021, a review embed and a heat mapping script, and a real slice of your load time now belongs to companies with no interest in your page speed.
The audit is a business question, not a technical one. Does anyone actually answer that chat widget? If not, delete it. What survives can usually be delayed until the visitor scrolls or taps, a checkbox in most caching plugins. Nobody needs the chat bubble in the first two seconds.
Does an old database or PHP version really matter?
Both matter and both are cheap to fix. A site running since 2016 will be storing forty revisions of every page, expired transients nobody cleaned up, and leftover tables from long removed plugins. None of that is fatal alone. What does hurt is the autoloaded options table, because WordPress loads it on every single request; past about 1MB you feel it everywhere.
PHP is the easier win. Plenty of Australian small business sites still run PHP 7.4, which stopped getting security updates in 2022. Moving to 8.2 or 8.3 often cuts server processing time by 20 to 30 per cent on pages that are not cached. Test on staging first, because an old plugin can break, then have your host make the switch.
Why is a perfect PageSpeed score not the goal?
Because the score is a weighted lab simulation, run on a throttled mid tier phone at one moment in time. It is a diagnostic, not a report card. We regularly see one site score 92 and another 68, where the 68 feels faster to a real customer because its hero image appears instantly and the 92 is efficiently loading nothing useful.
Chasing 100 also breaks things. Deferring the JavaScript your booking form needs, inlining CSS that falls apart on an iPhone, removing jQuery because a tool said to: we have cleaned up all three.
What matters is whether a customer on 4G outside your shopfront sees your phone number and can tap it within a few seconds. Get Core Web Vitals into green in Search Console, get LCP comfortably under 2.5 seconds, then stop and go do something that earns money. Treat any promise that faster loading will lift your rankings by a specific amount with suspicion, because nobody can guarantee that. Speed is a tie breaker between comparable pages, not a lever you pull for positions.
What order should I fix things in?
Work top down and measure after each step, otherwise you will never know what helped.
- Compress and resize every image over 300KB. Half the sites we look at are effectively finished here.
- Turn on caching, at server level if your host offers it.
- Check time to first byte. Still poor, and the hosting is your problem; no amount of tinkering with the site will fix it.
- Delete plugins nobody uses and consolidate anything duplicated.
- Put Cloudflare in front of the site.
- Audit third party scripts and delay what survives.
- Update PHP and clean the database.
- Only then look at render blocking CSS and JavaScript, which is fiddly and returns the least of the lot.
If you would rather not spend your Sunday on it, that list is standard work for us and comes bundled with our managed hosting and maintenance. No lock in contract either way.
Rule of thumb we use: if a site swallows more than about six hours of optimisation and still cannot get under three seconds, the build itself is the problem and a rebuild on a lighter foundation works out cheaper over two years. More on this across our WordPress and hosting guides.
Common questions
How fast should my website actually load?
On a mid range phone over 4G, aim for the main content being visible in under 2.5 seconds and the page being usable within about 3. Under 2 seconds is excellent and rarely necessary for a small business site. Above 4 seconds you are losing enquiries, particularly on mobile where people bail out fast and go back to the search results.
My site is fast on my computer but slow on my phone. Why?
Two reasons. Your computer is on fixed broadband with a browser that has already cached the site, so you are not seeing a first visit. And phones have far less processing power, so the JavaScript your desktop chews through instantly takes several times longer. Always test in an incognito window, and use the mobile tab in PageSpeed Insights rather than the desktop one.
Will a faster website improve my Google rankings?
It helps, but less than most people are told. Page experience is a ranking signal, and it works mainly as a tie breaker between pages of similar relevance and quality. A fast page with weak content will not outrank a slower page that answers the question better. Where speed genuinely pays is conversion: fewer people give up before your page finishes loading.
Should I trust PageSpeed Insights or GTmetrix?
Use both, for different things. PageSpeed Insights includes field data from real Chrome users, which is what Google actually uses, so treat that section as the truth. GTmetrix gives you a clearer waterfall chart for finding which specific file is holding things up. Ignore the difference between their scores; they weight things differently and neither is the target anyway.
Can two caching plugins conflict with each other?
Yes, and it is one of the more common self inflicted slowdowns we find. Two caching plugins will fight over the same files, serve stale pages, and sometimes break the site in ways that only show up for logged out visitors, so the owner never sees it. Run one only. If your host caches at server level, you often need no caching plugin at all.
Is it cheaper to fix a slow site or rebuild it?
Fixing is cheaper if the foundation is sound: expect a few hundred dollars of work excluding GST for images, caching and a plugin cleanup. Rebuilding makes more sense when the site runs a heavy multipurpose theme stacked with add ons, because every optimisation is fighting the build itself. Get someone to look before you decide, since the answer is obvious within about twenty minutes.
Want to know what is actually slowing your site down?
Send us your URL. We will run it properly, tell you the two or three things that are really costing you time, and be straight about whether it is worth paying anyone to fix. Australian based, WordPress specialists since 2004, no lock in contracts.