Site Speed and Core Web Vitals

Lab scores and field data are different things

Lighthouse runs a simulation on a specified connection and device. It is excellent for debugging and misleading as a target, because your visitors are not that device on that connection.

Field data — the Chrome User Experience Report, and real user monitoring if you have it — records what actually happened to real people. When lab and field disagree, field wins. We have seen sites with a 95 lab score failing Core Web Vitals in the field because most of their traffic was mid-range Android on mobile networks.

Diagnosing against field data first means fixing what people experience, rather than what a simulation experienced.

The three metrics, and what actually causes them

Largest Contentful Paint

How long until the main content appears. Usually caused by a hero image with no priority hint, render-blocking CSS or fonts, or a slow server response. On image-led sites it is almost always the hero.

Interaction to Next Paint

How quickly the page responds when someone taps. This replaced First Input Delay and is stricter. The cause is nearly always JavaScript occupying the main thread — frequently third-party scripts nobody has audited in two years.

Cumulative Layout Shift

Content moving as the page loads. Images without dimensions, injected banners, and fonts swapping late. This is the one visitors notice most, because it makes people tap the wrong thing.

Third-party scripts are usually the problem

Most slow sites are not slow because of their own code. They are slow because of accumulated tags — analytics, chat widgets, heatmaps, review embeds, consent tools, and abandoned marketing pixels from campaigns that ended years ago.

An audit of what each tag costs, in milliseconds and in blocking time, is usually the fastest available win. Removing three unused scripts routinely does more than a week of code optimisation.

What we do

• Field data diagnosis before any lab testing
• Third-party script audit — including the measurement tags — with a measured cost per tag
• Image strategy: formats, sizing, priority hints and lazy loading
• Font loading that does not cause layout shift
• Render-blocking resource elimination
• Caching and server response work
• Prioritised fix list scored by effort against expected effect

Mobile is the measurement that counts

Core Web Vitals are assessed primarily on mobile, and mobile is where most UK consumer traffic arrives. A site that performs well on a desktop connection and poorly on a mid-range phone is failing the test that matters.

The gap is usually larger than teams expect, because everyone tests on a recent phone on office wifi. Testing on a throttled connection and a mid-tier Android device is uncomfortable and honest.

Keeping it fast afterwards

Speed work decays. A site optimised properly will drift back within a year as tags accumulate, images get uploaded at full resolution, and plugins are added without review.

What prevents it: a performance budget agreed in writing, a check before any new third-party script goes live, and image handling that resizes automatically rather than depending on whoever uploads. We set those up as part of the work, because a one-off fix with no guardrails is a fix you pay for twice.

Speed as a ranking factor, in proportion

Core Web Vitals are a ranking signal and a weak one next to relevance and authority. A fast page about the wrong thing will not outrank a slower page that answers the question.

Where speed genuinely pays is conversion. The gap between a two-second and a five-second load shows up in completed forms and abandoned baskets far more visibly than in rankings. We will tell you plainly whether speed is your ranking problem — usually it is not — while still recommending the work on its commercial merits.