What speed metric does Google really prioritize for ranking?

Why does Google refuse to focus on a single metric?

The speed perceived by a user depends on dozens of factors: mobile network, CPU power, browser extensions, server geolocation. No synthetic metric captures this complexity.

Therefore, Google leverages multiple data sources: the Chrome User Experience Report (CrUX), which collects anonymized real-world metrics, Lighthouse calculations in controlled environments, and likely undocumented internal signals. This multi-sourcing prevents a site from gaming a single metric at the expense of real experience.

What do we mean by real data versus tool calculations?

Real data comes from Chrome browsers used by actual users: network latency, display times, real interactions. CrUX aggregates these measurements over rolling 28 days. This is the real-world truth, but it comes with a delay and requires sufficient traffic volume.

Tool calculations (Lighthouse, WebPageTest) simulate standardized conditions: throttled 4G connection, limited CPU, no cache. Useful for diagnostics, but they never perfectly reflect your actual audience. A site could score 95 on Lighthouse and show catastrophic Core Web Vitals in production if the server infrastructure is undersized.

How do these metrics impact ranking?

Google incorporates speed into the Page Experience signal, a ranking component since mid-2021. However, the exact weight remains opaque. Field observations show that a slow site on competitive queries loses positions, while an average site on a niche query sees no drastic impact.

Speed acts mainly as a quality filter: below a critical threshold (LCP > 4s, CLS > 0.25), you risk a progressive penalty. Beyond an acceptable threshold, gaining 200ms of LCP will not necessarily lead to a traffic jump. It’s an entry ticket, not a miracle lever.

• Google combines real data (CrUX) and simulations (Lighthouse) to assess speed
• No single metric dictates ranking: the algorithm weighs multiple signals
• Optimizing just one tool (e.g., PageSpeed Insights) does not guarantee a good ranking if real user experience remains degraded
• The weight of speed varies based on query competitiveness and overall content quality
• Monitoring CrUX via Search Console remains the benchmark for understanding Google’s perception of your speed

Is this multi-metric approach consistent with field observations?

Absolutely. We regularly see sites with a mediocre Lighthouse score (60-70) but green Core Web Vitals in Search Console, and vice versa. Clients who frantically optimize Lighthouse without looking at CrUX waste time.

The issue is that Google does not specify how it weighs these sources. Does CrUX take precedence over Lighthouse? What other internal signals are used? [To verify] as there is no official documentation detailing the exact formula. In practice, it appears that real-world data (CrUX) seems to carry more weight in ranking than simulations.

What areas of uncertainty remain in this statement?

Mueller refers to “various tools” without listing them. Lighthouse and CrUX are documented, but what other internal calculations does Google perform? Server signals (backend TTFB, CDN latency)? Non-public custom metrics? We do not know.

Another vague point: granularity. Does Google evaluate speed page by page, by template, or at the domain level? Observations suggest a mix: CrUX aggregates at the origin level (domain), but Lighthouse can be launched on specific URLs. A site with a fast homepage and slow product pages will have a mixed profile. [To verify] how the algorithm arbitrates these disparities.

Does Google’s stance change anything in our practices?

Not fundamentally. Serious SEO experts have already been monitoring CrUX + Lighthouse + WebPageTest for years. What Mueller confirms is that you should never focus on just one tool at the expense of others.

However, this invalidates simplistic approaches like “just pass the green on PageSpeed Insights”. No. You need to measure real user experience, segment by device and region, and address regressions as deployments occur. It’s an ongoing effort, not a one-time task.

What actionable steps should be taken to cover all bases?

First, install RUM monitoring (Real User Monitoring): Google Analytics 4 exposes Core Web Vitals, or use solutions like SpeedCurve, Cloudflare RUM, New Relic. This way, you will have your own real-world data, independent of CrUX, with segmentation by page, device, country.

Next, regularly audit with Lighthouse in a controlled environment (CI/CD, WebPageTest) to detect regressions before going live. But never settle for the overall score: dig into the listed opportunities (unoptimized images, blocking JS, fonts, third-parties).

What mistakes should be avoided in speed optimization?

A common mistake is to optimize only for the lab (Lighthouse) while neglecting the real world. For example, lazy-loading all images improves the Lighthouse score, but if above-the-fold images are lazy-loaded, the actual LCP skyrockets. Result: a good Lighthouse score, but degraded Core Web Vitals in production.

Another pitfall is to sacrifice functionality for a few points. Removing an essential analytics script or breaking a UX component to gain 5 performance points is counterproductive. Google values overall experience, not just raw speed.

How can I check if my site meets Google's expectations?

Log in to Search Console, section “Experience” > “Core Web Vitals”. This is the only official source that reflects what Google sees via CrUX. If your URLs are green (Good), you’re in the clear. If they’re orange or red, prioritize these pages.

Complement with PageSpeed Insights which combines CrUX data (if sufficient volume) and Lighthouse audit. Test your key templates (homepage, category, product page, article) on both mobile and desktop. If CrUX lacks enough data for your site, rely on internal RUM and Lighthouse, but be cautious: you’re navigating blind.

• Enable RUM monitoring to capture real user metrics
• Check Core Web Vitals in Search Console monthly (only official Google source)
• Audit critical templates with Lighthouse in CI/CD to avoid regressions
• Segment analyses by device, region, connection to identify weaknesses
• Never optimize just one tool: cross-reference CrUX, Lighthouse, RUM
• Prioritize high-impact optimizations (LCP, CLS) before cosmetic micro-optimizations