Most slow websites are not slow because of hosting. They are slow because of decisions made months earlier, by people who were never asked about speed.
Here is what actually causes it, how to tell which problem you have, and which fixes are worth paying for.
Speed is a revenue problem, not a technical one
Google has been explicit since 2021: Core Web Vitals are a ranking signal. But ranking is the smaller half of it. The larger half is that people leave.
A visitor who taps your link from a search result has already decided to give you a few seconds. If the page is still assembling itself when that patience runs out, they go back and tap the next result. You never appear in any report, because they never arrived.
The enquiries you lose to a slow site are invisible. Nobody fills in a form to tell you they left.
The four things that are usually wrong
1. Images nobody resized
This is the most common cause by a wide margin, and the easiest to fix. Someone uploads a photo straight from a phone or a stock library at 4000 pixels wide, and the browser downloads all of it to display a 400 pixel thumbnail.
The fix is not complicated: resize to the size actually displayed, serve modern formats like WebP, and set explicit width and height so the layout does not jump while images load.
2. Plugin and script sprawl
Every analytics tool, chat widget, heatmap recorder, A/B tester and social pixel is JavaScript that has to download, parse and run before your page settles. Each one seemed reasonable on its own. Together they are the reason the page takes six seconds.
Audit what is loading. Most sites we look at have at least two scripts nobody can account for, still running from a campaign that ended a year ago.
3. Fonts that block the first paint
Custom fonts are worth having. Loading them badly means the browser waits on a font file before it will show any text at all. Preloading the fonts you actually use, and setting a sensible fallback so text appears immediately, costs nothing and is felt instantly.
4. A theme built to demo well, not to run well
Off-the-shelf themes are built to look impressive in a marketplace preview, which means sliders, animation libraries and half a dozen layout options you will never touch. You inherit the weight of all of it, permanently.
This is the expensive one, because it usually cannot be fixed by tuning. It is why we build sites from scratch rather than customising a template.
How to tell which one you have
Run your homepage through Google PageSpeed Insights. Ignore the headline score, which swings around for reasons that do not matter, and read the two numbers underneath:
- Largest Contentful Paint (LCP) — how long until the main content is visible. Over 2.5 seconds needs attention. This is usually images or fonts.
- Interaction to Next Paint (INP) — how quickly the page responds when someone taps something. Over 200 milliseconds means too much JavaScript.
Test on mobile, on a normal connection. Testing on office wifi on a desktop tells you almost nothing about the person tapping your link on their commute.
What is worth fixing first
In order, because the first two are cheap and the third is not:
- Resize and compress every image above the fold. Often halves load time on its own.
- Remove scripts nobody owns. Free, and immediate.
- Fix font loading. An hour of work, felt on every single page.
- Replace the theme. Expensive, and sometimes the only honest answer.
If the first three get you under 2.5 seconds, stop. Speed is worth pursuing until it stops costing you enquiries, not to the last millisecond.
When it is worth bringing someone in
If you have done the obvious things and the numbers have not moved, the problem is usually structural: render-blocking resources, a bloated framework bundle, or a server that is slow before it sends a single byte. That is diagnosis work rather than tuning.
We do this as a fixed piece of work: measure, fix, and prove the numbers moved. See performance and Core Web Vitals, or tell us the URL and we will tell you what is wrong with it.
