What actually counts for search rankings
Google’s page experience ranking system uses Core Web Vitals to evaluate how a site performs, but only one type of measurement matters for rankings. Google collects Core Web Vitals from real users browsing a site — this is known as field data. Lab tests, such as Lighthouse, measure performance in a controlled environment but have no direct impact on search position.
“Google only considers the Core Web Vitals field data when ranking your site. Google does not consider your Lighthouse score in any way for search ranking.”
Page experience is one factor among many in Google’s ranking algorithm. Content relevance and quality carry substantially more weight. However, when competing pages are closely matched on those fronts, page experience can be the deciding factor. Core Web Vitals stand apart from other ranking signals in two practical ways: you can improve them through your own engineering work, and Google is transparent about how well you’re doing.
Where to check your Core Web Vitals
For a view of how your entire application performs for page experience rankings, Google Search Console is the authoritative source.
For per-page data, Google’s PageSpeed Insights is the simplest tool. It presents results in two main sections: Core Web Vitals and Lighthouse.
What the field data measures
The top section of PageSpeed Insights, labeled “Discover what your real users are experiencing,” reports the 75th percentile of user experiences over the last 28 days, collected from Chrome on desktop and Android devices. Google uses only three metrics from this data to influence ranking: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). As of March 12, 2024, INP replaced First Input Delay (FID). These three scores are the exact numbers Google uses, averaged alongside similarly-performing pages on your application.
Google ranks mobile and desktop versions of your site separately, so PageSpeed Insights presents the data with tabs for each. The three metrics displayed below the Core Web Vitals section offer additional insight into user experience but do not affect search ranking.
Who is included in the data
The Chrome User Experience Report (CrUX) is the official dataset behind Core Web Vitals, and its methodology is publicly documented. To be counted in the report:
- Pages must be “sufficiently popular” and “publicly discoverable.” You can check whether your pages meet the popularity threshold via the CWV report in Search Console.
- Users must have usage statistic reporting enabled, be signed into Chrome with history sync on, and not use a Sync passphrase.
- Users must be on Chrome for desktop or Android.
A notable consequence: iPhone users are never counted. In markets where Android devices skew slower than iPhones, a larger share of the slower visits to your site may end up in the dataset. If your application doesn’t generate enough qualifying traffic, your Core Web Vitals cannot be measured and won’t factor into ranking at all.
User geography also matters, since field data reflects real traffic from all global regions counted equally. Slower connectivity in certain countries will bring your scores down. However, Google aggregates data over a 28-day sliding window, meaning any improvement — or regression — takes roughly a month to show its full effect in the reported numbers.
Lighthouse: The Lab-Measured Side of PageSpeed Insights
The second section of PageSpeed Insights, “Diagnose performance issues,” is where Google runs your page through Lighthouse, the same auditing engine built into Chrome DevTools. This lab-based testing environment is completely separate from the field data discussed earlier. Its purpose is to surface suggestions for improvement, not to supply metrics that are used in search rankings: nothing in Lighthouse counts toward your site’s position in Google Search results.
The prominent Lighthouse performance score is a weighted composite of First Contentful Paint (FCP), Speed Index, LCP, Total Blocking Time (TBT), and CLS. After applying Google’s weights, the actual Core Web Vitals account for just 50% of that total, and the newer INP metric is not included in the calculation at all.
Lighthouse generates its numbers by emulating a Moto G Power on a throttled network connection—hardware and network conditions that may differ dramatically from those of your real users. This gap between synthetic and real-world conditions is one of several challenges inherent to lab data; lab tests also can’t account for a user’s navigation path to your page or other context that shapes their actual experience. TBT illustrates the point: modern frameworks like React interrupt execution when a user event occurs, leading to good real-world INP, but the lab can’t observe real interactions and therefore can’t reflect that behavior.
What the Lighthouse Audits Are Still Good For
For all their limitations, lab results remain useful for diagnosing which parts of your application might be degrading user experience. Each category points developers toward specific problem areas:
- Performance: If your real-world Core Web Vitals fall outside acceptable ranges, Lighthouse flags likely culprits (for example, render-blocking scripts) and identifies the exact element that it counts as your LCP.
- Accessibility: The audit finds common errors named links or form fields lacking labels, and also catches low-contrast elements and links that are too small to tap.
- Best Practices: This catch-all category covers guidance that improves security and usability, such as using a proper doctype. It helps browsers parse your code easily and guards against some (but not all) common vulnerabilities like XSS.
- SEO: Suggestions here zero in on the technical side of crawling and indexing. These checks can be very helpful for debugging why your page isn’t ranking as expected, although they don’t represent a complete list of all SEO factors.
Iterating Faster: Real-Time Data as a Complement
Google’s 28-day sliding window remains the authoritative reporting cycle for ranking purposes, but it is a slower feedback loop. Shipping a change today means waiting up to a month to observe its full effect in PageSpeed Insights—and then waiting another month if you must correct a regression.
To close that gap, Vercel’s Speed Insights taps into the Core Web Vitals metrics that Chromium browsers already expose on real user sessions. Because the data comes from users, it reflects actual conditions and appears as soon as those visitors encounter your site. The service keeps the same 75th-percentile view as Google, then lets you drill down to the 90th, 95th, and 99th percentiles, or shift the time window from the default 28 days to a shorter or more custom range aligned with a release.
Speed Insights is tied to Vercel’s deployment model, so you can compare performance on a per-branch or per-deployment basis and see the net effect of each git push. Data is also filterable by distinct application routes and by geographic region, making it easier to see where resources are needed for specific audiences — all while keeping metrics uninfluenced by any individual visitor or IP address, in line with data-privacy regulations.
Where to Go Next
For coverage of how to optimize the individual metrics, Vercel publishes a deep dive aimed at JavaScript frameworks and its own tooling. Google’s LCP, CLS, and INP guides remain the authoritative technical references.
The bottom line from all of this measurement context:
- Core Web Vitals are the most transparent ranking signal in Google Search, because you have direct access to the same data Google uses to rank your site.
- Lighthouse, no matter which number you focus on, has zero impact on your ranking.
- For fast iteration on the metrics that matter, real-time tooling like Speed Insights offers the immediacy that a 28-day reporting window cannot.
