Does web performance really improve your organic search rankings?

What's the difference between direct effect and side effect in SEO?

Gary Illyes establishes a fundamental distinction that many still confuse. A direct primary effect would mean that Google uses performance metrics as a ranking signal in its algorithm. A side effect means that performance impacts user behavior, and that behavior then influences SEO.

Concretely? Your technical optimizations (preload, prefetch, compression) don't change how fast Googlebot crawls your pages or how it indexes them. They do, however, improve the loading time perceived by the real user.

Why does Google insist on this semantic nuance?

Because too many professionals still optimize performance for Googlebot rather than for their visitors. The message is clear: studies show that users prefer fast sites, stay longer, convert better. It's this virtuous circle that impacts your visibility — not a magical algorithmic boost.

This clarification also prevents sites from merely manipulating synthetic metrics without truly improving experience. A PageSpeed score of 95 is useless if your user journey remains disastrous.

Do crawling and indexation benefit from no improvement at all?

That's what Illyes affirms — and that's where it gets interesting. Googlebot doesn't need your frontend optimizations to efficiently explore your pages. It has its own resources and doesn't face the same constraints as a regular browser.

On the other hand, a structurally slow site (high server time, multiple redirects, blocking resources) can indeed slow down crawling. But that's not what we're talking about here: preload and prefetch are client-side techniques, invisible to the bot.

• User performance does not directly improve crawling or indexation according to Google
• Frontend optimizations (preload, prefetch) target actual user experience
• SEO impact flows through retention, engagement, and conversions
• Googlebot does not benefit from the same optimizations as a regular browser
• The distinction between primary and secondary effects is strategic for prioritizing your efforts

Is this statement consistent with what we observe in the field?

Yes and no. On paper, the distinction makes sense: Google doesn't directly use your Core Web Vitals as a major ranking signal. Correlation studies actually show weak links between CWV and organic positions. The infamous Page Experience Update had a negligible impact on most sites.

But — and here's where it gets tricky — nobody has access to Google's actual behavioral data (session duration, bounce rate, post-click navigation). If these signals weigh in the algorithm, and performance influences them strongly, then the indirect effect becomes mechanically significant. Google isn't technically lying, but the actual effect could be far more powerful than a simple "side effect".

What nuances should we add to this statement?

First point: Illyes is talking about preload and prefetch, relatively advanced techniques. Many sites have far more basic performance issues — slow server, unoptimized images, blocking JavaScript. These factors can actually impact crawling if the server responds too slowly to Googlebot requests.

Second nuance: mobile performance. On mobile, a slow site causes massive abandonment before even the first click. If Google measures post-SERP CTR or pogo-sticking, you have an indirect effect that becomes dominant. [To verify] — Google has never officially confirmed using pogo-sticking as a signal, but patents and observations point in that direction.

In what cases might this rule not apply?

If your site is so slow that Googlebot times out regularly, you have a crawling problem — not a user experience one. Same if your server response times consistently exceed 2-3 seconds: the bot will adjust its crawl rate downward to avoid overloading your infrastructure.

Another edge case: very high-volume sites. Limited crawl budget can be aggravated by deficient technical architecture. There, optimizing server response times has a genuine direct primary effect on indexation — unlike the frontend optimizations mentioned by Illyes.

What should you do concretely after this clarification?

Stop optimizing performance solely to improve your Google rankings. Adopt a holistic approach: performance should serve your business objectives (conversions, engagement, retention). If it impacts SEO, that's a bonus — not the primary goal.

Concretely, prioritize optimizations that improve the perceived loading time for real users: preloading critical resources, lazy loading below-the-fold images, optimizing the Critical Rendering Path. Don't just satisfy Lighthouse or PageSpeed Insights if the experience remains mediocre.

What errors should you avoid in your performance audits?

First classic mistake: optimizing for a perfect PageSpeed score while sacrificing features or experience. A score of 95 guarantees nothing if your user journey is broken or your content takes 5 seconds to become interactive.

Second mistake: confusing server performance and frontend performance. The optimizations Illyes mentions (preload, prefetch) don't impact crawling — but a 3-second TTFB does. Audit these two dimensions separately and fix structural problems before fine-tuning the frontend.

Third trap: measuring only in lab conditions. Field Core Web Vitals (CrUX) reflect actual user experience, with their mediocre 4G connections and budget devices. That's what matters — not your test on fiber with a MacBook Pro.

How do you ensure your optimizations actually serve your SEO?

Track the metrics that really matter: session duration, bounce rate, pages per visit, conversions. If your performance optimizations improve these KPIs, you're on the right track — regardless of direct or indirect ranking impact.

Implement RUM (Real User Monitoring) to capture actual performance, not synthetic. Segment by device, geography, connection type. Identify where you're losing users and fix priority areas.

• Audit server performance (TTFB, response time) and frontend performance (CWV, rendering) separately
• Prioritize optimizations that improve perceived loading time for real users
• Measure impact on behavioral metrics (engagement, conversions) rather than rankings
• Use RUM to capture field performance, not just synthetic tests
• Never sacrifice user experience for an artificial PageSpeed score
• Fix structural problems (slow server, deficient architecture) before fine-tuning the frontend
• Track Core Web Vitals CrUX evolution to measure actual visitor experience