You get about three seconds. That is roughly how long someone on a phone will look at a blank screen before hitting back and opening the next search result. It is not impatience. It is the sensible response when nine other companies are one tap away.
Page speed still sits near the bottom of most project lists, somewhere below colours, copy and the contact form. We think that is a mistake. Load time is the first impression, and it is the one impression good design cannot rescue. Before anyone reads a word about what you do, they have already felt whether your company is quick or sluggish.
What actually slows a page down
It is nearly always the same suspects. Images straight from the camera or a stock library, several megabytes each, displayed six hundred pixels wide. Scripts from other companies: a chat bubble, an analytics tool, an ad pixel, a cookie banner, a font service. Every one of them opens a connection to somebody else's server, and your page waits.
Then there are fonts that arrive late and leave the text invisible for a beat. Images and ad slots with no reserved space, which shove everything down as they load, so people tap the wrong thing. And a server that takes the better part of a second to answer the very first request because something heavy is thinking in the background.
Core Web Vitals in plain language
Google measures three things, and all three describe the experience rather than the code. How long until the biggest visible element appears, usually the hero image or the headline. Whether the page responds the first time you tap it, or freezes because scripts are still busy. And whether the layout stays put while the rest loads, instead of jumping around under your thumb.
That is enough to act on. You can disappear into thresholds and percentiles, and plenty of people do, but it buys very little while the basics are still broken.
The uncomfortable part
Most websites do not lose their time in code. They lose it in images nobody resized and in tracking scripts somebody added three years ago that no one reads any more. We have seen sites where deleting two dead scripts did more than a week of development work.
So start with an inventory. Which external services run on your site, who asked for them, and does anyone still look at the data? Anything without an answer to those questions can go.
An order of work that pays off
Images first. Correct dimensions, a modern format, and nothing below the fold loads until someone scrolls there. Then clear out the foreign scripts. Then the fonts: two weights served from your own domain beat six pulled in from elsewhere. Only after that is it worth talking about caching, delivery networks and server response times.
It is not the exciting order, but it is the cheap one. Rebuilding your server architecture will not save a home page that carries a four megabyte photo.
Test on a phone, not at your desk
The classic self deception goes like this. You open your own site at the office, on a fast line, with everything already cached, and conclude that it is instant. Your customers are not sitting at your desk. They are on a platform with a three year old handset and two bars of signal. Measure there, or you are optimising for yourself.
More on how we build fast, maintainable sites: web development.
Frequently asked questions
How fast does a page need to be?
As a rule of thumb, the useful part should be on screen after a little over two seconds on an average phone. The exact number matters less than whether the page feels finished rather than half built.
Would switching hosting help?
Sometimes, rarely first. If your server needs more than a second to answer the initial request, it is worth a look. In most cases the problem lives in the browser, not in the data centre.
Does a fast site cost more?
Usually it costs one round of cleaning up and then a little discipline. It gets expensive when speed has to be retrofitted into a site built on twenty add on services.
If you want to know what is holding your own site back, we will look at it together, with no obligation and no sales pressure.
This article is part of our knowledge hub web development and e-commerce.