A visitor never thinks "this page is slow". They do not think anything at all. They look at a white screen for a second and a half, feel a vague boredom, and press back.
And you never find out. Your analytics have no line reading "37 people left because it was slow". That makes speed the one marketing problem that does not report itself, which is why it stays broken on most sites for years.
What slowness costs you
One thing straight away. We do not know what slowness costs your company, and nobody else does either. A slide saying "one second of delay means X percent of sales" is somebody else's shop and somebody else's year.
You can work your own out, from four lines: visitors a month, enquiries a month (calls, emails and forms together), how many enquiries turn into clients, and what a client is worth across the whole relationship.
An invented example, so the arithmetic is visible. A thousand visitors a month, 20 enquiries, one in five becomes a client, a client is worth 1500 euros over a year: four clients a month. Now move only the middle number. 22 enquiries instead of 20 is roughly five extra clients a year, or 7500 euros. Two enquiries a month.
We are not promising that a faster site moves that number. The arithmetic only tells you whether you have a 200-euro problem or a 7000-euro one. It can come back the other way too: if 30 people a month visit and the orders arrive by phone anyway, put this list down.
Where the time goes
We have looked at a lot of slow sites over the past few years, and the causes repeat so precisely that you can almost predict them in order.
Images, nearly always
A photo off a camera or a phone is three to five megabytes and about 6000 pixels wide. The page needs it perhaps 1600 pixels wide and 200 kilobytes heavy.
If someone uploaded eight of those to the homepage straight from a folder, every visitor downloads about 30 megabytes to see something that fits on one screen. On a phone, on a weak signal, that is a disaster.
This is by far the most common cause and the cheapest to fix. It usually returns half the load time without anything on the page looking different.
Too many scripts
Analytics. A second analytics, because the first did not show the thing you needed. A Facebook pixel. A chat widget. A cookie bar. A font loader. A popup offering a newsletter. A map embed in the footer that loads even when nobody scrolls that far.
Each was added on its own. Each seemed trivial at the moment it went on. Together they are often half the load time.
A question worth asking yourself honestly: when did you last open that second analytics report?
Hosting
If the server is cheap and shared, your site is fast only while the neighbours happen to be quiet. You do not notice, because your own browser has the site cached. A new visitor notices.
No amount of image compression fixes this, and neither does any plugin with the word "speed" in its name. It is the only item on this list whose solution is moving house.
Fonts
Four font families, four weights each, all from an external source. The text does not appear until they arrive, so a person stares at an empty space where a headline should be.
Two families are almost always enough. And if they come from your own server, that is one external request fewer.
How a site that launched fast becomes slow
Almost none of those sites was slow at the start. They were built fast, measured and handed over. The slowness arrived later, and quietly.
- A colleague put photos straight off a phone into a news post. The photo is good and it looks fine on the page.
- A plugin went on for a campaign in the spring. The campaign ended, the plugin stayed: taking one off always feels riskier than leaving it there.
- The agency running the ads added a tracking script. It was mentioned in one meeting, and that person has since changed jobs.
- A video went on the front page. A video brings a player with it, and a player is not small.
None of those steps was a mistake, and each one was trivial on its own. Speed is not a project that gets finished. It drifts. Which is why the most useful thing you can do is also the most boring: once a year, open the plugin list and the front page and ask of every line who needs it now.
What to measure
Google looks at three things, and they are the same three a visitor actually feels. The names are ugly but the ideas are simple.
- LCP - how quickly the largest thing on the page appears. Usually the headline or a big image. This is "is the page loading at all".
- CLS - how much the content jumps around while loading. This is why you press the wrong button, because an advert loaded itself into the path of your click.
- INP - how long the page takes to respond to a press. A button that does nothing immediately is a button that gets pressed three times.
And now the thing we say in almost every meeting: one number instead of three tells you nothing. "Our site scored 92" is a sentence that can sit in front of a very slow site. Most speed tools measure a desktop machine on a fast connection by default. Your customer is on a phone, on a bus, on an average signal.
If you test, test in mobile mode. The difference is often two to three times.
The most honest instrument is a phone and a stopwatch
Take your phone, turn the wifi off and stay on mobile data. Walk out of the office, because the signal in the office is good. Type the address by hand rather than using a bookmark. Start the stopwatch and mark two moments: when text you can actually read appears, and when you can press a button without anything shifting under your thumb.
Write those two numbers of seconds down and do the same once a quarter. A score out of a hundred is an average a machine calculated from one attempt, on a connection your customer does not have. The stopwatch measures what actually happens.
Your own laptop lies to you for three reasons at once: the cache (half the files are already on the machine), the connection (a cable is not a bus), and the fact that you know where you are going. Your eye is on the button before the page has finished.
Quick wins you can do this week
- Resize every image properly and serve it in a modern format. This alone often returns half the load time. If your site system can do it automatically, switch that on and run the old images through it again.
- Remove every script nobody looks at. Go down the list and ask who uses each line. Usually two to four disappear.
- Load anything below the fold only once someone scrolls to it. Most site systems can do this, but it is not always on by default.
- Cut down to two font families and serve them from your own server.
- Give images their dimensions. A small technical detail that stops the content jumping, which improves CLS almost for free.
If your site runs on WordPress
Most small business sites in Estonia do. Here the order matters more than the individual step. A backup before anything else. Then the images, because the images are the cause and a plugin is a plaster. Only then one optimisation plugin, with a measurement between every change.
Three optimisation plugins do not add up, they compete. Each one caches the output of the one before it, two of them rewrite the same file, and when something breaks you can no longer say which of them did it.
One place in the media settings is worth opening: "Settings", then "Media". Those are the sizes WordPress generates from every image you upload. If the design shows a photo 1600 pixels wide but the largest generated size is 1024, the browser gets the original instead: that six thousand pixel file from the phone.
Two fixes that look like fixes
A caching plugin on a site nobody has fixed. A caching plugin stores the finished page so the server does not have to assemble it again for every visitor. Useful. But it does not make your images smaller: those 30 megabytes still travel to every new visitor's phone. A cache skips the assembly, not the delivery. The number in the tool improves, because the tool is measuring the second time round, warm.
A bigger server, when the problem is the images. A bigger server thinks faster, but thinking was never the slow part. Thirty megabytes on their way to a phone on an average signal are still thirty megabytes. You start paying every month to fix the part that was not broken.
Neither is wrong in itself. A cache is the right step once the images are sorted, and a bigger server is the right step when hosting really is the cause. The difference is the order: cause first, purchase second. The other way round, all you buy is a prettier measurement.
When it needs real work
If the images are sorted, the scripts are trimmed, the fonts are cut down and the site is still slow, the cause is deeper: hosting, the database, or how the site itself is built.
A plugin does not help here. And honestly it is not worth attempting yourself, because this is exactly where things break. A caching plugin gets swapped in, the site gets twice as fast, and the contact form stops working without anyone noticing for three weeks.
Our own rule is simple: everything on the list above is reversible, provided you took a backup first. Everything below it gets done with a backup and checked afterwards. And if the site is built in a way that cannot be made fast, the honest answer is a new site rather than one more fix.
Speed is a tiebreaker, not the goal
Before that, one sentence about Google, because this gets promised the wrong way round. Speed is a tiebreaker, not a cheat code: if two pages answer the question equally well the faster one wins, but a fast page with nothing to say loses to a slow page that answers the question. The search side is worth treating as its own piece of work, not as a by-product of speed.
Speed is not the goal. Nobody buys anything from you because the page loads in 1.2 seconds. Speed is just what allows everything else to work at all: the content, the offer, the contact form.
Which is why we never recommend a speed project before the content is in place. A very fast page with no answer to the customer's question is simply quickly useless. If the trouble is really there, start with the content.
Where to start
The cheapest step is still the phone and the stopwatch. Our free search engine audit says the same thing without you needing to know any tool names.
Keeping it there, meaning somebody notices when things get slow again, is what web management is for. And if the problem is the server, the answer is on the hosting page: that one cannot be solved with code.
And if the arithmetic above gave a large enough number, ask for a quote and put those two stopwatch numbers in the message. Work can start from those. It cannot start from "the site feels slow".
Frequently asked questions
The most common cause is images: a photo off a camera or a phone is three to five megabytes and about 6000 pixels wide, when the page needs it perhaps 1600 pixels wide. The second is scripts - analytics, a pixel, a chat widget, a cookie bar, a font loader - each trivial at the moment it went on and together often half the load time. The third is cheap shared hosting, the only one of these whose solution is moving house. The fourth is fonts: four families from an external source hold the text back until they arrive.
LCP is how quickly the largest thing on the page appears, usually the headline or a big image. CLS is how much the content jumps around while loading, which is why you press the wrong button. INP is how long the page takes to respond to a press. One number instead of three tells you nothing, because most speed tools measure a desktop machine on a fast connection by default, while your customer is on a phone on an average signal. If you test, test in mobile mode: the difference is often two to three times.
Take your phone, turn the wifi off and stay on mobile data, walk out of the office, because the signal in the office is good, and type the address by hand rather than using a bookmark. Start the stopwatch and mark two moments: when text you can actually read appears, and when you can press a button without anything shifting under your thumb. Write those two numbers down and repeat once a quarter. Your own laptop lies for three reasons at once: the cache, the connection, and the fact that you know where you are going.
A caching plugin stores the finished page so the server does not assemble it again for every visitor, but it does not make your images smaller: a cache skips the assembly, not the delivery. A bigger server thinks faster, but if the images were the slow part you start paying every month to fix the part that was not broken. Neither is wrong in itself: a cache is right once the images are sorted, and a bigger server right when hosting really is the cause. The difference is the order: cause first, purchase second.
Speed is a tiebreaker, not a cheat code. If two pages answer the question equally well the faster one wins, but a fast page with nothing to say loses to a slow page that answers the question. Speed is not the goal: nobody buys anything from you because the page loads quickly, it is simply what allows the content, the offer and the contact form to work at all. That is why a speed project is not worth starting before the content is in place.
Read next
You nodded through a meeting about A records and TTL. The invoice says "unlimited", the report shows a red LCP. Here are those words back, in groups and a sentence apiece, every abbreviation written out. Including the three that actually cost money when they go wrong.