Google uses two sources of speed data: lab data (measurements from Lighthouse running in a controlled environment) and field data (real user measurements from the Chrome User Experience Report, called CrUX). Lab data is used in Google Search Console and PageSpeed Insights for diagnosis. Field data is what Google actually uses in ranking — specifically the CrUX data for your site aggregated over the prior 28 days.
Key Takeaways
- Google ranks pages using field data (CrUX 28-day real-user data), not lab scores — a good Lighthouse score doesn't guarantee a good ranking signal
- The Page Experience ranking signal only applies to pages in the "Poor" CWV threshold — fixing a "Needs Improvement" page to "Good" matters for users, not directly for the ranking signal
- Core Web Vitals signals are page-level in theory but in practice Google uses domain-level patterns when page-level data is insufficient
- Content relevance and authority still outweigh speed — a slow page with strong topical authority ranks above a fast page with weak relevance
- TTFB is not a direct ranking factor but a slow TTFB delays LCP, which is
The Core Web Vitals Ranking Signal
Google's Page Experience signal became a ranking factor in mid-2021. It uses three Core Web Vitals metrics:
| Metric | What it measures | Good | Needs Improvement | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Loading performance — time to render the largest visible content element | ≤ 2.5s | 2.5–4s | > 4s |
| INP (Interaction to Next Paint) | Responsiveness — time from user interaction to next visual update | ≤ 200ms | 200–500ms | > 500ms |
| CLS (Cumulative Layout Shift) | Visual stability — unexpected layout movements during load | ≤ 0.1 | 0.1–0.25 | > 0.25 |
Google uses the 75th percentile of field data for each metric. A page "passes" Core Web Vitals only if all three metrics are in the Good threshold at the 75th percentile. A single failing metric — most commonly LCP — fails the entire page.
What Speed Data Google Uses for Ranking
Google uses Chrome User Experience Report (CrUX) data — real user measurements from Chrome users who have opted into usage statistics. This is aggregated and anonymised data showing how real visitors experienced the page.
If your page doesn't have enough CrUX data (low traffic), Google falls back to domain-level aggregated data. This means low-traffic pages are effectively scored based on the domain's overall Core Web Vitals health, not the specific page.
TTFB and LCP — The Indirect Connection
TTFB (Time to First Byte) is not a direct Core Web Vitals metric and not directly used in ranking. But a slow TTFB delays everything downstream, including LCP. A server that takes 1.5s to respond makes it almost impossible to achieve a sub-2.5s LCP, because the main HTML document (which triggers all subsequent resource loading) hasn't arrived yet.
For most sites, reducing TTFB from 1.5s to 300ms (by moving to a faster server, using a CDN, or implementing caching) is the single highest-leverage performance improvement available — not because TTFB is a ranking signal, but because it's the bottleneck preventing LCP from being Good.
How to Measure Your Core Web Vitals
Google Search Console → Core Web Vitals report: Shows field data per page group, with pass/fail threshold. The most reliable source of how Google actually sees your site.
PageSpeed Insights: Shows both lab (Lighthouse) and field (CrUX) data for any URL. The "Field Data" box at the top is what matters for ranking; the "Lab Data" section is for diagnosis.
Page Speed Inspector: Server-side timing (DNS, TCP, TLS, TTFB, download) plus HTML analysis — render-blocking resources, image dimension issues, third-party scripts. Covers the TTFB and resource-loading dimensions of LCP.
What to Fix First
For most sites, fixing LCP is the highest priority because LCP is the most commonly failing metric. The most impactful LCP fixes:
- Reduce TTFB with a CDN or server-side caching (fastest win on high-traffic sites)
- Preload the LCP image element with
<link rel="preload" as="image" href="hero.webp"> - Remove render-blocking JavaScript and CSS that delay the browser from rendering the LCP element
- Convert images to WebP or AVIF (smaller file = faster decode + display)
- Serve images from the same origin or a CDN with low latency — cross-origin LCP images incur an additional TCP connection
Measure TTFB, Render-Blocking Resources & Third-Party Script Load
Free, no signup. The Page Speed Inspector reports server-side timing, every render-blocking script and stylesheet, LCP candidate image URL, and third-party script count — the variables most directly tied to LCP and INP rankings.
Try the Page Speed Inspector Free →Affiliate disclosure: Some links on this page may be affiliate links. We only mention tools we've personally used and have an honest opinion about. Affiliate revenue helps keep ByteWaveNetwork's tools free and maintained. We are not paid by any of the tools compared in this article for favorable coverage.