Your Website Doesn't Have a Design Problem. It Has a Speed Problem

Most founders test their website on office Wi-Fi, from a fast laptop. Their customers visit on a mid-range phone, on mobile data, halfway through a commute. That gap — between the machine you built on and the machine your customer actually uses — is where the money quietly leaks.

A slow website is not a design issue. It is a sales issue. And unlike a redesign, it is measurable, fixable, and cheap to prove.

What a slow page actually costs

The numbers here are not guesses. They come from studies with real traffic behind them:

• Deloitte and Google, "Milliseconds Make Millions" (2020) — across 37 brands and roughly 30 million mobile sessions, a 0.1-second improvement in mobile site speed was linked to 8.4% higher retail conversions and 9.2% higher average order value. Travel conversions rose 10.1% for the same tenth of a second.
• Portent (2022) — across more than 27,000 landing pages, ecommerce conversion sat at 3.05% on pages loading in one second, fell to 1.68% at two seconds, and 1.12% at three. A one-second page converted about 2.5 times better than a five-second one for ecommerce, and three times better for B2B lead generation.
• Akamai (2017) — a 100-millisecond delay in load time was associated with a 7% drop in conversion rate, measured across roughly 10 billion retail site visits.
• Google / SOASTA (2017) — as page load time rises from one second to three, the probability of a bounce increases by 32%. From one to five seconds, it jumps 90%.

Read those together and the conclusion is unavoidable: nobody changed the offer, the pricing, or the copy. Only the loading time. And the loading time moved the revenue line.

The honest caveat: these are large observational studies, not randomised trials. Treat the magnitudes as directional, not as a guarantee for your site. But the direction has been consistent for a decade, across every study that measured it.

Why your Lighthouse score can be green and your site still feels slow

Here is the trap most teams fall into: they optimise for the lab and ignore the field.

Lighthouse runs on a fast machine with a throttled connection. Your users run on real phones, real networks, real CPUs. Google knows this, which is why it judges Core Web Vitals on field data at the 75th percentile — the experience of your slowest quarter of visitors, not your best test run.

The three thresholds, current since March 2024:

• LCP (Largest Contentful Paint) — main content visible within 2.5 seconds
• INP (Interaction to Next Paint) — interaction response under 200 milliseconds
• CLS (Cumulative Layout Shift) — layout shift under 0.1

INP is the one most teams miss. It replaced First Input Delay in 2024, and it grades your worst interaction, not your first. A page can paint in 0.8 seconds and then lock up for two more while hydration freezes the main thread. The HTML arrived. The brain didn't.

That is the most common failure mode I see in modern sites: a beautiful page that paints fast, then ignores clicks while 400KB of JavaScript hydrates a "Read more" button. Lighthouse goes green. The user leaves.

Measure where your customers actually are

Stop testing on your own laptop. Start measuring the field.

The simplest honest check is free: open Chrome DevTools, run a performance trace on a mid-range Android profile with 4G throttling, and watch what happens after the first paint. Better still, read your real field data in the Chrome UX Report or PageSpeed Insights — it shows the 75th-percentile numbers your actual visitors experience.

If you want a number you can track in code, the web-vitals library gives you the real metrics from real sessions:

import { onLCP, onINP, onCLS } from 'web-vitals';

function sendToAnalytics(metric) {
  // metric.name: 'LCP' | 'INP' | 'CLS'
  // metric.value: the real field value, in milliseconds (or score for CLS)
  console.log(metric.name, Math.round(metric.value));
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

One line of instrumentation beats a hundred lab runs. It tells you what your customers feel, not what your test rig pretends.

The fixes that actually move the number

Speed work is not mysterious. The same five fixes cover most sites I audit:

1. Ship HTML first, hydrate only what's interactive. Server-render the page. Then hydrate selectively — the checkout button, the search box — and leave the rest as plain HTML. A static hero does not need a framework runtime.

// Don't hydrate the whole page. Hydrate the island that needs it.
import { lazy, Suspense } from 'react';

const CheckoutButton = lazy(() => import('./CheckoutButton'));

export default function ProductPage() {
  return (
    <main>
      {/* Static HTML: ships instantly, no JS needed */}
      <h1>Wireless Headphones</h1>
      <p>40-hour battery. Noise cancelling.</p>

      {/* Only this island gets JavaScript */}
      <Suspense fallback={<button disabled>Loading…</button>}>
        <CheckoutButton />
      </Suspense>
    </main>
  );
}

2. Kill the JavaScript you don't use. Audit your bundle. Third-party scripts — chat widgets, analytics, tag managers — are usually the biggest single chunk. Every script you remove is speed you never have to optimise.

3. Serve images like it's 2026. Modern formats (AVIF/WebP), responsive sizes, loading="lazy" below the fold, and explicit width/height so the layout never jumps:

<img
  src="hero.avif"
  srcset="hero-480.avif 480w, hero-800.avif 800w, hero-1200.avif 1200w"
  sizes="(max-width: 600px) 480px, 800px"
  width="1200"
  height="630"
  alt="Product hero shot"
  fetchpriority="high"
/>

4. Stop the layout shift. Reserve space for everything that loads late — images, ads, embeds. A CLS under 0.1 is mostly a discipline problem, not a technical one.

5. Fix your fonts and your third parties. Use font-display: swap, preload only the one font weight you actually render above the fold, and load every third-party script with defer or after interaction. A chat widget that blocks rendering is a tax on every visitor for the benefit of the few who chat.

The 30-minute speed audit

Do this today, before you touch a redesign:

1. Run PageSpeed Insights on your homepage, your top landing page, and your checkout — read the field data, not the lab score.
2. Note which Core Web Vital fails at the 75th percentile.
3. Open DevTools, throttle to 4G, and click the main call-to-action. Time how long until it responds.
4. List every third-party script on the page. Delete one.
5. Check your largest image: is it AVIF/WebP, correctly sized, and lazy-loaded below the fold?

Most sites find their biggest win in step 3 or 4. The fix is usually deletion, not addition.

Speed is a sales metric

A homepage that takes over three seconds on real mobile is not a design problem. It is a leak in the funnel, and it compounds: every ad click you buy lands on the same slow page, every SEO ranking you earn sends visitors into the same wait.

The founders who win this are not the ones with the prettiest site. They are the ones who measured on the device their customers actually hold, fixed the worst interaction first, and treated a tenth of a second as revenue — because the data says it is.

When did you last load your own website on mobile data?

---

I break down systems like this daily — web performance, AI automation, and the technical decisions that actually move revenue. Follow for more.

Sources: Deloitte & Google, "Milliseconds Make Millions" (2020); Portent, Site Speed and Conversion Rate research (updated 2022); Akamai, "State of Online Retail Performance" (2017); Google/SOASTA Research (2017); web.dev Core Web Vitals thresholds (2024).