What actually makes a website fast
Hosting gets the blame and images are usually the culprit. A practical look at where the time on a page actually goes — and the handful of decisions that fix most of it.
- Performance
- Web Development
Every client asks for a fast website, and almost every conversation about it starts in the wrong place. Speed is not one number and it is not one setting. It is a handful of decisions, most of which are made long before anyone runs a test.
Hosting is the floor, not the ceiling
Cheap shared hosting will make a good site slow. Expensive hosting will not make a bad site fast. The server decides how quickly the first byte arrives; everything after that is the page's own doing — and on most sites, everything after that is where the time goes.
What the server genuinely controls is worth knowing: time to first byte, how close it sits to your visitors, and whether it falls over under load. Those are real, and they are the reason we are opinionated about where a site is hosted. They are also, on a well-built site, a small slice of the total.
Images are almost always the problem
On nearly every site we are asked to look at, images are the largest thing on the page by an order of magnitude. A photograph straight off a phone is four megabytes. The same photograph, sized for the box it appears in and saved as WebP, is under a hundred kilobytes — and looks identical.
Three things fix most of it:
- Serve the size that is actually shown. A 3000px image in a 600px column is 2400px of wasted download.
- Use a modern format. WebP and AVIF are a fraction of the size of the same JPEG.
- Reserve the space before it loads. An image without dimensions makes the text jump as it arrives, which reads as slow even when it is not.
JavaScript you don't send can't slow you down
A page has to be downloaded, parsed and executed before anyone can use it, and JavaScript is the most expensive of the three. Every plugin, tracker, chat widget and carousel adds to a bill your visitor pays on their own phone, on their own data.
This is why we build most marketing sites as static pages. The HTML is generated when the content changes rather than when someone visits, so the server has nothing to compute and the browser has almost nothing to run.
The fastest request is the one that never happens. The second fastest is one answered by a file that already exists.
Measure what your visitor feels
Speed scores are a proxy. The numbers worth watching are the ones that describe an actual experience — Google groups them as Core Web Vitals:
- Largest Contentful Paint — when the main thing on the page shows up. Aim under 2.5s.
- Interaction to Next Paint — how quickly the page answers a tap. Aim under 200ms.
- Cumulative Layout Shift — how much the page moves while loading. Aim under 0.1.
Test on a mid-range phone on mobile data, not on your laptop on fibre. Chrome's Lighthouse panel has a Slow 4G throttling preset for exactly this, and the difference between the two is usually the difference between a site people use and one they abandon.
None of this is exotic. It is sizing images properly, sending less code, and putting the result somewhere sensible — done consistently, from the start, rather than retrofitted once someone complains. If your site is slow and you are not sure which of these is to blame, send us the URL and we will tell you what we find.