What a Slow Web App Really Costs You
"The site feels a bit slow" is easy to ignore. It's vague, it's hard to argue with, and it never makes it to the top of the list.
So before any theory, sit through it. Set a load time below and press the button.
Pick a load time, press the button and watch how long the main content takes to turn up.
Put your own numbers on it
The drop-off figure is yours to set. Every site is different, so take it from your analytics rather than from us.
Your estimate. Compare fast and slow sessions to find it.
- Conversions lost per month
- 40
- Revenue lost per month
- £3,200
- Revenue lost per year
- £38,400
Two seconds doesn't sound like much when you read it. It feels like a lot longer when you're staring at a grey box. Your visitors do that on every page.
What the simulator is measuring
The number you set is Largest Contentful Paint (LCP): how long it takes for the main thing on the page to appear. That's normally the headline, the hero image or the first screen of your app.
Google publishes thresholds for it as part of Core Web Vitals:
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| LCP | When the main content appears | 2.5s or less | Over 4s |
| INP | How quickly the page reacts to a tap or click | 200ms or less | Over 500ms |
| CLS | How much the layout jumps around | 0.1 or less | Over 0.25 |
Google judges you on real visits, at the 75th percentile. In plain terms, three out of four page loads need to hit the "good" mark, including the ones on old phones and patchy 4G.
Why we don't give you a magic percentage
You'll have seen claims that every extra second costs some fixed share of your sales. Those figures come from other people's websites, with other people's customers. Yours will be different, and it could be better or worse.
That's why the second half of the simulator asks for your own drop-off estimate. To find a real one:
- In your analytics, split sessions by load time: fast against slow.
- Compare the conversion rate of each group.
- Put the gap into the calculator.
If you don't have load times in your analytics yet, Google's PageSpeed Insights shows field data for pages with enough traffic. That's a fair place to start.
Where the time usually goes
In most slow web apps the delay comes from a short list of causes.
- Oversized images. A hero image served at four times the size it's displayed.
- Too much JavaScript up front. The browser has to download, parse and run it before anything useful appears.
- Slow server responses. An unindexed database query, or a page that waits on several API calls one after another.
- Third-party scripts. Chat widgets, trackers and tag managers, each adding its own delay.
- Content that loads after the page does. A spinner, then a second request, then the data.
Motion can be on that list too. We covered how to keep it cheap in Do Animations Hurt SEO?
The order to fix things in
- Measure real visits first. Lab scores from your own laptop are a best case.
- Find the LCP element on your most important pages and make that one thing arrive sooner.
- Fix the server response before polishing the front end. Nothing can render until the first byte arrives.
- Put the JavaScript on a diet. Load what the first screen needs and defer the rest.
- Set a performance budget so it stays fixed.
What a performance budget is
A budget is a limit you agree in advance, for example "LCP under 2.5 seconds on the product page" or "no more than a set amount of JavaScript on first load". The build checks it automatically, and a change that breaks the limit doesn't ship until someone decides it's worth it.
Without one, speed slips a little with every release and nobody notices until a customer does.
What to do next
Run the simulator at your current LCP, put your own figures into the calculator, and you'll know whether this is a rounding error or a line item. If it's a line item, that's what our performance and security service is for.