Speed is a feature: why every 100ms costs you customers

The number that actually matters

Google’s own research is blunt about this: as page load time goes from one second to three, the probability that someone bounces climbs by 32%. Push to five seconds and it nearly doubles. Speed isn’t a nice-to-have that lives in a developer’s conscience — it’s a direct tax on every marketing dollar you spend getting people to the page in the first place.

The metrics I watch are the Core Web Vitals: Largest Contentful Paint (how fast the main content appears), Interaction to Next Paint (how quickly the page responds when tapped), and Cumulative Layout Shift (how much the page jumps around while loading). They’re the same signals Google uses for ranking, which means fast sites get rewarded twice — once by visitors, once by search.

Where the seconds actually go

• Oversized images — a single un-optimized hero image can weigh more than an entire well-built page.
• Render-blocking scripts — third-party tags and heavy JavaScript that stop the page from painting.
• Font loading — beautiful typography that leaves users staring at blank space while it downloads.
• Doing work on the client that should happen on the server, before the page ever reaches the browser.

How I build for speed by default

I render as much as possible on the server so the browser receives finished HTML, not a construction site. Images are sized, compressed, and served in modern formats automatically. Fonts are loaded so text is visible immediately rather than hidden behind a spinner. And the whole thing ships on infrastructure that serves your pages from close to your visitors, wherever they are.

None of this is exotic. It’s just a discipline of measuring first, cutting weight, and refusing to ship a page that fails its vitals. Fast is a decision you make on day one — not a rescue mission you run after launch.