"Can you make our site faster" is one of the most common things we get asked, and it is almost always asked after someone has already bought faster hosting and been disappointed. Hosting is rarely the problem. Here is what usually is, in the order it is usually worth checking.
First, measure. Open PageSpeed Insights, put your URL in, and look at the mobile score, not the desktop one. Then look at Largest Contentful Paint — how long until the biggest thing on the screen appears. Under 2.5 seconds is fine. Over 4 is why people are leaving.
One: your images are enormous
This is the single biggest cause, and it is the easiest to fix. A photographer sends a 6MB JPEG, someone uploads it straight to the hero, and the browser downloads all six megabytes to display it 1200 pixels wide on a phone.
- Export at the size it will actually be shown, not the size it came out of the camera.
- Serve WebP or AVIF rather than JPEG. The same picture, roughly a third of the bytes.
- Set width and height on every image so the page does not jump while they load.
- Load images below the fold lazily — the browser does this for you with one attribute.
Fixing only this usually takes a site from "slow" to "fine".
Two: you are loading fonts wrong
Custom fonts block text from rendering. If the font file is fetched from a third-party domain, the browser has to do a DNS lookup, a TLS handshake and a download before it will show a single word.
Self-host the font files, subset them to the characters you actually use, and set font-display: swap so the text appears immediately in a fallback and reflows when the real font lands. Three fonts on a page is usually two too many.
Three: you have installed too many things
Every plugin, tag, chat widget, heatmap, popup tool and analytics script is more JavaScript the browser must download, parse and run before the page responds to a tap.
Open your browser's network tab, sort by size, and look at what is actually being loaded. On most sites we audit there is at least one script nobody remembers adding and nobody is reading the output of. Removing those is free performance.
- List every third-party script on the site.
- For each one, name the person who looks at its data.
- If you cannot name one, delete it.
Four: the page is being built at the wrong time
This is the structural one, and the one that actually needs a developer. If every visit makes your server query a database and assemble the page from scratch, every visitor waits for that. Most pages do not change between visits — so they should be built once and served as files.
That is what we do by default: pages are rendered ahead of time and served from the edge, and only the parts that genuinely differ per visitor are built per request. It is the difference between a page that responds in 80 milliseconds and one that responds in 800.
What we would not bother with
- Upgrading hosting before doing the four above. Faster servers do not fix a 6MB image.
- Minifying CSS as a headline fix. It is worth doing and it is worth almost nothing on its own.
- Chasing a score of 100. The score is a proxy. The number that matters is whether the thing people came for appears quickly on a mid-range Android phone on mobile data, because that is who is visiting.
Speed is not a feature you add at the end. It is a set of decisions you either made or did not make while building.
If you want us to run this properly on your site, ask — we will send back what we find and what it would take to fix, whether or not you hire us to do it.