Ninety-five in Lighthouse. Failing in the field. Both true.

They are a genuine but modest ranking input, and pretending otherwise in either direction wastes money. A slow site rarely fails because of speed alone, and a fast site does not rank on speed. What makes the work worth doing is the second effect: speed changes conversion rates measurably, particularly on mobile, so a CWV project usually pays for itself commercially before any ranking benefit appears. We sell it on that basis and let rankings be the bonus.

Because Google ranks on CrUX field data, real Chrome users on real devices and connections, while Lighthouse runs a simulated lab test on a throttled desktop profile. Sites routinely score 95 in Lighthouse and fail Core Web Vitals in the field, usually because real users are on mid-range Android phones with slower networks and your test machine is not. Every engagement here starts and ends with field data; lab tools are diagnostics, not scores to chase.

Almost always one of four things: a slow server response (TTFB, frequently cheap hosting or uncached dynamic pages), render-blocking CSS and fonts delaying paint, hero images that are unoptimised, wrongly sized or lazy-loaded when they should be prioritised, and client-side rendering that leaves the main content until after JavaScript executes. The diagnosis order matters, front-end tuning cannot rescue a 900ms TTFB, and plenty of agencies sell image compression to sites whose real problem is their hosting.

Interaction to Next Paint replaced First Input Delay as the responsiveness metric and measures every interaction rather than just the first, which exposed sites that felt fine on load and stuttered thereafter. The usual culprits are heavy JavaScript execution on the main thread, oversized third-party tag stacks (analytics, chat widgets, A/B tools, ad scripts), and hydration cost on JavaScript frameworks. Fixing INP is mostly about doing less work in the main thread, which means auditing what you have loaded and why.

By reserving space for everything that arrives late: explicit dimensions on images and embeds, font-loading strategies that avoid reflow, ad and widget slots with fixed sizes, and no content injected above existing content after paint (cookie banners and promotional bars are the classic offenders). CLS is usually the cheapest of the three to fix and the most visible to users, who experience it as the page moving under their thumb.

On most sites, moving from failing to passing across all three metrics is achievable within a project, occasionally not without platform-level change (some page builders and template systems impose ceilings, which we quantify honestly rather than pretending optimisation is infinite). We report expected outcomes as ranges tied to specific fixes, and we report field-data movement over the following weeks, because CrUX updates on a 28-day rolling window and instant verification is not possible.

Diagnostic and remediation plans from £700. Implementation projects typically £1,500-£4,000 depending on stack and severity, and we can implement directly on most stacks rather than handing over a document. Ongoing performance monitoring sits inside technical retainers, because speed regresses with every release unless someone is watching.