What the three Core Web Vitals measure
Google's current Core Web Vitals are Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. They are deliberately centred on things a visitor can experience rather than an abstract measure of how much code a page contains.
Largest Contentful Paint, or LCP, measures when the largest visible image, text block or video in the viewport is rendered. Google classifies 2.5 seconds or less as good. An LCP problem can begin before the browser even receives the page, so image compression alone will not fix a slow server or delayed HTML response.
Interaction to Next Paint, or INP, measures responsiveness to clicks, taps and keyboard interactions across a visit. A good INP is 200 milliseconds or less. Heavy JavaScript, long main-thread tasks and expensive interface updates are common causes of poor responsiveness.
Cumulative Layout Shift, or CLS, measures unexpected movement of visible content. A good CLS is 0.1 or less. Images without reserved dimensions, dynamically inserted content and font changes are typical causes.
Core Web Vitals thresholds and the 75th percentile
The headline thresholds only make sense when the measurement method is understood. Google recommends assessing Core Web Vitals at the 75th percentile of page loads, separately for mobile and desktop.
- LCP: good at 2.5 seconds or less, needs improvement above 2.5 seconds and up to 4 seconds, poor above 4 seconds.
- INP: good at 200 milliseconds or less, needs improvement above 200 milliseconds and up to 500 milliseconds, poor above 500 milliseconds.
- CLS: good at 0.1 or less, needs improvement above 0.1 and up to 0.25, poor above 0.25.
Search Console uses real-world Chrome user data and groups similar URLs. Google notes that only indexed URLs can appear in its Core Web Vitals report and that pages without sufficient reporting data may be omitted.
Chrome UX Report data is aggregated across a rolling 28-day period. That matters after a repair: a Lighthouse test can show an immediate improvement while the Search Console status still contains data gathered before the change.
Why Lighthouse and Search Console can disagree
This is one of the most common sources of confusion in performance work. Lighthouse is a laboratory test. It loads a page under a controlled set of conditions and produces diagnostics that can be reproduced during development. Search Console reports field data derived from eligible real Chrome users.
The two answer different questions. Lighthouse can tell you that a hero image is requested too late, JavaScript is blocking the main thread or an image lacks suitable dimensions. Field data tells you what eligible visitors actually experienced across different devices, networks and visits.
A page can therefore score well in Lighthouse and still have poor field data, particularly if real visitors use slower devices, encounter different content or exercise interactions that a synthetic page-load test does not reproduce. The reverse can also happen where a single laboratory run encounters an unusually slow response.
Use our page speed checker for an initial Lighthouse test, then compare the result with available Search Console or Chrome UX Report data before deciding what needs attention.
How Core Web Vitals problems are fixed
The metric identifies the symptom. The engineering work is finding the cause.
For LCP, we first identify the actual LCP element. If it is an image, useful changes may include correct dimensions, compression, a more efficient format, earlier discovery or removing unnecessary lazy loading from an above-the-fold asset. If Time to First Byte is already slow, the investigation moves backwards to hosting, caching, PHP execution or application work before the HTML is returned.
For INP, the important evidence is what occupies the main thread around a slow interaction. Large JavaScript tasks may need breaking up or removing. Third-party scripts and framework code can contribute just as much as custom code. The aim is not merely to make the initial page load lighter, but to allow the browser to respond promptly when somebody actually uses the interface.
For CLS, the browser needs enough information to reserve the right amount of space before content arrives. Images, embeds and other media should have predictable dimensions. Dynamically inserted banners need careful placement, and web-font behaviour should be checked where a font swap changes text dimensions.
Our website speed optimisation service applies these changes as part of the £449 Website Speed Fix where they are relevant to the diagnosed problem.
Core Web Vitals and Google Search
Google states that Core Web Vitals are used by its ranking systems and recommends achieving good results for Search and for user experience. That does not mean a site moves up the rankings simply because three numbers turn green.
Google also states that there is no single page experience signal. Its systems consider many signals, and relevant content can still rank even when page experience is not ideal. It specifically warns against chasing a perfect performance score purely for SEO.
That makes the practical priority straightforward: fix a poor experience because visitors benefit from faster loading, quicker responses and a stable layout. Treat any search benefit as part of the wider technical picture rather than a guaranteed outcome.
This also affects prioritisation. A page with an LCP of 2.7 seconds does not automatically deserve more engineering time than a checkout button with severe interaction delay. Metrics should direct investigation, not replace judgement about what visitors are trying to do.
Keeping Core Web Vitals healthy after the fix
Performance is not necessarily permanent. A new tracking script can affect INP, a redesigned hero can change LCP and an unreserved promotional banner can introduce CLS. WordPress plugins, theme releases and ordinary content editing can all change the loading path without anybody intending to make the site slower.
The one-off Website Speed Fix is £449 and includes an audit, targeted optimisation and before and after reporting. It carries the published money-back promise where we cannot demonstrate measurable speed improvement.
For frequently changing sites, the £89 per month or £890 per year Speed Retainer adds monthly Lighthouse and CrUX review, ongoing image and script optimisation, plugin bloat control, performance reporting and regression fixes.
If the problem is specifically WordPress, see WordPress speed optimisation for the platform-specific causes we check.