What Slow Pages Actually Cost You (Beyond the Lighthouse Score)

Performance work attracts two equally unhelpful positions. One treats a perfect Lighthouse score as an end in itself. The other dismisses speed entirely because Google says it is a minor ranking factor.

Both miss the point. Speed is a weak ranking signal and a strong conversion signal, and those two facts justify completely different amounts of investment.

The ranking question, settled

Google has been consistent for years: page experience is a tiebreaker between pages of comparable relevance, not a substitute for being relevant. A fast page with mediocre content does not outrank a slow page with excellent content.

So if your goal is ranking, performance is somewhere near the bottom of the list - well behind whether the content actually answers the query and whether anyone links to it.

If that were the whole story, most performance work would not be worth funding.

The conversion question, which is the real one

The conversion effect is larger and more direct, and it does not depend on anyone’s ranking algorithm.

The mechanism is simply that people leave. Every second of delay before a page becomes usable loses some portion of visitors, and the loss compounds through the funnel - fewer people see the offer, fewer reach the form, fewer submit it. The effect is most pronounced on mobile, on slower connections, and on first visits where nothing is cached.

Two things follow from this that change where you should spend.

The 75th percentile is the number that matters. Averages hide the problem. If your median load is 1.8 seconds and your 75th percentile is 6 seconds, a quarter of your visitors are having an experience you have never personally had. That quarter is disproportionately mobile users on real networks - often exactly the segment you are paying to acquire.

Speed matters most where intent is highest. A slow blog post loses a reader. A slow quote form or checkout loses revenue directly. Performance budget should follow money, not traffic.

Where the time actually goes

Audits of business websites tend to find the same three culprits, and none of them are the framework.

Images. Consistently the largest single contributor. Uncompressed, served at desktop dimensions to mobile devices, in formats a decade out of date, and loaded eagerly whether or not they are on screen. Modern formats and correct sizing routinely cut page weight by more than half, and it is close to a configuration change on most platforms.

Third-party scripts. Analytics, tag managers, chat widgets, heatmaps, A/B testing tools, three ad pixels and a cookie banner. Each one added by a different person for a good reason, none ever removed. These frequently account for more blocking time than all of your own code combined.

The useful exercise: list every third-party script, name the person who would notice if it disappeared, and remove the ones with no name against them. This usually produces a bigger improvement than any code change, and costs nothing.

Layout shift. Content jumping as images and fonts load. This is less a speed problem than a usability one - users misclick, forms lose focus, and the page feels broken even when it is fast. Fixing it is mostly a matter of reserving space for elements before they load.

What not to do first

Do not rebuild the site to fix performance. This is the most expensive available solution and it rarely addresses the actual cause. A site with unoptimised images and fourteen third-party scripts will be slow on any framework. Rewriting moves the problem into a new codebase along with a new set of bugs.

There are legitimate cases - a platform that genuinely prevents modern image formats or forces render-blocking resources. But that conclusion should come from an audit, not from a rewrite proposal. If someone recommends a rebuild before measuring, they are quoting for the project they wanted rather than the problem you have. The same dynamic shows up throughout development quoting.

Do not optimise for the lab score. Lighthouse is a diagnostic run under simulated conditions on your machine. It is useful for finding problems and misleading as a target, because it is easy to improve the score without improving anyone’s actual experience. Use field data from real users as the source of truth and lab tools to investigate why.

A sensible order of work

1. Get field data. Real users, 75th percentile, segmented by device. Until you have this, you are guessing.
2. Audit third-party scripts. Remove the unowned ones. Free, fast, usually the largest single win.
3. Fix images. Modern formats, correct dimensions per breakpoint, lazy-load below the fold.
4. Reserve space for dynamic content. Kills layout shift.
5. Defer non-critical JavaScript. Most of it does not need to block first render.
6. Measure again. Then decide whether anything structural is left.

Most business sites reach acceptable performance somewhere around step 3, having spent very little. The teams that end up spending heavily are usually the ones who started at step 6.

The connection to everything else

Performance sits at an awkward intersection: marketing owns the outcome, engineering owns the fix, and neither owns the priority. That is why it tends to be either ignored or over-corrected with a rewrite.

The framing that resolves it is to treat page speed as part of the conversion path rather than as a technical hygiene metric. It belongs in the same conversation as form design and offer clarity, and it should be funded from the same budget as the traffic you are buying - because slow pages are, precisely, a tax on acquisition spend.

That is also why it shows up as a revenue issue in industries where buyers self-qualify online before ever contacting you, as B2B manufacturers have been discovering. If the buyer never reaches your specification pages, none of the rest of the funnel gets a turn.

One last note on sequencing. If performance problems are severe enough that a rebuild genuinely is the answer, scope it against real numbers rather than a vague “modernisation” brief - what custom builds actually cost covers the tiers, and the difference between a targeted rebuild and an open-ended one is usually a factor of three.