Speed kills: what a slow website is costing you

Load time is a revenue number. Not a technical metric — a revenue number. Amazon has reported that every 100ms of additional latency costs 1% in sales. Google's own data shows bounce rate increases 32% when page load goes from 1s to 3s.

Your site is probably slow in ways you haven't measured.

The actual numbers

Largest Contentful Paint (LCP) is the metric that correlates most strongly with conversion. Google's threshold:

• Good: under 2.5s
• Needs improvement: 2.5s–4s
• Poor: over 4s

Most business websites we audit sit in the 3–6s range. The gap between 6s and 2s isn't a design win — it's a conversion rate win that shows up in revenue.

Where time goes

Images — unoptimized images are the most common culprit. A 4MB hero image served to mobile users is a 4MB tax on every first impression.

Third-party scripts — analytics, chat widgets, ad pixels. Each one blocks rendering. A typical marketing site loads 8–12 third-party scripts.

Render-blocking resources — CSS and JS loaded in the document head that block the browser from painting anything.

Server response time (TTFB) — if your server takes 800ms to respond, no amount of frontend optimization closes that gap.

Client-side rendering — SPAs that ship a blank HTML page and then hydrate are inherently slow on first load.

The fix stack

For most sites, the highest-leverage fixes in order:

1. Move to a CDN-edge runtime — Vercel, Cloudflare Pages, or similar. Sub-100ms TTFB globally.
2. Serve optimized images — use next/image or Cloudflare Image Resizing. WebP, correct dimensions, lazy loading.
3. Defer non-critical scripts — load analytics and chat widgets after the page is interactive.
4. Eliminate render-blocking CSS — inline critical CSS, defer the rest.
5. Switch to server rendering — pre-render HTML so users see content immediately.

Measuring correctly

Don't test performance from your office on a fast machine. Use:

• WebPageTest with a 4G throttled mobile connection
• Lighthouse CI in your build pipeline to catch regressions
• Core Web Vitals in Google Search Console for real-user data

The goal is to be visibly fast on a mid-range Android phone on a congested mobile network. Everything else is optimizing for an audience that wouldn't notice anyway.