Quick answer
Test your home page and one key service or product page in PageSpeed Insights on the mobile setting, then run GTmetrix. Most slow small business sites come down to overloaded or distant hosting, oversized images, too many plugins or page-builder add-ons, and third-party scripts such as chat widgets. Fix the biggest item the report flags first.
Slow pages cost you enquiries before anyone reads a word. This guide shows you how to test your site properly, what each common cause looks like, and when patching stops making sense. It is part of our Website help centre.
Check these first
- Run PageSpeed Insights on mobile. Go to pagespeed.web.dev, paste your page address and click Analyze. It opens on the Mobile tab. Look at the top section first: that is field data from real Chrome users over the last 28 days. The score further down is a lab test, useful for finding causes.
- Read the Core Web Vitals result. If the field data says "Failed", note which metric is red: LCP (loading), INP (responsiveness) or CLS (layout jumping). That tells you where to look.
- Run GTmetrix. At gtmetrix.com, test the same page and open the Waterfall tab. If your plan lets you pick a test location, choose the one nearest your customers.
- Check the first bar in the waterfall. The first request is your server building the page. If it takes more than about a second before anything else starts, hosting or a heavy plugin is the likely cause, not images.
- Sort the waterfall by size. Any single image over 500 KB on a normal page is worth fixing. Hero images saved straight from a camera or stock site are the usual culprit.
- Count the outside scripts. In the waterfall, look for requests to other domains: chat widgets, booking tools, review badges, heatmaps, old tracking pixels. Each one adds work for the phone.
- Test logged out. If you are logged in to WordPress, the admin bar and uncached pages make it feel slower than visitors see. Use a private window.
Common causes and fixes
| What you see | What it means | How to fix it | How long it takes |
|---|---|---|---|
| Long blank pause before anything loads; slow first bar in GTmetrix | Slow server response: crowded shared hosting, no page caching, or a server far from Australia | Turn on page caching; move to better or Australian-based hosting; check resource limits in cPanel | 1 hour for caching; half a day to move host |
| "Improve image delivery" or "Properly size images" in PageSpeed Insights | Images are far larger than the space they fill on screen | Resize to the display size, convert to WebP or AVIF, lazy-load images below the fold | 1 to 3 hours for a small site |
| LCP over 2.5 seconds on mobile | The main hero image or heading arrives late | Compress the hero, preload it, and stop sliders or videos from loading first | 1 to 2 hours |
| "Reduce unused JavaScript" with many plugin or builder files | Every plugin and builder module loads its own code on every page | Remove plugins you do not use, disable unused builder widgets, load scripts only where needed | 2 to 6 hours |
| INP over 200 ms; taps and menus feel laggy | The phone is busy running scripts when someone taps | Delay chat, review and tracking scripts until interaction; drop duplicates | 1 to 4 hours |
| CLS over 0.1; text jumps as the page loads | Images, ads, banners or fonts load without reserved space | Set width and height on images, reserve space for banners, preload fonts | 1 to 2 hours |
| Fast on your office computer, slow on a phone | Your desktop and connection hide the problem | Always judge on the Mobile tab and real phones on 4G | Ongoing habit |
What "good" looks like
Google publishes the targets on web.dev. A page passes Core Web Vitals when, for at least 75% of visits, LCP is 2.5 seconds or less, INP is 200 milliseconds or less and CLS is 0.1 or less. These three numbers matter more than the 0 to 100 performance score, which can move between runs even when nothing on the page changed.
Google says Core Web Vitals are used by its ranking systems, but relevance still matters far more. A faster page will not outrank a better answer. The bigger win is usually conversions: people on phones leave slow pages before the form or phone number appears.
Fixes by platform
WordPress
- Install one caching plugin, not two. Many hosts include server-level caching; check before adding another layer.
- Go to Plugins and deactivate anything you cannot name a reason for. Delete it once the site still works.
- Page builders add weight. If every page uses dozens of builder widgets, a lighter theme often beats any amount of tuning.
- Update PHP to a currently supported version in your hosting control panel (in cPanel, MultiPHP Manager), after taking a backup.
- For the interaction side of speed, see our guide to Core Web Vitals and INP on WordPress.
Shopify
Hosting is handled for you, so slowness usually comes from apps and the theme. Uninstalled apps can leave code behind in theme files. Check the theme for leftover app snippets, remove apps you no longer use, and compress large banner images before uploading.
Wix and Squarespace
You cannot change the server, so focus on what you control: image file sizes, the number of embedded widgets and videos, and animations on the home page. Remove sections nobody uses.
Australian detail: where your site is hosted
Many cheap hosting plans run on servers in the United States or Europe. Every request from a phone in Brisbane then travels across the world and back, which adds delay before the page even starts. If your customers are in Australia, hosting in Australia or using a CDN with Australian locations removes much of that wait. You can see where your server is with an IP lookup on your domain. We host client sites on our own Australian server for this reason.
Also check your hosting plan's resource limits. In cPanel, the Resource Usage page shows whether your account has been hitting its CPU or memory ceiling. If it has, the host is slowing your site down on purpose.
When a rebuild is cheaper than patching
Speed work has a ceiling. If the theme loads several sliders, three font families and a builder on every page, you can spend hours trimming and still fail on mobile. A rebuild is often the better spend when:
- the site has not had a theme or plugin update in years, and updates break things;
- the field data still fails after caching, image work and plugin clean-up;
- you also need new content or a better enquiry flow, so the work overlaps.
If you are weighing up platforms at the same time, read WordPress vs Shopify vs Wix for Australian businesses. And if your ads send clicks to a slow page, check why Facebook ads get clicks but no sales, as speed is one of the first things to look at.
When to get help
A specialist will look at server response times, what each plugin and script costs, and the field data trend, then fix in order of impact rather than chasing a score. If you have tried caching and image fixes and the mobile result has not moved, it is time for a second pair of eyes.
Talk to us about website speed
About this guide
Written by Amann Jhamb, Director of AR Digital Solutions, 17 years in web design, SEO and paid ads. Last checked: 3 November 2026 against web.dev: Web Vitals. Change note: first published 3 November 2026. Part of our Website help centre.