"The site is slow" is one of the most frequent complaints and one of the worst defined. Slow for whom? At what moment? Compared to what?
Without answering that, any optimization is a shot in the dark. And most of the time, teams end up optimizing whatever is easy to measure instead of whatever actually hurts the user.
What the user feels
There are three moments that matter, and none of them is "how much does the page weigh."
When they see something. The time until the main content shows up. If there's a blank screen for two seconds, it doesn't matter what happens after: part of your audience already left.
When they can use it. Seeing isn't the same as being able to tap. A site that shows up fast but ignores clicks for a second feels worse than one that takes a bit longer but responds the moment it appears.
Whether the content jumps. That moment when you're about to tap a button and an image that loaded late pushes everything down and you end up tapping something else. It's the one that generates the most frustration and the cheapest to fix: it's almost always about reserving the image's space before it loads.
The mistake of measuring from your own desk
You open the site on your computer, on fiber, and it's fine. Conclusion: not slow.
Your customers aren't you. They're on their phone, on a variable connection, and sometimes on a four-year-old device. Speed has to be measured under real conditions, not yours.
And above all: you need to measure the real site, with data from real people, not just in a lab test. Synthetic measurements are useful for finding problems; real user data is useful for knowing whether they exist.
Where to start (in this order)
The problem is almost never the framework or the server. It's this, in this order:
- Images. They're 90% of the weight of almost any site. Modern formats, the right size for where they're displayed, and lazy loading for anything further down. This alone usually solves half the problem.
- Fonts. A badly loaded typeface blocks the text: the page is there but unreadable. Showing text with a fallback font while the final one loads beats a blank screen.
- Third-party scripts. Analytics, chat, pixels, heatmaps. Each one is someone else's code running on your site, and it can slow it down. This is the most uncomfortable one, because someone specifically asked for each one, but it's where you gain the most.
- Only then, your own code.
That order matters. It's very common to see teams optimizing their JavaScript while the homepage loads a 4 MB image.
How you connect it to money
This is the part that turns the discussion from technical into something else.
If you have analytics, you can cross speed against conversion: group sessions by how fast they loaded and compare how much each group bought. The relationship is usually pretty clear, and it's useful for justifying the investment to whoever signs off on it.
You can also go the other way: look at your highest-traffic pages and sort them by speed. The ones high on traffic and low on speed are your task list, in order.
What not to do
- Chase the score. A 100 on some tool doesn't mean the site feels fast. Optimize for what people feel, not for the number.
- Optimize without measuring first. If you don't know the starting point, you won't know if it worked.
- Optimize only once. Speed degrades on its own: every new feature, every script someone in marketing adds. Without continuous measurement, you're back to square one in six months.
This site is delivered pre-rendered for exactly this reason. If you have an e-commerce store and suspect speed is costing you sales, write to us and we'll measure it.
