Fixing page experience against the data Google actually uses
Core Web Vitals are three measurements of page experience: LCP for loading, INP for responsiveness and CLS for visual stability. Google assesses them using field data collected from real Chrome users, which is why a site can score well in a lab test and fail the assessment that counts.
Almost every conversation about page speed starts with a lab score, and lab scores are the least relevant number available. A test run from a data centre on a simulated fast connection tells you about the test environment. Google's assessment uses data gathered from the people who actually visit your site, on their devices and their connections.
The gap between the two is where most optimisation effort is wasted. A business chases a lab score from 70 to 95 while its field data barely moves, because the real visitors are on mid-range phones over mobile networks and the lab was not. Meanwhile the actual causes go untouched: an oversized hero image, a font loading late and shifting the layout, a third-party script blocking interaction, and a cookie banner that arrives after the page has visibly settled and moves everything down.
When this work makes sense
Questions worth asking any supplier
Is the work measured against field data or lab scores? Only one of them is what Google assesses.
Which metric is actually failing? LCP, INP and CLS have entirely different causes and fixes.
Has anyone audited third-party scripts? They are frequently the largest single cause and the easiest to defend against removal.
Is the cookie banner measured? Banners injected late are a common and unexamined source of layout shift.
Will the fixes survive the next deployment, or are they manual tuning that regresses?
Deliverables
Field data analysis from Search Console and the Chrome UX Report, by device type
Identification of which metric fails and on which templates
Image work: format, sizing, responsive delivery and priority for the largest element
Font loading strategy that does not shift the layout when the font arrives
Third-party script audit with a recommendation on each, including removal
Layout stability fixes — explicit dimensions, reserved space for late-arriving elements
A performance budget so the improvement does not erode with the next feature
Built with
Process
This work starts from field data segmented by device, not from a lab test. Desktop and mobile frequently fail for entirely different reasons, and a single blended score conceals that. We establish which metric fails on which template for which device class before changing anything, because optimising the wrong metric is the most common way this work produces no measurable result.
The standard nine stages — discovery, strategy, UX/UI, development, content and SEO, testing, launch, measurement, continuous improvement — apply to every project. The paragraph above is what differs for this one.
What moves the number
Pricing depends on scope, functionality, integrations and content requirements. These are the factors that change it most:
Quick wins, template rework, or architectural change
Quick wins
Fits: Sites failing on images, fonts or a single heavy script
Limits: Bounded — if the architecture is the problem, this only moves the numbers slightly
Template rework
Fits: Sites where specific page types fail consistently
Limits: Requires development time and regression testing across the affected templates
Architectural change
Fits: Client-rendered sites where responsiveness is structurally poor
Limits: Effectively a rebuild of how the site renders; the largest intervention available
Case studies
No published Core Web Vitals case study. Before and after score screenshots are trivially easy to produce from a lab test and prove very little about field performance.
MBGDesk operates from 4 offices — India, United States, United Kingdom, United Arab Emirates. We hold no industry certifications and do not imply otherwise.
Frequently asked questions
Our Lighthouse score is 95 but Search Console says we fail.
That is the expected disagreement. Lighthouse runs a simulated test on the machine you run it from. Search Console reports field data from real visitors, on their devices and networks. When they disagree, the field data is the one Google uses.
What is INP and what happened to FID?
Interaction to Next Paint replaced First Input Delay as a Core Web Vital in March 2024. FID measured only the delay before the first interaction was processed. INP measures responsiveness across the whole visit, which is considerably harder to pass and a fairer reflection of how the page feels.
How much do Core Web Vitals affect rankings?
They are a ranking signal among many, and relevance matters more. A fast irrelevant page does not outrank a slow relevant one. Where competitors are closely matched on relevance, page experience can be the difference — and it affects conversion regardless of ranking.
Can we pass without changing our platform?
Usually. Most failures come from images, fonts, third-party scripts and layout shift, all of which are addressable within a platform. Structural failure — where responsiveness is poor because of how the site renders — is the case that needs more.
Our marketing team keeps adding tracking scripts.
That is the most common cause of regression, and it is a governance problem rather than a technical one. A performance budget gives the team a number to check against before adding something, which turns it into a decision rather than an accumulation.
What is a realistic target?
LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1, at the 75th percentile of real visits. The percentile matters — it means three quarters of your visitors must have that experience, not your average visitor.
Services that connect to this
Talk to us about this
Tell us what you are trying to build and we will come back with scope, approach and an estimate.