In short
Page speed is treated by both search engines and AI answer engines as a genuine ranking and trust signal, not a cosmetic nice-to-have — a slow site is deprioritized in crawling, ranks lower on Core Web Vitals, and converts worse, making speed one of the highest-leverage investments available, not an optional final polish step.
Where speed usually sits in the priority list
In most project timelines, performance work gets scheduled last — after the content is written, the design is finalized, the features are built. It's treated as a polish pass, something to "optimize later if there's time." This ordering reflects an outdated assumption: that speed is cosmetic, not structural.
The evidence against that assumption
Core Web Vitals are an explicit, direct ranking signal — not a proxy or a correlation, but a metric search engines have stated they factor in directly. A crawler also allocates less crawl budget to slow, unreliable sites, meaning a genuinely slow site can have worse indexing coverage independent of its ranking position on any individual page. And on the conversion side, a slower page reliably loses visitors before they ever see the content that was supposedly worth the wait.
AI answer engines raise the stakes further
An AI system's retriever behaves similarly to a search crawler in de-prioritizing slow or unreliable sources — a page that's technically excellent as writing but slow to load is competing at a disadvantage against a faster page with merely adequate content. Speed isn't separable from visibility in either search or AI-mediated discovery; it's a precondition for both.
Why treating it as optional is expensive
When speed is scheduled last, it usually gets cut or shortened when a deadline arrives — which means the sites most likely to skip performance work are exactly the ones under the most delivery pressure, often the same sites competing hardest for visibility. The nice-to-have framing produces a self-reinforcing gap between teams that prioritize speed and teams that don't.
What treating it as a real requirement looks like
Set a performance budget at project kickoff, not at the end — a concrete target for page weight or load time that's part of the definition of done, alongside content and design requirements, rather than an afterthought checked once before launch and never again.
The reframe that matters
Speed isn't a technical detail separate from content and design quality — it's part of what "quality" means for a web page, on equal footing with accurate content and a clear layout. Once it's treated that way in planning and prioritization, it stops being the thing that gets cut under pressure, and starts being the thing that was never optional in the first place.
Primary source: Google Search Central documents the specifics referenced above.
Common questions
Is page speed really a direct ranking factor?
Yes — Core Web Vitals are an explicit ranking signal that search engines have stated they use, not merely a correlation with other quality factors.
Should performance work happen before or after content and design?
Alongside, with a performance budget set at project kickoff — treating it as a final polish step means it's the first thing cut when deadlines get tight.
Does speed matter for AI citation as well as search ranking?
Yes — AI retrievers behave similarly to search crawlers in de-prioritizing slow or unreliable sources, so speed affects visibility in AI-mediated discovery as much as in traditional search.