Key Takeaways
- Core Web Vitals (LCP, CLS, INP) are Google's specific page experience signals — a "Poor" rating on any metric can suppress rankings relative to comparable pages with "Good" ratings; moving from "Poor" to "Needs Improvement" is less impactful than moving to "Good"
- Google uses field data (real user measurements from Chrome, aggregated in CrUX) for Core Web Vitals ranking signals — not lab data from tools like PageSpeed Insights; a fast lab score doesn't guarantee good field data if real users experience slow connections
- TTFB (Time to First Byte) is not a direct Core Web Vitals metric but affects LCP — every 100ms of TTFB delay directly adds to LCP; a slow server is often the root cause of LCP failures
- Speed's indirect SEO impact often exceeds its direct ranking impact: pages that load in under 2 seconds typically have 15–35% lower bounce rates than pages loading in over 4 seconds; lower bounce rates correlate with better dwell time, more pageviews, and higher return visit rates
- The PageSpeed Insights score (0–100) is a diagnostic tool, not a ranking signal — Google does not use the PSI lab score in its ranking algorithm; only field data CWV thresholds (Good / Needs Improvement / Poor) affect rankings
Which Speed Metrics Actually Affect Rankings
Google's page experience ranking signal uses Core Web Vitals, assessed from CrUX field data. There are three metrics, each measuring a different dimension of the loading experience:
| Metric | Measures | Good | Needs Improvement | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Loading performance | ≤2.5s | 2.5–4.0s | >4.0s |
| CLS (Cumulative Layout Shift) | Visual stability | ≤0.1 | 0.1–0.25 | >0.25 |
| INP (Interaction to Next Paint) | Responsiveness | ≤200ms | 200–500ms | >500ms |
The ranking impact is binary at the thresholds: pages with "Poor" scores are disadvantaged versus pages with "Good" scores on equivalent content quality. The transition from "Needs Improvement" to "Good" provides the most ranking benefit; pages already at "Good" see diminishing returns from further optimisation.
A critical point that many guides miss: Google evaluates these metrics using field data from the Chrome User Experience Report (CrUX) — real measurements from real users browsing your site. Lab scores from PageSpeed Insights or Lighthouse reflect a controlled test environment and do not map directly to ranking signals. A site can score 95 in PSI lab mode and still have "Poor" LCP in CrUX if real users are on slow mobile connections.
TTFB — The Upstream Cause
TTFB (Time to First Byte) is not a Core Web Vitals metric, but it sets the floor for all other metrics. If TTFB is 2 seconds, LCP cannot be below 2 seconds regardless of how optimised the frontend is. The browser can't start parsing HTML, loading images, or rendering anything until the first byte of the HTML response arrives.
Google's TTFB guidance: Good ≤800ms, Needs Improvement 800ms–1800ms, Poor >1800ms.
Common TTFB causes:
- Slow server processing — database queries, server-side rendering, unoptimised application code
- No server-side caching — every request generating a fresh response rather than serving a cached HTML page
- No CDN — serving all requests from a single origin server means users far from that origin experience high network latency
- DNS lookup time — slow DNS resolution adds directly to TTFB; using a fast DNS provider (Cloudflare, AWS Route 53) typically saves 20–100ms
Fix priority: CDN with edge caching first (highest impact for geographically distributed traffic), then server-side caching with Redis or Memcached, then application-level optimisation.
LCP Optimisation — Highest Ranking Impact
LCP is the most impactful Core Web Vitals metric for SEO because the transition from "Poor" to "Good" is achievable on most sites with focused effort, and LCP correlates strongly with bounce rate. A 1-second improvement in LCP can reduce bounce rate by 8–12% on mobile.
The LCP element is usually one of: the hero image, a large heading text block, or a video thumbnail. Identify it in PageSpeed Insights under "Largest Contentful Paint element" before starting optimisation — fixing the wrong element wastes time.
LCP optimisation checklist:
- Hero image served as WebP or AVIF (25–50% smaller than equivalent JPEG at the same perceived quality)
- Hero image has
fetchpriority="high"andloading="eager"(never lazy-load the LCP image) <link rel="preload" as="image" href="hero.webp">in<head>so the browser discovers it early in the critical path- Hero image hosted on the same origin or a CDN (avoid slow third-party image hosts)
- No render-blocking CSS or JavaScript above the fold that delays the browser's ability to start rendering
- TTFB ≤800ms (see the section above — LCP cannot win if TTFB is the bottleneck)
CLS Optimisation
CLS measures layout shift during page load — how much visible content jumps around as assets load. A CLS score above 0.1 is usually noticeable to users as text or buttons jumping when they're about to click. Three causes account for the majority of real-world CLS failures.
Images without dimensions. When the browser doesn't know an image's dimensions before it loads, the page reflows as the image arrives and the browser discovers its size. Fix: always set explicit width and height attributes on <img> elements. Modern browsers use these to reserve space before the image loads, even when CSS overrides the displayed size.
Web fonts causing FOUT/FOIT. Text reflows when custom fonts load and swap in. Fix: add font-display: swap or font-display: optional in @font-face declarations; preload critical font files with <link rel="preload" as="font" crossorigin> in <head>.
Dynamically injected content. Cookie banners, ads, and dynamically loaded content inserted above existing content push everything below it downward. Fix: reserve space for injected content with CSS min-height before it loads; load ad slots below visible content or in explicitly sized containers.
INP Optimisation
INP (Interaction to Next Paint) replaced FID (First Input Delay) as a Core Web Vital in March 2024. Unlike FID, which only measured the first interaction, INP measures responsiveness across all interactions throughout the page session — clicks, taps, and keyboard inputs. A page that loads quickly but freezes when users interact with it will have a poor INP score.
Common INP culprits:
- Long JavaScript tasks blocking the main thread — any JS task over 50ms blocks the browser from responding to user input until it completes
- Expensive DOM operations on click/input events — reading computed styles, forced synchronous layouts, or large tree mutations in event handlers
- Unoptimised third-party scripts — analytics, chat widgets, and ad scripts running on the main thread during interactions
Fix: break long tasks into smaller chunks using setTimeout or requestIdleCallback; defer non-critical third-party scripts until after page interaction with <script defer>; audit third-party scripts with the Waterfall view in Chrome DevTools Performance panel.
Speed's Indirect SEO Impact
The direct ranking impact of Core Web Vitals is real but bounded — it's a tiebreaker signal, not a primary ranking factor. Content quality, backlinks, and topical relevance all outweigh page experience for most queries. The bigger SEO case for speed is indirect, through its effect on user behaviour.
The behavioural signals most affected by page speed:
- Bounce rate — pages loading over 4 seconds have significantly higher bounce rates than pages loading under 2 seconds; users leave before seeing the content, reducing all downstream engagement signals
- Dwell time — slow pages that do load often see users leave sooner; less time reading correlates with lower perceived quality of the content, which feeds back into search quality evaluations over time
- Pages per session — slow subsequent page loads reduce how many pages a user visits in a session; for content sites, this reduces internal link equity flowing through the crawl graph
- Return visit rate — users who had a poor experience on a slow site are less likely to return; return visits are a signal of brand authority that correlates with stronger rankings on branded and semi-branded queries
These signals don't map to confirmed individual ranking factors, but they consistently correlate with ranking performance across competitive analyses. Sites that invest in speed tend to improve on multiple correlated engagement metrics simultaneously, compounding the ranking effect beyond what Core Web Vitals alone would predict.
What to Fix First — A Prioritised Approach
Start with a Page Speed Inspector measurement to establish your baseline TTFB, identify render-blocking resources, and flag missing image dimensions. Then work through in this order:
1. TTFB first. If TTFB is above 800ms, no amount of frontend optimisation will get LCP to "Good." Add a CDN or server-side caching before anything else.
2. LCP element. Convert to WebP/AVIF, add fetchpriority="high", and preload the image. This is the highest-impact single fix for most sites where TTFB is already acceptable.
3. CLS. Audit all images for missing dimensions. Add font-display: swap. Reserve space for ad slots and cookie banners. CLS is often the easiest "Poor" metric to move to "Good" once the causes are identified.
4. INP. Profile with Chrome DevTools on a mid-range mobile device. Long tasks and expensive event handlers are usually concentrated in a small number of third-party scripts or custom UI components.
5. Verify in field data. After making changes, check CrUX field data in PageSpeed Insights or Google Search Console's Core Web Vitals report. Field data updates on a 28-day rolling window — changes you make today take up to 4 weeks to fully reflect in CrUX.
Measure Your TTFB, LCP Contributors, and Compression
Free, no signup. The Page Speed Inspector measures DNS, TCP, TLS, TTFB, download time, and HTTP version — plus HTML analysis checks for render-blocking resources, missing image dimensions, and missing lazy loading that contribute to Core Web Vitals failures.
Inspect Your Page Speed 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.