Every 100ms Costs You Money. Here's the Data.
Speed isn't a technical concern — it's a business metric. The numbers are more brutal than most teams realize, and the fixes are more accessible than they think.
James Park
APSLOCK
The Numbers Are Real
Amazon ran the study that changed how engineers talk to executives: every 100 milliseconds of added latency cost them 1% in revenue. That was in 2006. The mobile era has made it worse.
Google found that a half-second delay in search results dropped traffic by 20%. Walmart discovered that for every one-second improvement in page load time, conversions increased by 2%. These aren't edge cases. They're consistent across industries, device types, and traffic sources.
Speed is a conversion lever, and most teams are leaving money on the table.
Why Most Sites Are Still Slow
The irony is that we have better tools than ever, and sites are slower than they were five years ago. The culprits are predictable:
JavaScript bundle sizes ballooned — modern frameworks made building easier and bundles heavier
Third-party scripts — analytics, chat widgets, A/B testing platforms, ad pixels — each adds network requests and blocks rendering
Unoptimized images — a marketing team uploads a 3MB JPEG and nobody notices until someone checks Lighthouse
No caching strategy — assets that don't change are re-fetched on every visit because nobody set cache headers
No CDN — a server in Virginia serving users in Singapore with 300ms of latency baked in before the page starts loading
The Quick Wins (Do These First)
Before touching architecture, these fixes deliver the most return per hour of engineering time:
Convert images to WebP and serve them at the right size with srcset — this alone can cut 30–60% off page weight
Add a CDN — Cloudflare's free tier is enough for most small to mid-size sites
Lazy-load below-the-fold images — the browser has native support, it's one HTML attribute
Audit your third-party scripts — load them asynchronously and defer what isn't needed on first paint
Set proper cache headers — static assets should be cached for a year with a versioned filename
You can often get a site from a Lighthouse score of 40 to 75 without touching a single line of application code.
The Architectural Decisions That Matter Long-Term
For teams building new products or doing serious refactors:
Static generation where possible. If a page doesn't need to be dynamic, render it at build time. This eliminates server response time entirely for that page.
Edge functions over origin servers. Platforms like Vercel, Netlify, and Cloudflare Workers let you run logic at the CDN edge — milliseconds from the user instead of hundreds of milliseconds away.
Streaming HTML. React 18 and Next.js introduced streaming, which lets the browser start rendering before the server finishes generating the full response. First contentful paint drops dramatically.
Core Web Vitals as deployment criteria. If a PR degrades LCP or CLS significantly, it shouldn't merge. Make performance a quality gate, not an afterthought.
The Conversation with Stakeholders
Translate it to dollars. Your current conversion rate times your traffic times your revenue per conversion — apply the Amazon 1%-per-100ms rule. Even a rough estimate makes the case.
Show the competitive gap. Run your competitors through PageSpeed Insights. If you're losing on Core Web Vitals and they're winning, that's a tangible, fixable disadvantage.
Frame it as SEO. Google uses Core Web Vitals as a ranking factor. Page experience is literally in the algorithm.
The Bottom Line
Fast sites make more money than slow ones. This has been proven repeatedly, across industries, at every scale.
You don't need to rebuild everything. You need to audit honestly, fix the high-impact items first, and treat performance like the business metric it actually is — not a nice-to-have technical detail.
Your users are already telling you with their bounce rate. The question is whether you're listening.
Written by
James Park
Part of the APSLOCK team — building digital experiences that don't just work, but matter.