Google's page experience document contains a sentence that resolves an argument I have watched people have for years:
There is no single signal. Our core ranking systems look at a variety of signals that align with overall page experience.
That is the whole “is page experience a ranking factor” debate, closed. There is no switch. There are several things, Core Web Vitals among them, that the core systems read.
How much it matters, in Google's words
The document is unusually direct about priority:
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.
So: content first. A slow page with the best answer outranks a fast page with a worse one. But most queries have several good answers, and among those, experience is a tiebreaker. For a small site competing against bigger ones on the same topics, tiebreakers are where the game is.
The numbers
The Core Web Vitals thresholds, from web.dev, measured at the 75th percentile of real page loads, split by mobile and desktop:
| Metric | Good | What it measures |
|---|---|---|
| Largest Contentful Paint | 2.5 seconds or less | when the main content is visible |
| Interaction to Next Paint | 200 milliseconds or less | how quickly the page responds to input |
| Cumulative Layout Shift | 0.1 or less | how much things jump around |
INP replaced First Input Delay in 2024. If a tool is still showing you FID, the tool is old.
The 75th percentile part matters. It is not your laptop on office wifi. It is the slower quarter of your real visitors, which for most sites means a mid-range Android phone on a mobile network.
The rest of the checklist
Google's self-assessment list goes past the vitals: served over HTTPS, displays well on mobile, no excessive ads that interfere with the main content, no intrusive interstitials, and a clear distinction between main content and everything else. None of it is exotic. All of it is the kind of thing that erodes one decision at a time.
The page on this site that has to earn it
Article pages here are close to free. Code blocks are highlighted at build time, so no highlighting library ships to the browser. The layout is static HTML from the server. There is nothing to be slow.
The homepage is different. It has a 3D hero built on three.js. I kept it out of the server bundle and off every page that does not use it, and it loads dynamically so the rest of the page is not waiting on it. But it is still a WebGL scene on the page most people land on first, and INP and LCP on a mid-range phone are exactly where it would show.
I am not going to claim numbers I have not measured. What I am committing to is measuring that page separately from the articles, at the 75th percentile, on mobile, and treating the hero as a cost that has to justify itself. If it cannot hit the thresholds on the slower quarter of devices, the scene gets simpler or goes.
What I would tell a Flutter developer reading this
The same logic applies to a Flutter web build, with worse defaults. I already moved a game off Flutter Web for developer experience reasons. The page experience document is a reminder that the shipped experience has a cost too, and Google reads it from real users, not from your machine.
Sources: Google Search Central, “Understanding page experience in Google Search results.” web.dev, “Web Vitals.”