Why Is My Website Slow? A Diagnostic Guide for NZ Businesses

A slow website is not just irritating. It quietly costs you enquiries: visitors leave before the page finishes loading, and you never see the ones who left. This guide walks through diagnosing the cause properly, in the order that finds the problem fastest.

• Measure before you change anything - most "speed fixes" are applied to the wrong bottleneck.
• Oversized images are the single most common cause, and the cheapest to fix.
• Test on mobile over a real mobile connection, not on your office fibre.
• Google publishes exact thresholds for what counts as good. Use them instead of guessing.
• Some causes are cheap to fix; some mean the platform is the problem. Knowing which is the point of diagnosing.

Your own impression of your site is unreliable. You visit it constantly, so your browser has everything cached, and you are probably on good broadband. Your customer is on a phone, on mobile data, seeing the site for the first time.

Google measures three things, known as Core Web Vitals, and publishes precise thresholds for each. These are the numbers that matter, because they are also the ones used as a ranking signal.

Run your homepage and one service page through Google PageSpeed Insights, and look at the mobile tab first. If real-world field data is available for your site it appears at the top - trust that over the simulated lab score, because it reflects what actual visitors experienced.

This is the most common cause by a wide margin, and usually the easiest win. A photo straight off a phone or a stock library can be several megabytes and thousands of pixels wide, then displayed in a slot a few hundred pixels wide. The visitor downloads the whole thing anyway.

• Serve images at the size they are actually displayed, not the size they were shot.
• Use a modern format such as WebP or AVIF, which are substantially smaller than JPEG at equivalent quality.
• Load images below the fold lazily, so they do not compete with what the visitor can already see.
• Always set width and height so the browser reserves the space - this is usually what causes the page to jump around.

If the server takes a long time to send the first byte, nothing else you do can compensate: the browser is simply waiting. Two things commonly cause this. Oversubscribed budget shared hosting, where your site competes with hundreds of others on one machine. And physical distance, if your server sits in a data centre far from your customers.

For a New Zealand business serving New Zealand customers, hosting in or near the region helps, and a CDN that caches your content at edge locations helps more. If your time to first byte is consistently poor while everything else looks fine, hosting is your bottleneck.

On WordPress specifically, this accumulates invisibly. Each plugin can add its own stylesheets and scripts to every page, whether that page uses the plugin or not. Twenty-five plugins to run a five-page brochure site is common, and every one of them adds weight.

Page builders deserve a particular mention. They make editing easy and they generate deeply nested markup that is slow to render on mobile hardware. That is a real trade-off, not a reason to panic, but it is often the answer to "why is my site slow when it looks so simple".

Chat widgets, analytics, ad pixels, review embeds, booking widgets, font services. Each one is a request to someone else's server, and your page waits on their performance. Three or four of these stacked together will visibly slow a site, and they are frequently the cause of poor interaction responsiveness.

Audit them honestly. There is usually at least one tracking script installed for a campaign that ended two years ago.

Without caching, a database-driven site rebuilds every page from scratch for every visitor, every time. Caching serves a prepared copy instead. On WordPress this is a plugin and a configuration change rather than a rebuild, and it is one of the highest-value changes available.

Not every performance problem justifies the same spend. Roughly, the work sorts into three tiers.

The order matters. Rebuilding a site to fix a speed problem caused by six-megabyte images solves the symptom at maximum cost. Do the cheap diagnostics first; they frequently make the expensive conversation unnecessary.

It affects two things at once. Google uses page experience signals as part of ranking, so a slow site competes at a disadvantage for visibility. And separately, visitors abandon slow pages before they load, which means the enquiry never happens and never shows up in your analytics as a lost lead.

That second effect is the one business owners underestimate, because it is invisible. You cannot see the people who did not wait.