A slow website gives you no warning. Nothing breaks, no error appears, and your analytics still show traffic arriving. The cost is in the people who arrive, wait, and leave before the page has shown them anything.
The cost is a visitor you already paid for
Every visitor arrives through something you invested in: an ad you bought, a search result you earned, an email you wrote. That money and effort is spent the moment someone clicks, whether the page then appears in one second or six.
A slow page does not reduce your marketing spend. It reduces what you get back for it. A visitor who reads your offer costs you the same as one who gives up on a blank screen, and only the first can become a customer.
Your site is judged on a phone, not on your laptop
Websites get built on fast machines with fast connections, close to the server. Almost nobody visits them that way. A fairer test is a mid-range phone on a mediocre connection, because that’s where a large share of your visitors are.
Phones also work harder for the same page. They download the same JavaScript, then run it on a smaller processor while the browser struggles with a weak signal. A page that feels instant at your desk can be a long blank wait in a car park.
Where the time actually goes
The causes repeat from site to site, roughly in this order:
- Oversized images. Photos at full camera resolution get shrunk by the browser, so visitors download pixels they never see.
- Render-blocking JavaScript and fonts: files the browser has to process before it draws anything, which is why the screen stays white.
- Too many third-party scripts, such as analytics, chat widgets, trackers and ad tags, each added for a reason and never removed.
- No caching or CDN, so every visitor fetches everything again from one server, possibly on another continent.
- A slow server response, meaning time spent putting the page together before a single byte reaches the browser.
Third-party scripts build up without anyone noticing. A different person adds each one for a different campaign, and nobody owns the total.
A fast page can still feel broken
A page can paint quickly and still rearrange itself while someone’s reading it. An image arrives late and shoves the text down, or a banner drops in above it. On a phone that’s worse than slow: a thumb is already moving toward a link when the link moves.
Google measures this as Cumulative Layout Shift, one of the three Core Web Vitals along with Largest Contentful Paint and Interaction to Next Paint. The published thresholds for “good” are LCP at or under 2.5 seconds, INP at or under 200 milliseconds, and CLS at or under 0.1. INP replaced First Input Delay as a Core Web Vital in March 2024.
As for search, keep it in proportion. Google has confirmed that page experience signals, including Core Web Vitals, are used in ranking, but they matter less than the relevance and quality of the content itself. You make a site faster for your visitors. Search engines notice as a side effect.
Two kinds of measurement, and why you need both
Lab tests are repeatable. A tool loads the page once, on one machine, over a simulated connection. That makes them good for diagnosis: change something, run the test again, and see whether the number moved.
Field data shows what really happens. It comes from real visitors on real devices and networks, so it’s messier and harder to argue with. It’s also the only way to find out that the page everyone lands on is the slow one.
Use field data to decide what to fix, and lab tests to find out why and to confirm a change helped. One score from one laptop is somewhere to start, and not much more.
When a rebuild is not the answer
Plenty of slow sites don’t need replacing. If the structure is sound and the content is right, the fix is usually a short list of targeted changes: resize the images, remove the scripts nobody can justify, add caching and a CDN, and reserve space for anything that loads late. That’s quicker and far less risky than starting again.
A rebuild earns its place when the problem sits underneath: a platform that’s no longer supported, a codebase where every change is a gamble, or a front end that resists every attempt to make it faster. Then the slowness is a symptom, and treating symptoms year after year costs more than dealing with the cause. Working out which one you have is where any website modernization and performance project starts, and we say so when a few fixes will do. Where a modern front end is the answer, we take it on as React and Next.js development.
Speed also slips over time. New images go up, a tag goes on for a campaign, a plugin updates, and a site that was fixed six months ago is slow again. That’s why performance belongs in ongoing development and maintenance rather than in a project that ends at launch. If you’re not sure whether your site needs a few fixes or something deeper, tell us what you are working with and we’ll recommend an approach.