Are Core Web Vitals really the only speed criterion that counts for ranking?

Why does Google limit speed to just Core Web Vitals?

This statement marks a radical simplification of what matters for ranking. Previously, the SEO ecosystem scrutinized a dozen metrics: TTFB, SpeedIndex, Total Blocking Time, and even PageSpeed Insights thresholds.

With this clarification, Google makes it clear: only three indicators count for ranking—LCP (Largest Contentful Paint), FID (First Input Delay replaced by INP in 2024), and CLS (Cumulative Layout Shift). The rest may improve the experience but do not weigh in the ranking algorithm.

What exactly is the 'page experience' algorithm?

The page experience signal encompasses several criteria: Core Web Vitals, HTTPS, absence of intrusive interstitials, and mobile-friendly navigation. It's a ranking factor among others—not the most powerful, but significant enough to differentiate between two equivalent contents.

The important nuance: Mueller talks about the speed factor within this signal. In other words, if you want your site's speed to work in your favor, focus on the CWV. Everything else is out of scope for ranking.

Then why are other metrics still important?

Because they indirectly influence SEO through user behavior. A site with a catastrophic TTFB but correct CWV can technically pass the Google filter—except visitors will leave before the page loads.

Bounce rate, session duration, and engagement signals can then impact ranking. Google does not measure your SpeedIndex, but if your users are leaving, the algorithm will eventually detect it.

• Only Core Web Vitals (LCP, FID/INP, CLS) are direct ranking factors for speed
• Other metrics (TTFB, SpeedIndex, TTI) do not count in the ranking algorithm
• The overall user experience can affect SEO via indirect behavioral signals
• The 'page experience' signal remains a modest factor compared to content and backlinks
• Optimizing for CWV does not absolve you from a fast global architecture

Is this statement consistent with field observations?

Overall, yes. A/B testing on thousands of pages shows that fixing a failing CLS or LCP can unlock positions—provided the content is already solid. In contrast, improving a TTFB from 600 ms to 200 ms without touching the CWV has never yielded measurable ranking gains.

But be careful: this rule applies to the page experience filter. If your site is so slow that Googlebot cannot crawl effectively, you have a problem upstream—not a ranking issue, but a crawl budget and indexing problem. Two different challenges.

What nuances should be added to this claim?

Mueller talks about direct ranking, but says nothing about penalty thresholds. A site with an LCP of 8 seconds won't just be 'ranked lower'—it risks falling into a zone where Google views the experience as too degraded to merit the first page.

Another vague point: the interaction between CWV and other signals. If two pages have identical CWV but one has a TTFB of 50 ms and the other 2 seconds, is it really neutral? [To be verified]—public data does not allow for a clear answer, and Google remains evasive about side effects.

In what cases does this rule not apply completely?

For e-commerce sites or high-traffic platforms, ignoring TTFB or server response time can degrade the experience to the point that behavioral metrics plummet. No matter how well you respect CWV, if 40% of visitors leave before even the DOM is built, Google will capture the signal.

Additionally, some ultra-competitive markets show that the highest-ranked sites have all their metrics in the green—not just CWV. Correlation does not imply causation, but it is observed that the winners never settle for the minimum standard.

What practical steps should be taken to optimize Core Web Vitals?

Start by identifying priority pages: those that generate organic traffic or that you are targeting for a strategic keyword. Use Search Console to spot URLs failing on CWV—this is where the ranking impact is measurable.

Then, focus your efforts on LCP (often the most penalizing): optimize the hero image, use a CDN, enable modern compression (WebP, AVIF), and preload critical resources. For CLS, reserve space for dynamic elements (ads, embeds) with fixed dimensions. For INP, reduce blocking JavaScript and defer non-essential scripts.

What mistakes should be avoided in this race for CWV?

Do not sacrifice real user experience for a Lighthouse score. A site that displays an empty skeleton in 0.5s to achieve a perfect LCP but leaves the user with an unusable page for 3 seconds is fundamentally flawed. CWV measure specific moments—not overall fluidity.

Another trap: optimizing only the homepage or landing pages tested by Google. CWV are measured in the field (through Chrome User Experience Report), meaning across all your visited pages. A slow product page can negatively impact your overall score even if your homepage is flawless.

How can I check that my site meets CWV thresholds?

The Search Console provides an aggregated view by page group (mobile/desktop). This is your strategic dashboard. PageSpeed Insights lets you test a specific URL under real conditions (field data) and lab data. But be cautious: lab scores do not always reflect real-world performance.

For continuous monitoring, set up tools like Lighthouse CI or third-party solutions (Calibre, SpeedCurve, Treo) that track your CWV over time. The goal is for 75% of your pages to be in the green across the three metrics to avoid any ranking penalties.

• Audit your strategic pages via Search Console (Core Web Vitals report)
• Optimize LCP as a priority: hero image, preloading, CDN, modern compression
• Stabilize CLS by fixing the dimensions of dynamic elements (ads, iframes)
• Reduce INP by deferring or removing non-essential blocking JavaScript
• Do not neglect the overall experience: a good CWV score does not compensate for a disastrous UX
• Test under real conditions (field data) rather than relying solely on lab tests