Site speed is treated as an engineering concern. It is a revenue concern, and the numbers are unusually direct about it.
Performance work gets deprioritised because it sounds technical. Framed correctly, it is one of the most direct levers on revenue a site has.
The three numbers that matter
LCP — how long until the main content appears. INP — how quickly the page responds when someone interacts. CLS — how much the layout jumps around while loading. Google measures all three from real visitors, and they feed search ranking.
Where the time actually goes
In our experience the order is almost always: unoptimised images, then render-blocking third-party scripts, then oversized JavaScript bundles, then slow server responses. Teams usually attack the last one first because it feels like the real engineering. It rarely is.
What we do by default
Images are served as AVIF or WebP at the size they actually render, with explicit dimensions so nothing shifts. Rendering happens on the server, so the browser gets HTML rather than a loading spinner. Fonts are self-hosted and preloaded. Third-party scripts are audited one by one, and most do not survive the audit.
Measure real visitors, not your laptop
A synthetic score from a fast machine on office fibre tells you very little. Field data from actual users on actual phones on actual mobile networks tells you everything. Optimise against the second one.
- performance
- SEO
- Core Web Vitals
- conversion
