How Fast Should Your Website Load?

The 3-second rule

Google’s research is blunt about this. 53% of mobile users abandon a site that takes longer than three seconds to load. Not five. Not ten. Three.

Here is the bounce probability as load time grows, from Google’s own findings:

• 1 second: the baseline. This is where attention is still intact.
• 2 seconds: bounce probability up 32%.
• 3 seconds: bounce probability up 90%. More than half your mobile visitors are gone.
• 5 seconds: bounce probability up 106%.
• 10 seconds: bounce probability up 123%. The few who remain are angry.

The curve flattens because there is nobody left to lose. Most of the damage is done in the first three seconds.

What “load time” actually means

When we talk about load time, we are not talking about the loading spinner disappearing. We are talking about when the user can see and use the main content. That metric is called LCP — Largest Contentful Paint — and it is the one that maps to how fast the page feels.

A page can technically finish loading, in the sense that all its resources have downloaded, and still feel slow because the main content has not painted yet. This is the JavaScript hydration problem. The browser has the data. It has the HTML. But it is waiting on 200KB of JavaScript to execute before it can show anything meaningful. The user stares at a blank or half-rendered screen.

That gap between “done downloading” and “usable” is where most business sites lose people.

Mobile vs desktop: the gap nobody tests for

Here is the part that catches everyone. The load time you measure on your MacBook is not the load time your customers experience.

Most testing happens on fast laptops over fast wifi. Most browsing happens on mid-range Android phones over cellular connections. A mid-range phone has a CPU roughly a third as fast as a modern laptop, and it processes JavaScript far less efficiently. A page that loads in 1.2 seconds on your desk can take 4 seconds on the device in your customer’s pocket.

Google actually publishes this. They test on a simulated Moto G Power — a real, common, cheap phone — and throttle the connection to a slow 4G profile. If you have only ever tested your site on your laptop, you are looking at the optimistic version of your numbers.

The gap is not small. It is the difference between a site that works and a site that quietly loses half its audience.

Where the time actually goes

Let’s break down a typical React-based marketing page on a throttled mid-range phone.

• 0–200ms: DNS lookup, TCP handshake, TLS negotiation. Networking overhead you mostly cannot compress.
• 200–500ms: Server response time, the time to first byte.
• 500–1,500ms: Downloading the HTML, the CSS, and the JavaScript bundles.
• 1,500–3,000ms: Parsing and executing the JavaScript and hydrating the React tree. This is the expensive part, and it is the part frameworks add.
• 3,000ms+: The main content finally paints.

Now the same page built in Astro and served from a CDN edge.

• 0–200ms: DNS, TCP, TLS.
• 200–400ms: Server response, except now it is a static file from the nearest edge node, not an origin server rendering on demand.
• 400–600ms: Download the HTML and the CSS. No JavaScript bundle to fetch.
• 600ms: Content is visible.

That is not a typo. About 600 milliseconds from request to a painted page, on the same throttled phone. The difference is the absence of the JavaScript execution step.

The hydration tax, named

The big chunk of time in the React example — that 1.5-second block of parsing and executing and hydrating — is what we call the hydration tax. The framework ships a runtime, the browser downloads it, parses it, runs it, and then walks the page attaching event listeners. All of this happens before the page is fully usable, and most of it is invisible work that produces no visible result.

You pay this tax on every single page load, for every single visitor, whether they ever interact with the page or not. On a marketing site where 95% of visitors just read and leave, that is a tax collected for a service almost nobody uses.

Astro’s model is the opposite. Static HTML, hydrated only where you ask for it. The tax drops to zero on most pages and to a few kilobytes on the ones that genuinely need interactivity.

The business math

Say you get 1,000 visitors a month. That is modest, but concrete.

If your site takes 4 seconds to load, roughly 70% of mobile users bounce. That is 700 people who never saw your offer. If even 2% of the remaining visitors contact you, that is six leads a month.

Cut the load time to under a second. Bounce rate on mobile drops sharply. Say 40% bounce instead of 70%. Now 600 people stay instead of 300. At the same 2% contact rate, that is twelve leads. You doubled your leads by changing nothing about your offer — only how fast the page appears.

Now run that math over a year. Then run it over the lifetime of the site. Speed is not a technical detail. It is the single highest-impact thing you can fix, and most businesses never fix it because it does not show up on an invoice.

What to do today

Three things, in order.

1. Measure. Run your homepage through PageSpeed Insights. Look at the mobile score, not the desktop one. If your performance number is under 50, you have a real problem. If it is under 90, you have room to improve.
2. Find the biggest cost. The report tells you. It is almost always a large image, a heavy JavaScript bundle, or a slow server.
3. Cut it. Compress the image. Drop the framework. Move to a CDN. The fixes are not exotic. They are just rarely done.

Speed is not an optimization task you do once. It is the default you set when you build the site. Build it right and you never have to think about it again.

---

Want a site that loads before your visitors can second-guess? See our pricing or tell us about your project.