Core Web Vitals Won't Save a Page Nobody Wants to Read
Nobody has ever ranked first for being fast. Speed is worth fixing — just not before the things that actually decide whether you rank at all.
· 6 min read
Core Web Vitals get a disproportionate share of engineering attention, and I think the reason is unflattering but simple: they are the only part of SEO that looks like programming.
They have numbers. The numbers have thresholds. The thresholds go green when you do the right thing. You can profile, optimize, measure, and feel the specific satisfaction of a metric moving because of something you did. Compared to 'write something people want to read', it is enormously more tractable — and that tractability is exactly why it absorbs effort out of all proportion to its value.
What page experience actually is
Google has been consistent about this, and consistently ignored. Page experience is a tiebreaker. Between two pages of comparable relevance and quality, the better experience can win. That is the claim, and it is the whole claim.
It is not a lever. It does not lift a mediocre page over a better one. A slow page with the best answer to the query still beats a fast page with a worse answer, every time, and you can verify this yourself by searching almost anything and clicking the top result.
Nobody has ever ranked first for being fast.
The ordering that actually matters
There is a strict dependency chain in SEO, and it is routinely worked in the wrong order:
- 1Is the page indexed? If not, nothing else matters at all. Its LCP is irrelevant. It cannot rank, because it does not exist as far as Google is concerned.
- 2Is it relevant to a query someone actually searches? If not, being indexed and fast is being fast in an empty room.
- 3Is it as good as what already ranks? If not, Google has no reason to prefer it, however quickly it renders.
- 4Is it a good experience? *Now* we can talk about LCP.
This is not hypothetical and I am not being smug about it. We shipped exactly that canonical bug on this very site.
Why the 28-day window makes it worse
Core Web Vitals in Search Console reports a rolling 28-day average of real user data. So you ship a genuine fix and the report barely moves for a week, because it still contains three weeks of the old, slow site.
The predictable consequence: teams conclude the fix did not work, revert it, try something else, and spend another month. The feedback loop is four weeks long, which is close to the worst possible length — long enough to destroy causality, short enough that you keep trying.
Meanwhile indexing problems, which are fixable in an afternoon and worth vastly more, sit untouched in a report nobody opened. See the Core Web Vitals guide for how to read that window properly.
The case for fixing them anyway
I want to be clear that I am not arguing against performance work. I am arguing against performance work as an SEO strategy, which is a different thing, and the distinction determines what you should actually be optimizing for.
Fix Core Web Vitals because a page that jumps around while it loads and stalls when tapped is genuinely worse for the people using it, and those people are trying to give you money. The conversion impact of a fast, stable page is real, measurable, and considerably easier to justify than a tiebreaker in a ranking function you cannot observe.
That is a better reason than the ranking one, and it survives contact with the evidence. The ranking benefit is a rounding error dressed up as a strategy.
What to do this week instead
Open the Page indexing report
Is the indexed page count roughly what you expect? If Google says twelve and you have ninety, stop reading and go fix that — you have found something worth more than every millisecond you will ever save.
Check the canonical on a non-homepage URL
curl it. If the href is your homepage, you are actively deindexing your own site, and it takes one line to fix.
Find your striking-distance queries
Position 5–15, high impressions, low CTR. Rewriting those titles takes an afternoon and moves real traffic — no new content, no links, no build pipeline.
Then, if there is time, go make it fast
Genuinely. It is worth doing. It is just not worth doing first.