A slow site is a revenue problem, not a design opinion
Nobody argues about the ad budget. Everybody argues about whether two extra seconds matter. It is the same money.
Here is a conversation that happens in every agency and every founder-led business. Someone says the site feels slow. Someone else says it looks fine on their machine. The discussion becomes a matter of taste, gets parked, and the site stays slow for another year.
It is not a matter of taste. Speed decides what fraction of the traffic you have already paid for ever reaches your offer, which makes it a line item, not an aesthetic.
Why it is treated as an opinion
Because the people arguing are the worst possible sample. You test on a good laptop, on office fibre, with the page warm in your cache. Your customer is on a mid-range phone on mobile data with fourteen tabs open. Those are different websites.
Google publishes the thresholds it actually measures, and they are public and specific rather than vibes. Core Web Vitals defines what counts as good for loading, interactivity and visual stability. That gives you a number to argue about instead of a feeling.
Where the money actually leaks
Three places, in order of how much they cost and how little they get looked at:
- Paid traffic landing on a slow page. You pay per click whether or not the page finishes rendering. Every visitor who leaves before it does is a click you bought and threw away.
- Mobile organic. Speed is part of how search evaluates pages, and it compounds: slower page, fewer visitors, weaker signals, lower ranking, fewer visitors again.
- Forms and checkouts. The one place users have already decided to act, and the one place a delay reads as broken rather than slow.
The first is the one that stings. If you are spending on ads and sending them to a page that takes five seconds on a phone, you are subsidising your competitor's remarketing. Google's own SEO documentation is unambiguous that the technical foundation is not separable from the content on top of it.
What actually causes it
In our experience rebuilding these, it is rarely the thing people blame. It is almost never the hosting. It is usually one of four:
| Cause | What it looks like | Honest fix |
|---|---|---|
| Unoptimised images | A 4 MB hero photo nobody resized | Resize and convert. Often 90% smaller. |
| Plugin sprawl | Twelve plugins, three doing the same job | Remove, do not add a caching plugin on top. |
| Render-blocking scripts | Blank screen, then everything at once | Defer what is not needed to paint. |
| A CMS doing work at request time | Fast when cached, slow when not | Render it once at build time instead. |
The last one is the interesting case. A great deal of what a database-backed site computes on every single request could have been decided once, when the content was published. That is the whole argument for static output, and it is why a rebuilt page routinely goes from over a megabyte to under twenty kilobytes without losing anything a visitor can see.
The fastest page is the one that was already finished before the request arrived.
How to settle the argument this week
Stop testing on your own laptop. Run the page through Google's own measurement on a throttled mobile connection, then do one thing: find the largest image on the page and see what it weighs. That single number ends most of these debates in about four minutes.
If the traffic is the constraint rather than the page, that is a different problem, and KF Agency works on that end of it. But fixing acquisition while the landing page leaks is the expensive order to do things in.
Describe it. We build it.
Seven or twelve days, pay on delivery, a year of maintenance included. Bring the problem, not a spec.
Book a meetingRead next
The three tools every training centre rebuilds in spreadsheets
Enrolment, attendance and certificates. Every training business ends up building all three in spreadsheets, and every one of them eventually breaks in the same predictable way.
Read