Skip to content

Development

Core Web Vitals still matter, just not for the reason you were told

Speed was never much of a ranking factor. It is a large conversion factor, and now it is a retrieval factor too — because slow, JavaScript-dependent pages are invisible to most AI crawlers.

Mawkaii 7 min read

Key takeaway

Core Web Vitals have only ever been a small direct ranking signal. Their real commercial value is conversion — faster pages convert measurably better — and, increasingly, retrieval: most AI crawlers do not execute JavaScript, so content that only appears after client-side hydration is invisible to them regardless of how well the page scores for a human visitor.

For five years the industry sold performance work on the promise of rankings. That was always a weak argument, and clients who bought it were often disappointed.

The argument is much stronger now, but it is a different argument.

The ranking case was always oversold

Google has been consistent that page experience is a tiebreaker between comparable results, not a primary signal. A fast page about the wrong topic does not outrank a slow page about the right one.

Anyone who promised you rankings from a Lighthouse score was, at best, repeating something they had read.

The conversion case is the real one

Performance work has always paid for itself through conversion, and that effect is well documented across retail, publishing and lead generation.

The mechanism is not mysterious. Every additional second before a page becomes usable is a moment in which someone with low commitment leaves. On mobile, over an unreliable connection, in the two seconds before a user’s attention goes elsewhere, this is decisive.

If you want a defensible business case for performance work, measure it against conversion rate on your own site. It will hold up.

The new argument: retrieval

Here is the part that has genuinely changed.

Most AI crawlers do not execute JavaScript. Not “sometimes” — as a design decision, because rendering millions of pages in a headless browser is expensive and largely unnecessary for well-built sites.

If your product page renders its content client-side after hydration, those crawlers see a document containing a <div id="root"> and a script tag.

Which means your page cannot be retrieved. Cannot be cited. Does not exist to the answer layer of the internet, no matter how good it is.

This is not a subtle penalty. It is binary.

How to check

The fastest test costs nothing:

curl -s -A "GPTBot" https://yoursite.com/your-key-page/ | wc -c

Then read what comes back. If your headline, body copy and product details are not in that raw HTML, they are not visible to crawlers that do not render.

Do the same with ClaudeBot, PerplexityBot and Googlebot and compare. The difference between what Googlebot sees, after rendering, and what everyone else sees is the size of your exposure.

What to do about it

Server-render or statically generate your primary content. This is the whole fix. Frameworks that produce HTML at build time — Astro, Next.js in static or server mode, Nuxt, SvelteKit — solve it by default.

Keep interactivity as an enhancement. Filters, carousels and calculators can hydrate on the client. The words that describe your business should not depend on it.

Set budgets and enforce them in CI. A performance budget that is not checked on every pull request is a preference, not a budget.

Stop treating it as a launch task. Performance regresses. A page that passed at launch fails eighteen months later after four marketing tags and a chat widget have been added. Monitor it like uptime.

The honest summary

Performance is not a growth hack. It is hygiene with an unusually direct link to revenue — and, as of the last two years, a precondition for existing in AI answers at all.

That is a better reason than the one the industry spent five years using.

  • performance
  • Core Web Vitals
  • conversion
  • AI SEO

We do this for a living.

If this is the sort of thinking you want on your side, the first conversation is free.