Core Web Vitals Are a Business Metric, Not an Engineering One
Page speed is usually filed under engineering housekeeping. It belongs on the same dashboard as conversion rate — and treated as a budget, not a one-off audit.
Almost every organisation we work with has run a Lighthouse report at some point. Far fewer have a number they are actually holding themselves to. That gap is the whole problem: performance measured once is trivia, performance measured continuously is a constraint that changes what gets built.
Why a single audit does nothing
A performance audit captures one moment, usually on a developer's machine, usually on a page that happens to be simple. The result gets circulated, a few images get compressed, and six months later the site is slower than it was before the audit — because in the interim three analytics scripts, a chat widget and a font variant were added, and nobody was measuring.
The fix is not a better audit. It is moving the measurement into the pipeline, so a regression fails a build in the same way a broken test does.
Setting a budget you will actually enforce
A performance budget is a small set of numbers agreed before the work starts. Ours usually look something like this:
- Largest Contentful Paint under 2.5 seconds on a mid-tier mobile device over a throttled connection
- Interaction to Next Paint under 200 milliseconds
- Cumulative Layout Shift under 0.1
- A hard ceiling on JavaScript shipped to the browser on the critical path
The exact figures matter less than the fact that they exist and that something automated checks them. Once a budget is in CI, the conversation about whether to add another third-party script changes character entirely — it stops being a matter of preference and becomes a matter of what fits.
Where the business case sits
Speed affects two things a business cares about directly. First, conversion: every additional second before a page becomes usable loses some proportion of visitors who were never going to wait. Second, search: page experience is a ranking input, and the pages that load quickly are the pages that get crawled more thoroughly.
If nobody can name the current LCP of your highest-traffic page, performance is not being managed — it is being hoped for.
Practical starting points
- Instrument real-user monitoring before optimising anything, so you know what actual visitors experience rather than what your laptop does
- Render as much as possible on the server; ship interactivity only where the page genuinely needs it
- Reserve layout space for images, embeds and ads so late-loading content cannot shift what someone is reading
- Self-host fonts, subset them, and limit the number of weights in the design system
- Audit third-party scripts quarterly and remove the ones nobody can justify
None of this is exotic. It is ordinary engineering discipline applied to a metric that most teams have decided is somebody else's concern.
The Cherbix Team
Engineering & editorial
Written and reviewed by the Cherbix engineers who do this work day to day — the same people who build the software, run the migrations and wire up the automation described here.