Skip to content
LUIGI MICCA

Published

4 min read

Your website's speed is a business number

Slow pages don't feel slow in the office — they feel slow at checkout, on a phone, on hotel Wi-Fi. How speed quietly taxes revenue, how to measure it like Google does, and what actually moves the needle.

Nobody's website is slow on the office Wi-Fi, on a developer's laptop, freshly cached. It's slow on a three-year-old Android, on mobile data, held by someone who has never visited before — which is to say: it's slow exactly where your next customer lives.

I've spent years making storefronts and web apps fast, and the pattern is always the same: speed is treated as a technical nicety until someone puts it next to a revenue number. Then it becomes urgent. Let's skip to that part.

The tax you don't see on any invoice

Page speed charges you three times:

  • Conversion. The relationship is brutally consistent across every study and every project I've measured: as load time grows from one second to three, a meaningful share of visitors simply leaves. On paid traffic this is money burned twice — you paid for the click and for the bounce.
  • SEO. Core Web Vitals are a ranking signal, and more importantly they gate how Google's crawler experiences you. You rarely see a "penalty"; you see competitors quietly outranking you on queries you used to own.
  • Perception. A site that responds instantly reads as competent. One that stutters reads as neglected — and visitors extend that judgement to the business behind it. Unfair, universal, measurable.

Measure it like Google does, not like your laptop does

The single most common mistake: judging speed by how the site feels to you, or by a lab score run from a fast machine. Two rules fix this.

Use field data first. Google publishes what real Chrome users actually experienced on your site — the Chrome UX Report, surfaced in PageSpeed Insights under "Discover what your real users are experiencing". That's the number that ranks you, and the number that matches your customers' reality.

Watch three metrics. LCP (when the main content appears — aim under 2.5s), INP (how fast the page reacts to taps and clicks — under 200ms), CLS (how much the layout jumps around — under 0.1). Everything else is diagnostics; these three are the verdict.

If your field data is green, congratulations — close this tab. If it's amber or red on mobile, that's not a technical detail. That's the tax from the previous section, running daily.

What actually moves the needle

After years of performance work, the honest ranking of fixes by impact-per-euro:

  1. Images. Still the number one offender on most sites: oversized, unoptimised, loaded all at once. Modern formats, correct sizes per device and lazy loading below the fold routinely cut page weight by more than half. Boring, effective, cheap.
  2. JavaScript. Every marketing tag, chat widget and carousel library rides on your customer's CPU. The fastest JavaScript is the JavaScript you delete; what remains should load after the content, not before it.
  3. Fonts. Two families, the weights you actually use, self-hosted and preloaded. Fonts are why so many sites flash, jump or show invisible text for a full second.
  4. The architecture. The ceiling on everything above. A page that must consult a slow server on every visit starts losing before the first byte arrives; a page served pre-built from a CDN starts from near zero. This is the difference you decide once, when the site is built — which is why speed is cheapest on day one and priciest as a retrofit.

Notice what's not high on the list: switching hosting providers, "performance plugins", and most of what gets sold as a quick fix.

The uncomfortable summary

A slow site is rarely slow for mysterious reasons. It's slow because speed was nobody's requirement — not in the brief, not in the contract, not in the acceptance checklist. The fix starts there: write it down. "Core Web Vitals green in field data, on mobile" is one line in a project brief, and it changes every technical decision made after it.

(This site loads in well under a second on a mid-range phone. Not because it's small — because that line was in its brief.)

I build websites and web applications with performance budgets written into the contract, and I audit existing sites that have grown slow. If your field data is amber — or you've never looked — let's talk: a 30-minute intro call is free, and I'll tell you honestly whether it's a one-day fix or an architecture problem.