Site speed is a topic that gets talked about a lot and measured little. "Optimised for speed" is in almost every quote, yet a large share of sites take three seconds or more to load on a phone.
This post breaks down what really decides speed, in order of how much each item weighs.
Why it matters
Two reasons, and the first is bigger.
People leave. Every extra second of waiting loses some visitors, most of all on phones and weaker connections, which is exactly where most traffic is today.
Google measures it. Speed is part of how a page is rated, based on real visitors. The measures are explained in Core Web Vitals for business owners.
The first reason holds regardless of search engines. A site that loses a fifth of its visitors before the first image loses them even when it ranks perfectly.
1. Images: the biggest single culprit
On a typical business site, images are 60 to 80 percent of everything downloaded.
What goes wrong:
The size isn't adapted. A photo from a camera is 4,000 pixels wide and several megabytes. On screen it takes up 800 pixels. The browser downloads all of it anyway.
Old formats. JPEG and PNG have outlived themselves. WebP gives the same quality at 25 to 35 percent less, and AVIF even less.
Everything at once. Images at the bottom of the page load even though nobody has seen them.
No set dimensions. The browser doesn't know how much space to leave, so the content jumps when the image arrives.
Done properly, this is the biggest gain for the least effort. On my case studies, images went from 13 MB to 472 KB with no visible difference.
2. The amount of code that's sent
The second item by weight.
JavaScript is the most expensive because it doesn't just have to be downloaded but also run, and on a cheaper phone that takes noticeably longer than on a computer.
CSS blocks rendering: until it loads, nothing is shown.
Fonts. Every weight and every style is a separate file. Three fonts in four weights is twelve files before the first word.
This is where the difference between a custom site and one on a ready-made platform or template comes from: a template carries code for every feature it has, and you use a part of it.
3. The server and where the site lives
Time to first byte is how long the server waits before sending anything. If that's a second, everything else is a second late.
This is where the biggest difference lies between a site assembled on every visit and one that's already finished. The first runs code, queries a database and builds the HTML; the second sends a file that's waiting ready.
Proximity matters too. A site served from a network with a node close to the visitor arrives faster than one travelling across half of Europe.
4. Third-party scripts
Every tool you add has a price: a chat widget, visit tracking, an ad pixel, a cookie bar, embedded maps, embedded video.
The unpleasant part is that you have no control over them. If their server is slow, your site is slow.
It's worth listing them once and asking of each whether it brings more than it costs. An embedded map that loads straight away can often be replaced by an image that becomes a map on tap.
5. Loading order
The same content can arrive in one second or three depending on the order.
What's on the first screen needs priority. The rest can wait. Fonts should be set up so the text shows straight away and then swaps when the font arrives, which is better than empty space.
How to measure
PageSpeed Insights: the top section shows real visitors, the bottom a test. Look at the mobile score.
The Network panel in the browser shows what's downloaded and how big it is. Sort by size and you'll see the culprit in seconds.
WebPageTest for a more detailed view of the order.
Realistic expectations
For a business site on a modern stack, it's reasonable to expect:
- The main content visible under 1.5 seconds on a phone.
- A total page weight under 1 MB, images included.
- Under 100 KB of JavaScript.
That isn't theory: it's what you get when a site is written without excess and the images are prepared properly.
Frequently asked questions
Can an existing site be made faster?
Partly, almost always. Images, third-party scripts and fonts can be fixed without a new build. The limit is in how it's built: the amount of code a platform sends can't be removed.
How long does a fix take?
Images and scripts take a few hours to a day. Deeper work depends on how the site was built.
Is speed more important than content?
No. Content and what the site offers decide more. Speed decides whether anyone reaches the content.
Do I need AMP?
No. Google no longer favours it and for most sites it makes no sense.
How to check where you stand
Run your address through PageSpeed Insights and look at the mobile score. If it's below 50, send me the address and I'll tell you what's causing it and whether the fix is small or goes into how the site is built.