Core Web Vitals are the loading, interactivity and visual-stability metrics Google uses as a ranking signal, and they are assessed on field data: the experience of your real visitors, not a lab test. That is why a perfect Lighthouse score can sit next to a failing Search Console report. Lighthouse runs one synthetic page load from a single data centre on a fixed connection, so it tells you what is possible under ideal conditions. Google's ranking assessment instead reads the 75th percentile of your actual visitors, across their real devices, networks and locations. If three quarters of your visitors load fast but the slowest quarter does not, the lab score passes and the field assessment fails. To improve rankings you have to measure the same thing Google does: real-user web vitals, at the 75th percentile, broken down by the page, device and country where the problem actually lives.
Lab data vs field data (and why they disagree)
Lighthouse and PageSpeed Insights run a synthetic load: one device, one network, one location, under controlled conditions. That is repeatable and great for debugging, but it is not what your visitors experience.
Core Web Vitals ranking uses field data, the real measurements from real sessions. A mid-range phone on suburban 4G is a different load from a data-centre test on fibre. When your Lighthouse score and your Search Console CWV report disagree, field data is the one Google acts on.
The 75th percentile is the number that matters
Google assesses Core Web Vitals at the 75th percentile of real visits. In plain terms: three out of four visits must hit the "good" threshold for a page to pass. Averages hide this, because a fast median can still mask a slow tail.
That is why chasing an average load time misses the point. You need the 75th percentile, per page, because one slow template (a heavy product page, an unoptimised hero image) can drag a whole site's assessment down while the homepage looks fine.
Why Search Console is too slow and too blunt on its own
Search Console's Core Web Vitals report is built on the CrUX dataset, which is aggregated on a 28-day rolling window. A fix you ship today can take weeks to show up, and low-traffic pages may never gather enough samples to report at all.
It also groups pages, so you see "needs improvement" for a bucket of URLs without knowing which page, device or country is the culprit. That is fine for a monthly health check, but too coarse and too delayed to debug against.
Measure the same thing Google does, per page and per device
The fix is to capture web vitals from every real visit and read them the way Google does: the 75th percentile, split by page, device and country. Then the slow tail has a name and a location, and you can prioritise the one template that is actually failing.
Ghaze captures the browser's web-vitals output from real sessions and aggregates the 75th percentile per page, per device and per country, the same percentile Google uses. It is the same lightweight, cookie-free script that also handles your analytics, session replay and uptime, so real-user performance is not a separate tool or a separate bill.
A practical workflow
Use Lighthouse to debug a single page in the lab and prove a fix is possible. Use real-user field data to confirm the fix reached the 75th percentile of actual visitors, and to find which page to fix next.
Watch the trend after you ship, not just the score on the day. Real-user vitals move as your traffic mix shifts across devices and regions, so the page that passes this month can slip next month without a single code change.
/ where to go next
- real-user web vitals: Field, 75th-percentile vitals per page, device and country: the data Google ranks on.
- session replay: Watch the slow sessions the metrics flag, so you can see what actually made them slow.
- one cookie-free script: One lightweight script for analytics, session replay, heatmaps and uptime.
- conversion tracking: Tie real-user performance to the conversions it affects.
- how Ghaze compares to GA4: GA4 reports the same CrUX field data, but on a 28-day delay.
Frequently asked questions
What are Core Web Vitals?
They are the loading, interactivity and visual-stability metrics Google uses as a ranking signal, measured on real visitors (field data) rather than a lab test. Google assesses them at the 75th percentile of your actual visits.
Why does my Lighthouse score pass but Search Console fail?
Lighthouse runs one synthetic load under ideal conditions, while Google ranks on field data from real visitors. If your slowest quarter of visits is slow, the lab score can pass while the field assessment fails.
What does the 75th percentile mean for Core Web Vitals?
It means three out of four real visits must meet the "good" threshold for a page to pass. An average can look fine while a slow tail still fails the assessment, which is why the 75th percentile is the number to watch.
How is field data different from lab data?
Lab data (Lighthouse, PageSpeed Insights) is a controlled synthetic test from one machine. Field data is the real experience of your visitors across their own devices, networks and locations. Google ranks on field data.
How does Ghaze measure web vitals?
Ghaze captures the browser's web-vitals output from real sessions and aggregates the 75th percentile per page, per device and per country, from the same cookie-free script that runs your analytics, session replay and uptime monitoring.