Why PageSpeed Insights and Search Console Disagree About Your Speed

A green 95 in PageSpeed Insights and a “Poor” email from Search Console about the same page can both be accurate. They answer different questions.

By David Cragg, SEO Tucson, in search marketing since 1990. Published October 23, 2026.

When people compare PageSpeed Insights vs Search Console, they usually assume one of them is broken. Neither is. PageSpeed Insights leads with a lab test: a simulated phone loading your page once, from a Google data center, with nobody touching it. Search Console reports only field data: what real Chrome users experienced on your pages over the last 28 days. One is a controlled experiment. The other is a four-week record of your actual visitors.

Every so often a client forwards me both in the same week: a PageSpeed Insights screenshot with a green circle, and a Search Console notice that the same pages need work. The question is always which one is lying. The honest answer is that they’re measuring different things, and once you know what each one measures, the disagreement tells you something useful.

PageSpeed Insights vs Search Console: two different questions

PageSpeed Insights runs Lighthouse against the URL you type in. Lighthouse loads the page once, on an emulated mid-range phone over a throttled connection, from a Google data center, with an empty cache. Then it scores what it saw. The question it answers is narrow: how does this page load under these fixed conditions, right now?

Search Console’s Core Web Vitals report never runs a test at all. It reads the Chrome User Experience Report, usually called CrUX, which is built from real visits by Chrome users who share usage statistics. Its question is broader: what did people actually experience on pages like this over the past four weeks?

Here’s the part that trips people up. PageSpeed Insights shows both. The top panel, the one about what your real users are experiencing, is CrUX field data, the same source Search Console uses. The big round score further down is the lab test. Most screenshots clients send me are cropped to the score, which is the half of the page Search Console ignores. Google’s About PageSpeed Insights page describes the two sections and where each one comes from.

What the lab test can and can’t see

I like the lab test. It’s consistent enough to compare a page before and after a change, it shows a filmstrip of the load, and it points at the files that are slowing things down. When I’m hunting for the cause of a problem, Lighthouse is where I hunt.

But a lab test is a robot loading a page one time. Some things it simply can’t observe:

• Taps and clicks. Lighthouse doesn’t open your menu, submit your form or tap your click-to-call button. Responsiveness in the field is measured on real interactions. In the lab, the closest stand-in is Total Blocking Time, an estimate of how busy the browser was while the page loaded.
• Anything that moves after the load. A cookie notice that slides in, a review widget that pushes the page down three seconds later, an accordion that shifts the layout when someone opens it. Field data watches layout shifts for the whole visit. The lab mostly stops watching once the page has loaded.
• Your actual audience. The emulated phone is one device profile. Your customers are on whatever phone they own, on whatever signal they have, wherever they happen to be.
• Return visits. Real visitors arrive with files already cached, through the back button, and from ads with tracking parameters. The lab always starts cold.

The lab score also moves from run to run when nothing on the page changed. Google’s documentation names local network availability, client hardware and resource contention as normal sources of that variation. PageSpeed Insights even tells you where the test ran: North America, Europe or Asia. It isn’t running from your customer’s kitchen table in Oro Valley.

Who field data includes, and who it leaves out

Field data comes from people, specifically Chrome users on desktop and Android who have usage statistics turned on. That detail matters more than most site owners realize.

Google’s CrUX methodology lists the exceptions plainly: Chrome on iOS doesn’t contribute, Android apps using WebView don’t contribute, and other Chromium browsers such as Microsoft Edge don’t contribute. Safari and Firefox users were never part of it. So if your analytics show that most of your customers reach you on an iPhone, your field data is drawn from the minority who don’t. It’s still real data. It just isn’t everybody.

A page also needs enough of those eligible visits to have field data of its own. When it doesn’t, PageSpeed Insights falls back to origin-level data, which blends every page on your site together. A small local site often sees origin data for every URL except the homepage, or no field data at all. That isn’t a penalty. It’s a sample size.

One more thing about field data: it’s graded at the 75th percentile, not the average. Google deliberately looks at the slower end of your visits. A page that’s quick for most people and painful for one visitor in four still has a problem, and the field data will say so even when the lab test says everything is fine.

The 28-day window

Field data covers a trailing 28-day collection period. PageSpeed Insights refreshes it daily, but each refresh still describes the previous four weeks. Search Console builds its URL groups on the same 28 days.

That window explains most of the “I fixed it and nothing happened” calls I get. Say you replace a bloated hero image on a Monday. Run PageSpeed Insights that afternoon and the lab score jumps. The field panel barely moves, because it’s now 27 days of the old page and one day of the new one. The improvement seeps in a day at a time, and the full effect takes about four weeks. When you click Validate fix in Search Console, it watches field data too, so it runs on the same clock.

It works in the other direction as well. A plugin update that slowed the site three weeks ago is still dragging the field numbers down after you’ve rolled it back. Before anyone panics about a field number, I check the collection period dates PageSpeed Insights prints under the field panel and line them up against what changed on the site.

There’s a Tucson wrinkle, too. The people inside those 28 days change with the seasons. If your business sees winter visitors from fall through spring, the phones and connections in your field data shift when they arrive and again when they leave, even if your site didn’t change at all. I treat a seasonal swing as a question about the audience before I treat it as a question about the code.

Why Search Console shows groups, not your page

Search Console doesn’t report pages one at a time. It sorts URLs into groups of similar pages and gives each group the status of its worst metric. A group that’s fine on two metrics and poor on one is Poor.

Google’s Core Web Vitals report help page spells out several differences from PageSpeed Insights, and they account for most of the mismatches I see:

• The URL you tested in PageSpeed Insights can be an outlier in its group. Your homepage might be quick while the service pages sharing a heavier template are not.
• Search Console keeps URL parameters when it identifies a page. PageSpeed Insights strips them and files everything under the bare URL, so ad clicks and social shares that land on tagged URLs are counted differently.
• Search Console assigns field data to the URL that was actually visited, not to the canonical URL.
• Only indexed URLs can appear in the report, and the data combines visitors from every location, not just your city.

Groups become useful once you stop fighting them. A failing group usually means a failing template, and fixing the template fixes the whole group at once.

How a page scores 95 and still fails

Put those pieces together and the page that scores 95 and still fails stops being a mystery. These are the patterns I run into most often:

• A late layout shift. A chat bubble, cookie notice or review carousel appears after the lab test has stopped watching. Real visitors are mid-scroll when it lands.
• Slow responses to taps. A mega menu, slider or form script that loads quickly and responds sluggishly. Lighthouse never taps it.
• A tougher audience than the test device. Older phones, weak signal at the edge of town or on a job site, a crowded network at a busy event.
• The wrong page. You tested the homepage. Search Console is grading the template your service pages share.
• Old news. The problem was fixed last week, and the field data is still averaging it in.
• Someone else’s numbers. The page had no field data of its own, so PageSpeed Insights showed you the whole site’s.

None of those show up as a lower lab score. That’s why a high score and a passing grade are two different things.

How I read the two together

When a client hands me both reports, this is the order I work in:

1. In PageSpeed Insights, scroll past the score. Check whether the field panel is showing this URL or the whole origin, and note the collection period dates.
2. Look at mobile field data first. Most local searches happen on phones, and mobile is usually where the problem lives.
3. In Search Console, open the failing group, note which metric is failing, and click through the example URLs to see which template they share.
4. Use the lab only to find the cause of the metric the field data says is failing. Don’t tune the lab score for its own sake.
5. Write down the date of the fix. Check field data weekly and expect a slope, not a switch.
6. For pages with no field data, test on a real phone over a real cellular connection, not only in the lab.

Where the pass and fail lines sit, and how each of the three Core Web Vitals works, is covered on my technical SEO services page. This article is about why the tools disagree, not where the lines are drawn.

If speed is one piece of a bigger question about what’s holding a site back, that’s what an SEO audit is for. And when the template itself is the problem, rebuilding it is sometimes cheaper than patching it forever, which is where website design comes in.

What clients say

These are reviews clients left on my Google profiles. Most date from my Temecula SEO years in Southern California, before I moved to Tucson in 2022. Dr. Nguyen is still a client today, and that review also appears on my SEO Tucson profile.

More on technical SEO

Written by David Cragg. Published October 23, 2026. Last reviewed October 23, 2026. Drafted with AI assistance, then edited, fact-checked and approved by David before publication. How I use AI, and what it is never allowed to do.