Because they are measuring two different things. A PageSpeed score is a lab test run on a simulated device. Search Console reports field data gathered from real people on real phones and real networks. When they disagree, the field data is the one that reflects your actual visitors.
This is the single most common source of confusion we see when a client sends over a performance report. Someone runs a test, sees a green 98, and cannot understand why Google is still flagging the site. Nothing is broken. The two tools simply answer different questions.
Once you understand which number comes from where, performance work gets much easier to prioritise. You stop chasing a score and start fixing the experience that real people are having.
Lab data comes from a controlled test. A tool loads your page once, on set hardware, over a throttled connection, with no human interacting with it. Field data comes from real visits by real users, collected over time, on whatever devices and connections those people happen to have.
Lab data is repeatable and diagnostic. Run the same test twice and you get roughly the same answer, and the tool can tell you exactly which script blocked rendering. That is what makes it useful when you are actually fixing something.
Field data is messy and slow to move, but it is true. It includes the visitor on a five year old Android phone on a bad connection, and the visitor who scrolled and tapped in a way no automated test would replicate. Google’s own guidance on Core Web Vitals notes that performance can vary substantially based on device capability, network conditions, other processes on the device, and how people interact with the page.
The Chrome User Experience Report, usually shortened to CrUX, is Google’s public dataset of real user performance data. Google describes it as a dataset reflecting how real-world Chrome users experience popular destinations on the web. It is the source behind the field numbers in PageSpeed Insights and Search Console.
Not every visit is counted. Chrome’s documentation sets out the user criteria: the user has to have usage statistic reporting enabled, sync their browser history, not have a Sync passphrase set, and be on a supported platform. Desktop Chrome on Windows, macOS, ChromeOS and Linux qualifies, as does Chrome on Android.
Sites have to qualify too. Google states there are separate eligibility criteria for origins and pages, primarily that they must be publicly discoverable and have enough visitors to create a statistically significant dataset. A brand new site or a low traffic page will simply have no field data at all.
Field data. Google’s page experience documentation states directly that Core Web Vitals are used by its ranking systems, and the Core Web Vitals reporting in Search Console is built on CrUX field data. Your Lighthouse score is a diagnostic tool, not a ranking input.
Google is careful to frame the weight of this. The same documentation notes there is no single signal, and adds that Google Search always seeks to show the most relevant content even if the page experience is sub-par. Speed is a tiebreaker on relevance, not a substitute for it.
We think that framing is right, and we say it to clients often. A fast page about the wrong topic will not outrank a slower page that answers the question. We go through the ranking side of this in more depth in our article on how Core Web Vitals affect SEO rankings.
Because one of them needs a human. Interaction to Next Paint measures how quickly a page responds after someone taps or clicks. Google’s documentation is explicit that tools like Lighthouse, which load pages in a simulated environment without a user, cannot measure INP because there is no user input.
Lab tools work around this with a proxy metric called Total Blocking Time. It measures how long the main thread was blocked during load, which correlates with poor responsiveness but is not the same measurement. A good Total Blocking Time is a decent sign, not a guarantee.
This is the biggest practical gap between the two views of your site. You can pass every lab check and still have a real responsiveness problem that only shows up once actual people start tapping things. Our breakdown of Interaction to Next Paint and how to fix it covers what usually causes that.
There are three stable metrics with fixed targets. Largest Contentful Paint should happen within 2.5 seconds of the page starting to load. Interaction to Next Paint should be 200 milliseconds or less. Cumulative Layout Shift should stay at 0.1 or less.
Those are the good thresholds published by Google on web.dev. Anything past them falls into needs improvement or poor, and Search Console groups your URLs accordingly. The targets themselves have been stable long enough that you can plan around them.
What changes more often is which metrics count. Interaction to Next Paint replaced First Input Delay as the responsiveness metric, so if you are working from an old checklist you may be optimising for something that no longer appears in the report.
Because an average would hide your worst experiences. Google measures Core Web Vitals at the 75th percentile of page loads, segmented across mobile and desktop. That means three quarters of your visits have to hit the threshold, so a small group of very slow loads still shows up.
Averages are dangerous in performance work. If most of your visitors are on fast desktops and a quarter are on cheap phones, an average tells you everything is fine while a quarter of your audience has a bad time. The 75th percentile deliberately refuses to let you hide that.
The mobile and desktop split matters just as much. We routinely see sites where desktop passes comfortably and mobile fails on every metric. If you only ever look at the combined number, or you only ever test on your own laptop, you will miss it entirely.
When you are fixing something, and when you have no field data yet. Lab tools give you a waterfall, a list of render-blocking resources, and a repeatable result you can compare before and after a change. Field data cannot do any of that, because it lags and it does not explain causes.
Lab testing is also the only option before launch. A site that has not gone live has no real users, so CrUX has nothing to report. Every pre-launch performance check we run is by definition a lab check, and that is fine as long as everyone knows what it does and does not prove.
Our own average PageSpeed score across projects is 98, and we are upfront that this is a lab number. It tells you our builds are clean and light. It does not by itself tell you what a visitor on a weak connection experienced last Tuesday. Both facts can be true at once.
A lot of people, and it is worth knowing who. CrUX is Chrome data only. Chrome’s documentation notes that Chrome on iOS, Android WebView, and other Chromium browsers such as Microsoft Edge are excluded. Safari and Firefox users are not in the dataset at all.
For most consumer sites that still leaves a large and representative sample, so the data is genuinely useful. For a site with an audience skewed heavily toward iPhone users, the picture is more partial than it looks, because those visitors using Safari are invisible to it.
The fix, if this matters to you, is to collect your own real user monitoring data alongside CrUX. That gives you field data from every browser, not just Chrome, and it updates immediately rather than waiting for the public dataset to catch up.
Chase the field data, and use lab data to get there. Field numbers in Search Console tell you whether your visitors are having a good time and whether Google agrees. Lab tools tell you what to change to fix it. Treating either one as the whole answer leads you astray.
The practical loop we use is simple. Read the field data to decide what is worth fixing, use lab tools to diagnose and verify the fix, then wait for the field data to move. That last part takes patience, because real user data does not update the moment you deploy.
Setting a hard limit on page weight keeps this from becoming an endless cycle, which is why we work to an agreed ceiling on every build. Our guide to setting and enforcing a performance budget explains how we do that.
If you are staring at two reports that disagree and you are not sure which one to believe, we’re happy to look at it with you. Reach out at phoenix.studio and we’ll tell you what the numbers are actually saying about your site.
Tell us where you want to go. We'll tell you how we'd get you there.