Most conversations about site speed stall at the Lighthouse score. Someone runs the test, sees an amber 68, and it goes on a backlog behind things with clearer business cases. The problem is that the score is a proxy, and proxies are easy to deprioritise. The underlying number is revenue, and once you calculate it the conversation changes quickly.
The arithmetic nobody does
Take your monthly sessions, your conversion rate and your average order value or lead value. Now apply the relationship that has held across a decade of independent studies: roughly a 7% relative drop in conversion for every additional second of load time, concentrated hardest in the first four seconds.
A store with 60,000 monthly sessions, a 2.1% conversion rate and a $95 average order does about $120,000 a month. If it loads in 5.5 seconds and a competitor loads in 2.5, that three-second gap is worth roughly 20% of conversion — about $24,000 a month, or $288,000 a year. That is not a technical debt item. That is a headcount.
Where the seconds actually go
In our audits the same handful of causes account for the overwhelming majority of slow sites, and almost none of them are the things teams worry about:
- Unoptimised hero images — a single 4MB PNG where a 90KB AVIF would be visually identical.
- Third-party scripts, especially tag managers that have accumulated tags nobody remembers adding.
- Render-blocking web fonts loaded without a swap strategy, leaving text invisible for whole seconds.
- Client-side rendering of content that could have been server-rendered, so users watch a spinner while JavaScript boots.
- Chat widgets and popups that load their entire bundle before the page is interactive.
The single most common fix we ship is deleting things. On the average audit, roughly a third of the JavaScript on the page is doing nothing anybody would miss.
Measure what users feel, not what tools score
Lighthouse runs on a simulated device in a data centre. Your customers are on a three-year-old Android on a train. The gap between those two realities is why sites with respectable lab scores still feel slow in the wild.
Use field data instead. The Chrome User Experience Report shows what real visitors experienced, and Search Console surfaces the same data grouped by page type. Three metrics matter: Largest Contentful Paint (how long until the main content appears), Interaction to Next Paint (how quickly the page responds when tapped), and Cumulative Layout Shift (whether things jump around as it loads).
A realistic order of operations
- Establish the field baseline. You cannot claim an improvement without a before.
- Fix images first — it is usually the largest win for the least effort.
- Audit third-party scripts ruthlessly and delete anything without an owner who will defend it.
- Serve fonts locally with font-display: swap and preload only the weights you actually use.
- Server-render anything above the fold rather than assembling it in the browser.
- Set a performance budget in CI so the gains do not quietly erode over the next two quarters.
That last step is the one teams skip, and it is why so many sites get fast once and then slowly regress. Speed is not a project you finish. It is a constraint you enforce.