PageSpeed 98, Search Console “poor” — which number counts?

The client sends a screenshot: PageSpeed Insights, 98 out of 100, all green. Two days later the second screenshot arrives, from Search Console, and there the same pages are marked “poor”. Both numbers are right, and that is exactly what makes the situation expensive: as long as nobody explains that two different measurements are standing side by side here, the team spends weeks optimising against the value Google does not use for its assessment at all.

How to go about it in JMX

1. Fetch Web Vitals. The Web Vitals view retrieves the values via the PageSpeed Insights API. Mobile is measured by default, because that is what Google assesses on; desktop doubles the calls and is a separate assessment, never an average.
2. Read the Data source column. It distinguishes Field (URL), Field (origin) and Lab, and above the table it says how many pages fall into which category. Only real field data per URL answers the question from Search Console.
3. Store an API key. Under Settings → Google. With a key, 25,000 requests a day are possible; without one you are left with twelve requests per minute, and JMX estimates around ten minutes for fifty pages with lab data.
4. Include the Lighthouse run. Four scores fall out of the same call: Score, A11y, BP and SEO. The client’s 98 is in the Score column. It is lab.
5. Switch to the Actions tab. It does not say how slow a page is but which file is how many kilobytes too large — grouped by action rather than by page, with the number of affected pages, the estimated saving as a median, and the weight with which the audit feeds into its category score.
6. Look at the field data history. Around forty weeks of 75th-percentile values from the Chrome UX Report History API, free of charge, with the same key. The 28-day value says how the site stands today. The curve says since when.

What to watch out for

The 98 is not wrong, it answers a different question. A lab test loads the page once on a throttled connection, and nobody clicks while it does — INP only comes into being through an interaction. Google, by contrast, assesses the 75th percentile of real loads over the last 28 days: 2.5 seconds LCP, 200 milliseconds INP, 0.1 CLS. A quarter of visitors may be worse off. If it becomes more, the assessment tips over even though nothing happened in the lab.

One limit has to be said out loud to the client: JMX does not read the Core Web Vitals report in Search Console. The connection delivers clicks, impressions, CTR and position, the URL inspection and the sitemap management; the vitals come from PageSpeed Insights, per individual URL. Search Console groups similar pages together and reports the group, which is why a measured URL can pass while its group fails. You get no closer than that: the Web Vitals view knows no segments — JMX computes the pass rate per device class only, mobile and desktop separately. That is not the same thing.

The most common special case: a page without field data of its own. If a URL has too little traffic, the API sends the numbers for the whole origin; JMX marks them as Field (origin) and takes those pages out of the pass rate rather than counting them as failed — the median of an origin says nothing about a single subpage. The field data history applies per origin and not per page for the same reason: it answers whether the site has got worse since the relaunch, not whether this one landing page has.

Report the 98 as a success and you are selling a lab measurement as visitor experience — and you will be standing there without an explanation at the next Search Console screenshot.