Most slow websites did not become slow through one bad decision. They became slow the way budgets get overspent: a marketing tag here, a carousel library there, a hero video nobody measured, until one day the site that used to feel instant takes four seconds to show its main content on a mid-range phone. Nobody owns the regression, because nobody was measuring for it.

That is why performance deserves to be treated as an engineering discipline rather than a launch-week cleanup. Like security or accessibility, it needs a yardstick, a budget, and enforcement — or it quietly erodes.

The yardstick: Core Web Vitals

Google's Core Web Vitals are the closest thing the industry has to an agreed measure of user-perceived speed. Three metrics, each answering a plain question:

  • LCP (Largest Contentful Paint) — how long until the main content is visible? "Good" is roughly 2.5 seconds or less.
  • INP (Interaction to Next Paint) — when the user taps or clicks, how long until the page visibly responds? Roughly 200 milliseconds or less is the target. INP replaced the older FID metric in March 2024, and it is a stricter judge: it considers interactions throughout the visit, not just the first one.
  • CLS (Cumulative Layout Shift) — does content jump around while loading? A score of roughly 0.1 or less counts as good.

As of early 2026, those thresholds are assessed at the 75th percentile of real visits, with mobile and desktop judged separately. That framing matters: your site is graded on what most of your actual users experience on their actual devices and networks, not on what your development machine reports over office fibre.

Why this is a revenue and SEO issue, not vanity

Performance work is sometimes dismissed as engineers polishing numbers. The commercial evidence points the other way. Retailers and publishers who have run their own experiments consistently find that faster pages convert better and that abandonment climbs steeply with every additional second of loading; the effect is strongest on mobile, where most first visits now happen. I will not quote a universal percentage, because it varies by sector and baseline, but the direction is not in dispute.

There is also the search dimension. Core Web Vitals feed into Google's page-experience signals. This is a modest ranking factor, not a magic lever — content and relevance still dominate — but in competitive niches where content quality is comparable, the faster site has the edge. And your field data is public: anyone can look up your domain's Core Web Vitals in the Chrome User Experience Report and compare you with a competitor. Prospective clients occasionally do exactly that.

Where business sites actually lose their speed

Across audits, the same culprits appear again and again:

  • Unbounded JavaScript. Frameworks, polyfills and utility libraries accumulate; nobody deletes. Every kilobyte must be downloaded, parsed and executed, and long main-thread tasks are the single most common reason for poor INP.
  • Third-party tags. Analytics, chat widgets, session recorders, A/B testing tools, consent managers — each added by a different stakeholder, each "just one script". Collectively they often outweigh the site's own code, and you do not control their release cycles.
  • Unoptimised images. Full-resolution photos scaled down in CSS, no modern formats such as AVIF or WebP, no lazy loading below the fold, and missing width and height attributes — the last of which causes layout shift as well.
  • Fonts. Several weights of a webfont, blocking render or swapping in late and shifting the layout under the reader.

None of this needs exotic engineering to fix. It needs someone to be accountable for it.

The discipline: a performance budget enforced in CI

A performance budget is a set of hard limits agreed in advance: total JavaScript per page, image weight, time to LCP on a throttled connection, perhaps a minimum Lighthouse score. The enforcement is the point. A budget in a wiki is a wish; a budget in the CI pipeline is policy.

The mechanics are unglamorous and effective: a Lighthouse CI run or a bundle-size check on every pull request, compared against a budget file committed to the repository. Exceed the limit and the build fails, exactly as it would for a broken test. The conversation then happens at the right moment — "this dependency costs a third of our script budget; is the feature worth it?" — instead of six months later, when the homepage has doubled in weight and no single commit is to blame.

Lab data, field data, and a path for a small team

Lab tools such as Lighthouse, WebPageTest and the browser's own profiler run your page under controlled conditions. They are ideal for diagnosis and for CI, because results are reproducible. But they describe a synthetic visitor. Field data — real-user monitoring, or RUM — records what actual visitors experienced, and it is what Google's assessment is based on. The two disagree constantly, and the field is the truth: a page that scores well in the lab can still fail INP in the field, because real users interact mid-load on slower phones.

For a small team, a pragmatic adoption path looks like this:

  • Establish the baseline. Check the field data for your key pages in PageSpeed Insights; if traffic is too low for field data, run lab tests with mobile throttling and treat those as the reference.
  • Fix the obvious first. Image formats and sizing, font loading, deferring non-critical scripts. This is usually where most of the gain sits.
  • Audit the third parties. List every tag, name an owner for each, remove the orphans. Often harder politically than technically.
  • Set the budget and wire it into CI, so that regressions fail loudly instead of accumulating silently.
  • Add lightweight RUM — the open-source web-vitals library posting to an endpoint you already run is enough — and review the trend monthly.

None of these steps requires a dedicated performance team. They require a few focused days and, above all, the decision that speed is a requirement rather than an aspiration. If you would like an outside pair of eyes to establish the baseline, negotiate the budget with your stakeholders, and wire the enforcement into your pipeline, that is precisely the kind of work I take on.