# Speed kills: what a slow website is costing you

> Every 100ms of load time reduces conversions by ~1%. We show you how to find and fix the slowest parts of your stack.

Source: https://areza.digital/blog/speed-kills-slow-sites
Published: 2026-02-12
Category: Performance

---


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.


---

## Related

- [Blog](https://areza.digital/blog)
- [Contact](https://areza.digital/contact)