Page Experience: No Single Signal, and the 75% Rule

Page experience is not a score, a report or a ranking factor you can point at. Google’s own documentation says so in one sentence: “There is no single signal.” What exists instead is a set of six questions Google tells you to ask yourself, one of which has measurable thresholds and five of which do not. This piece quotes the documentation, gives the current thresholds, and then does the arithmetic Google leaves out, which is the part that changes what you do on Monday morning.

What Google actually publishes

From Google Search Central’s page experience documentation, last updated 22 September 2026, checked today:

Google’s core ranking systems look to reward content that provides a good page experience.

There is no single signal. Our core ranking systems look at a variety of signals that align with overall page experience.

And on how much weight it carries, which is the sentence most summaries skip:

Google Search always seeks to show the most relevant content, even if the page experience is sub-par. But for many queries, there is lots of helpful content available. Having a great page experience can contribute to success in Search, in such cases.

Read that as a tie-breaker clause. Page experience does not beat relevance. It decides between pages that are already relevant, which is exactly the situation most commercial queries are in.

The six questions, and which of them you can measure

Google lists six self-assessment questions. This table is my own addition: the questions are quoted from the documentation, the right-hand columns are my classification of what each one can actually be tested with. That distinction is the whole reason page experience work goes wrong, because teams spend their budget on the one row with a number attached and ignore the five that need a human to look at the page.

Google’s question	Has a numeric threshold?	How you actually test it
“Do your pages have good Core Web Vitals?”	Yes, three of them	Field data at the 75th percentile, split by mobile and desktop
“Are your pages served in a secure fashion?”	Binary, not a threshold	Crawl the site and count non-HTTPS responses and mixed content
“Does your content display well on mobile devices?”	No	Render the templates at real viewport widths and look
“Does your content avoid using an excessive amount of ads that distract from or interfere with the main content?”	No, “excessive” is undefined	Judgement, ideally someone who did not build the page
“Do your pages avoid using intrusive interstitials?”	No	Judgement, per template, on a cold session
“Is your page designed so visitors can easily distinguish the main content from other content on your page?”	No	Judgement, per template
Six questions	One measurable, five judgement	Five sixths of page experience is editorial

One of six. That is the honest split. If your page experience programme is a dashboard, you are working on one sixth of what Google says it looks at.

The thresholds, and the percentile that does the real work

From the Core Web Vitals documentation on web.dev, which carries a last-updated date of 31 October 2024:

Metric	Good threshold, quoted
Largest Contentful Paint	“LCP should occur within 2.5 seconds of when the page first starts loading.”
Interaction to Next Paint	“pages should have a INP of 200 milliseconds or less.”
Cumulative Layout Shift	“pages should maintain a CLS of 0.1. or less.”

And the rule that almost nobody reasons about properly:

a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.

Also from the page experience documentation: “Core Web Vitals are used by our ranking systems. We recommend site owners achieve good Core Web Vitals for success with Search.”

The arithmetic Google does not spell out

A site that sits exactly on the thresholds reports all three metrics as good. Here is what that site is actually serving. The percentile is the whole trick: assessment at the 75th percentile means a quarter of page loads are worse than the number you are being graded on.

Take a site doing 120,000 page views a month, passing all three metrics at the threshold.

Reading	Calculation	Page views a month
Loads above 2.5s LCP	25% of 120,000	30,000
Loads above 200ms INP	25% of 120,000	30,000
Loads above 0.1 CLS	25% of 120,000	30,000
Loads passing all three, if the three failed independently	0.75 cubed = 0.4219	50,625
Loads missing at least one, same assumption	1 minus 0.4219 = 0.5781	69,375
The site reports “good” on all three	Between 25% and 57.8% of loads are not good	30,000 to 69,375

The limitation of that model, stated plainly

The 57.8 percent figure assumes the three metrics fail independently, and they do not. A slow device on a slow connection tends to blow LCP, INP and CLS at the same time, so the failures correlate heavily and the true share of bad loads sits nearer the 25 percent floor than the 57.8 percent ceiling. I am publishing both bounds rather than one invented number in the middle, because the useful conclusion does not depend on which end you believe: a site that passes Core Web Vitals is still delivering a bad experience to tens of thousands of sessions a month, and those sessions are disproportionately the slow-device, slow-network ones.

The second limitation is that this is page-view arithmetic, not a ranking model. Google has not published how the signals combine, so nothing here says what the 30,000 bad loads cost you in positions. What it does say is where the remaining upside is after the dashboard turns green, which is the question clients actually ask once they have paid for a Core Web Vitals project and seen no movement.

What I do with this on a real engagement

Pull field data at the 75th percentile, split mobile and desktop, and look at the shape of the distribution rather than the single number. A site at 2.4 seconds with a long tail is a different problem from a site at 2.4 seconds with a tight one.
Score the five judgement questions by template, not by URL. Interstitials, ad density and main-content clarity are properties of a template, so twelve templates is twelve assessments, not twelve thousand.
Fix the templates with the worst combination of traffic share and judgement score first. That ordering is almost never the same as the ordering a Core Web Vitals tool gives you.
Check HTTPS and mixed content as a crawl task, because it is the one binary item on the list and it is cheap to prove.
Stop when the remaining work costs more than the tie-breaker is plausibly worth. Page experience does not beat relevance, and Google’s own wording says so.

If traffic has fallen and page experience is the first suspect, it is usually the wrong suspect. The diagnosis sequence in my Google penalty recovery piece puts it where it belongs in the order, which is late.

Page Experience: Google Says There Is No Single Signal, and the 75th Percentile Is Why That Matters