How do I tell if my website is genuinely slow?

Test it on a phone, on mobile data, from a place your customers actually are, and test a page you have never visited so that nothing is cached. Testing on the office wi-fi on a page you look at daily will always feel fast.

My site got slower this month. Where do I look first?

At what changed. A new plugin, a new tracking script, a large image added to the home page, a hosting plan change, or a migration. Speed rarely degrades on its own.

Is slowness a hosting problem?

Sometimes, and less often than it is blamed. Images, scripts and third-party embeds account for more of it on most small business sites, and those are page problems rather than server problems.

My website is slow | Australian Website Design

This page is triage for a site that has become slower. What makes websites slow in general is a different question, answered in the performance guides; this one is for somebody who noticed a change.

Start with two facts, because both are routinely got wrong and either will waste an afternoon.

Test on a phone, on mobile data. Not the office wi-fi, not a desktop on a fixed connection. Most visits are on a phone and most complaints originate there.

Test a page you have never opened. A page you visit daily is cached in your own browser and will always feel fast, whatever anyone else experiences.

What changed

Speed rarely degrades on its own. Something was added or something moved. In the order they turn out to be the cause:

Change	Typical effect	Who fixes it
A large image added to a key page	Immediate and large	Whoever adds content
A new plugin or extension	Varies, sometimes severe	Developer
A new tracking or chat script	Slows interaction more than loading	Whoever added it
A third-party embed — map, feed, video	Large, and outside your control	Developer
A hosting plan or server change	Consistent across every page	Host
A migration	Everything at once	Developer
Growth in content or traffic	Gradual	Host, then developer

The first row is worth dwelling on because it is the most common and the least technical. A photograph taken on a modern phone and uploaded directly is often many times larger than the page needs, and one of them on a home page can dominate everything else on it.

The three measurements that matter

Core Web Vitals are Largest Contentful Paint, Cumulative Layout Shift and Interaction to Next Paint. Interaction to Next Paint is the current responsiveness measure; First Input Delay is no longer one of the three.

In plain terms: how long until the main thing appears, how much the page jumps about while loading, and how long it takes to respond when someone taps something.

They matter here because they separate causes. A slow Largest Contentful Paint usually means a heavy image or a slow server. Layout jumping usually means images or embeds without reserved space. Poor responsiveness usually means scripts.

Lab tests and real visitors

A speed testing tool runs one test from one place on one simulated connection. That is a lab measurement, it is repeatable, and it is not what your customers experienced.

A search console reports the same three measurements from actual visits to your site. That is field data, it is what actually happened, and it is free. When the two disagree, the field data is the one describing your business.

Use the lab test to find what to fix and the field data to decide whether it mattered. Setting up the account that reports it is on measuring what search engines did.

The Australian consideration

Distance is real. A site hosted on the other side of the world has a round trip to Australia on every request, and on a mobile connection outside a capital city that is compounded. It is not the largest factor on most small business sites — images and scripts usually are — but it is a genuine one and it is the factor most often dismissed by suppliers testing from somewhere else.

If your customers are Australian and your hosting is not, that is worth checking rather than assuming either way.

The order to fix a slow website in

Images. Resize and compress the large ones. The highest ratio of improvement to effort on almost every small business site, and it requires no developer.
Third-party scripts. List every tracking, chat, review and social script on the site and remove the ones nobody uses. Each one is code from somebody else running on your page, and each one adds its own HTTP requests before the page can be considered loaded.
Embeds. Maps, streaming video players and feeds. Often replaceable with an image that links through.
Plugins. Remove what is not used, rather than adding a plugin to speed up the plugins.
Hosting. Only after the above, because moving a heavy page to a faster server is paying monthly to hide a problem you could have deleted.

Most small business sites never need step 5.

What not to do

Do not install a speed plugin as a first response. Aggressive caching over an unfixed page produces a fast broken page, and the breakage is usually noticed later than the improvement.

Do not chase a score. A testing tool’s headline number is a summary. A business that improves the number while the site still feels slow on a phone has optimised the measurement.

Do not delete tracking you rely on in order to gain a second. Decide what the measurement is worth first.

When it is not the site

Three cases where nothing is wrong with the website at all: your own connection or device, a temporary host-side event, or a site that is not slow but is down for some visitors. If pages sometimes fail entirely rather than loading slowly, that is a different problem and it is on a website that will not load.

What to do next

Test one page you have never opened, on a phone, on mobile data, and write down the number. Then list what changed on the site in the last two months. Between those two you will usually have the cause before anyone is engaged. Where the fix is genuinely technical, that scope is on development as an ongoing engagement.

My website is slow