Website Speed & Core Web Vitals

The three metrics, and the ones that only look like them

Core Web Vitals are Google's documented set of three user-experience measurements, each with a published threshold for a good experience:

Two details get dropped routinely. Assessment is at the 75th percentile of page loads, so a quarter of visitors can have a worse experience while the page passes. And it is segmented across mobile and desktop separately, which is why corporate sites often pass on desktop and fail on mobile.

First Input Delay is retired. INP became a stable Core Web Vital on 12 March 2024, and Chrome tools stopped guaranteeing FID availability after 9 September 2024. An audit still reporting FID is running on stale documentation. Also not Core Web Vitals: Time to First Byte, First Contentful Paint and Total Blocking Time, which Google documents as supporting and diagnostic metrics. Total Blocking Time is lab-only.

Why the lab score and the field data disagree

There are two kinds of measurement and they answer different questions. Lab data comes from a tool loading the page in a simulated environment, such as Lighthouse and the lab section of PageSpeed Insights. Field data comes from real visitors, aggregated in the Chrome User Experience Report and surfaced in PageSpeed Insights and the Search Console Core Web Vitals report.

The gap is structural. Google states plainly that lab measurement is not a substitute for field measurement, and that tools like Lighthouse, which load pages in a simulated environment without a user, cannot measure INP at all. Total Blocking Time is the lab stand-in for interactivity, which is why a page can score well in a lab and still frustrate people who click things.

So a Lighthouse Performance score of 100 does not mean a page passes Core Web Vitals. It produces no INP value, and its LCP and CLS come from one simulated load. B2B sites are especially exposed, because field data requires sufficient real-user traffic and low-traffic pages may have only origin-level data or none at all.

What actually makes corporate sites slow

The cause is rarely the code a developer wrote. The biggest contributors are usually things marketing added, each approved separately and none reviewed since.

• The tag manager container. One tag becomes forty over three years: analytics, remarketing pixels, session replay, testing tools, visitor identification, heat mapping, consent management. Nobody can name the owner of half of them.
• The chat widget. A large third-party bundle, often loaded early because it must appear immediately, and frequently the most expensive script on the page.
• Marketing automation and personalisation scripts. These commonly rewrite content after paint, damaging both loading and stability metrics.
• Web fonts. Several families and weights from a third-party origin, blocking text rendering or swapping late.
• Hero video and oversized hero images. A twelve-megabyte background video is a design decision with a measurable cost, and on mobile it is usually pure waste.

Which makes this a political problem rather than a technical one. Removing the chat widget means telling the sales director their pipeline source is slowing the site down, so bring measured evidence for each script rather than a general appeal to speed.

Layout shift is a content-injection problem

Cumulative Layout Shift is caused almost entirely by things arriving after the page has begun to render and pushing existing content around. The recurring culprits are predictable: a consent banner inserted at the top of the document, a notification bar, images and embeds without declared dimensions, personalisation swapping the hero after it has painted, late-loading fonts changing text metrics, and embeds that size themselves after loading.

The remedy is the same in every case. Reserve the space. Set explicit width and height attributes or an aspect ratio on every image and embed. Give banners and bars a fixed, pre-allocated area, or overlay them rather than inserting them into the flow. Load fonts with a matched fallback so the swap does not change line heights.

This matters commercially more than the score suggests, because the visitor who suffers layout shift is usually the one about to act. A button that moves as somebody reaches for it produces a mis-click on a form, and a mis-click produces an abandoned enquiry.

Rankings, conversion and the honest argument

Website speed is a weak argument for rankings and a strong one for revenue. Be careful which you make, because the ranking case is the one likeliest to be challenged by somebody who has read the documentation.

What is documented is that Core Web Vitals are measures of user experience with published thresholds, assessed on field data at the 75th percentile. No primary source quantifies the ranking benefit of moving a page from failing to passing, and no weighting has been published. On a site of a few hundred pages competing on specialised technical queries, relevance and coverage will move rankings considerably more than shaving half a second off LCP.

The commercial case needs no such help. Paid clicks are billed whether or not the page renders, so every abandoned load converts media spend into nothing. Mobile visitors on poor connections are affected disproportionately, which in many B2B categories describes site visits, field engineers and anyone reading on a train. Framed as enquiries lost and media wasted, the work survives scrutiny that a score never will.

How to prioritise the work

Sequence matters, because performance work has a long tail of low-value effort.

1. Start with field data, segmented by device. Read the Search Console Core Web Vitals report and the field section of PageSpeed Insights before opening any lab tool. If there is no field data, install real-user monitoring; the official web-vitals library reports all three metrics from your own visitors.
2. Pick the pages that matter. The homepage is rarely the problem. Prioritise the templates carrying enquiries: product and solution pages, the contact page, and the top organic landing pages.
3. Identify the LCP element on those templates. Usually a hero image, a heading blocked by a font, or content injected by script. Fix the element, not the score.
4. Audit third parties by measured cost. List every script, name an owner, measure its contribution, and assign each to keep, defer, load on interaction, or remove.
5. Set a performance budget and enforce it at release. A page-weight and script-count ceiling checked in the build pipeline prevents the regression that undoes the project within a year.

Do not target the composite score. Report the three metrics, mobile and desktop separately.

Why marketing cannot fix this alone

Ownership of b2b website performance is split across four groups who rarely meet. Development owns the templates and the build. Marketing owns the tag manager and most third-party scripts. Sales owns the chat widget. Legal or privacy owns the consent banner, often the largest single cause of layout shift and not something you can simply delete. Add a content management platform the marketing team cannot change, and hosting decisions that determine time to first byte, and no single team holds the levers.

Treat it as governance rather than a project. Keep a register of every third-party script with a named owner, a stated purpose and a measured cost. Review it quarterly and delete anything whose owner has left or whose purpose nobody can state. Require any new tag either to replace an existing one or to arrive with a justification.

One honest caveat: below a certain size this does not warrant a programme. A site with a few hundred visits a month and no field data should compress its images, remove the scripts nobody owns, and spend the remaining attention on what its pages say.

Frequently Asked Questions