You shipped a real LCP improvement. Your own RUM dashboard shows median LCP dropping from 2.9s to 1.8s. Three weeks later, PageSpeed Insights still says the page fails, Search Console still shows the same count of poor URLs, and someone in a meeting asks whether the work was worth it.
Nothing is broken. Core Web Vitals field data is a 75th-percentile statistic computed over a trailing 28 days, aggregated in ways that are different in every tool that reports it. Once you know the aggregation rules, most of the disagreements stop being mysteries and start being predictions you can make before you deploy.
Why the same URL reports different numbers in different tools
All the public field numbers trace back to one source: the Chrome User Experience Report. Google collects it from Chrome users who have opted into usage statistic reporting and history sync without a custom passphrase. That is already a biased sample — it excludes Safari, Firefox, most in-app browsers, and Chrome users who opted out — but it is consistent bias, so trends within it are still meaningful.
What differs is how each surface slices that data.
| Source | Data type | Window | Granularity |
|---|---|---|---|
| CrUX API | Field | Rolling 28 days | Origin and URL, splittable by form factor |
| CrUX BigQuery tables | Field | Calendar month | Origin-level, with full histograms |
| PageSpeed Insights | Field + one lab run | 28 days / single load | URL, falling back to origin |
| Search Console CWV report | Field | Rolling 28 days | Groups of similar URLs |
| Your own RUM | Field | Whatever you configure | Whatever you configure |
So a URL can simultaneously be "failing" in Search Console (because its group fails), "passing" in the CrUX API (because that specific URL has enough samples and is fine), and show a red Lighthouse score in the same PageSpeed Insights report that shows green field data. All three can be correct.
What the 75th percentile actually rewards
Google assesses each metric at the 75th percentile of page loads: LCP at or under 2.5s, INP at or under 200ms, CLS at or under 0.1 are the "good" thresholds. The percentile is per-metric, not per-page-load, so a page can hit p75 good on LCP and fail on INP independently.
The consequence people miss: improving the majority of your traffic can move p75 by exactly zero.
Suppose 70% of loads are warm-cache repeat visits at 2.0s and 30% are cold, poorly-connected mobile loads at 5.0s. Sort them and the 75th percentile falls inside the slow 30% — p75 is 5.0s. Now optimize the fast segment from 2.0s to 1.2s. You have improved the experience for most of your users and changed p75 not at all.
The inverse is also true and more useful: if you are just above a threshold, shaving the slow tail can flip the assessment with a small absolute improvement. Before you scope performance work, pull the distribution, not the average. The CrUX BigQuery tables and API both return histograms; so should your RUM. Ask which bucket your p75 sits in and what fraction of loads would have to move to cross the line.
Why your fix takes a month to appear, and longer to trust
The CrUX API and Search Console both report a rolling 28-day window. The day after you deploy, 27 of those 28 days are pre-fix data. Two weeks later, half the window is still pre-fix. The reported p75 does not jump when you deploy; it walks toward the new value as old days fall out of the window.
The monthly BigQuery dataset is worse for feedback loops: it is a calendar-month aggregate published after the month closes, so a fix shipped on the 20th shows up as a diluted partial month and then, several weeks later, as a clean one.
Practical timeline for a change that affects all traffic equally:
- Day 0–7: essentially no visible movement; resist the urge to conclude anything.
- Day 7–27: gradual drift in rolling-window tools.
- Day 28+: the window contains only post-fix data. This is your first honest read.
- Next month's BigQuery drop: your first clean month-over-month comparison.
If you need a same-day signal, you need your own RUM. That is the only place you can slice to "loads after the deploy timestamp" and compute p75 immediately.
Why Search Console and PageSpeed Insights disagree about the same URL
Two separate mechanisms.
URL grouping. Google has documented that the Search Console Core Web Vitals report assigns URLs to groups of similar pages and applies the group's assessment to the URLs in it. A URL with no data of its own inherits the group's status. So a page you never optimized can be marked poor because its template siblings are poor, and a page you did optimize can stay marked poor until the group's aggregate moves.
Origin fallback. PageSpeed Insights reports URL-level field data when there is enough of it and otherwise falls back to origin-level data for the whole site. Google has not published the exact sample threshold. The tell is the label in the report — check whether you are looking at "this URL" or "this origin" before you draw a conclusion about a specific page. A long-tail page on a big site will usually show you the origin's aggregate, which is dominated by whichever templates get the most page loads.
That page-view weighting matters at origin level generally: every page load is one sample, so your homepage and your highest-traffic template set the origin number. Fixing a slow but low-traffic section will not move it.
What lab tools can and cannot tell you
Lighthouse runs one load on emulated hardware with throttled network. It is a debugging tool, not a measurement of your users. Two of the three Core Web Vitals cannot be measured honestly in that environment at all:
- INP requires interactions. A synthetic load nobody clicks produces no interaction latency. Lighthouse reports Total Blocking Time as a related diagnostic, and it correlates with INP problems, but it is not the same metric and does not share thresholds.
- CLS in the field accumulates across the page's whole lifetime, including shifts caused by lazy-loaded content, ad refreshes, and interactions long after load. Lighthouse only sees shifts during its capture window, which is why lab CLS is routinely much lower than field CLS on ad-supported pages.
LCP is the one metric where lab and field are conceptually comparable, and even there the lab device profile and throttling will produce a number that matches no real user in particular.
What to do
- Instrument your own RUM with the
web-vitalslibrary and store the raw values, not just averages. You need percentiles and histograms, segmented by device, connection, template, and — critically — deploy timestamp. - Before scoping work, pull the histogram and ask what share of loads must cross the threshold to move p75. If the answer is "the slowest 30%," target that segment specifically.
- Compare like with like. Put a note in your dashboard for the deploy date and do not read rolling-window tools until 28 days have passed.
- In Search Console, treat the report as template-level diagnostics, not per-URL truth. Use the example URLs to find the pattern, then verify individual pages against the CrUX API.
- When PageSpeed Insights shows field data, check whether it is URL-level or origin fallback before you attribute it to the page.
- Keep Lighthouse for finding causes — render-blocking resources, oversized LCP images, long tasks — and never for judging whether you passed.
Google has said page experience, including Core Web Vitals, is used in ranking systems, and has also been clear that relevance dominates. Measure this work as a user-experience program with a search-visibility side effect, and the 28-day lag stops feeling like a reporting failure.