PERFORMANCE

Page Speed and SEO: How Performance Affects Google Rankings

Page speed became an official Google ranking factor in 2021. Here's how LCP, INP, and CLS affect rankings, what actually slows pages down, and how to fix each metric.

Published July 12, 2026 · 9 min read

Run a free audit →

Page speed has been a Google ranking signal since 2010 for desktop and 2018 for mobile, but the 2021 Page Experience update made it a direct, measurable factor via Core Web Vitals. Google now uses three specific metrics — LCP, INP, and CLS — to evaluate page experience, and they directly influence where pages rank, especially when content quality is close between two competitors.

This guide explains which speed metrics matter, how much they affect rankings, what causes each one to fail, and how to fix it.

How page speed affects Google rankings

Google uses a set of metrics called Core Web Vitals to measure page experience:

  • LCP (Largest Contentful Paint) — how long it takes for the largest visible element (usually a hero image or headline) to render. Good: ≤2.5s. Poor: >4.0s.
  • INP (Interaction to Next Paint) — how quickly the page responds to clicks, taps, and key presses. Good: ≤200ms. Poor: >500ms. INP replaced FID (First Input Delay) in March 2024.
  • CLS (Cumulative Layout Shift) — how much the page layout shifts unexpectedly while loading. Good: ≤0.1. Poor: >0.25.

Google uses field data — real measurements from Chrome users over a 28-day window — not lab simulations. This data comes from the Chrome User Experience Report (CrUX) and is what Google Search Console reports under Core Web Vitals. Lighthouse scores (from PageSpeed Insights or DevTools) are lab simulations, which are useful for debugging but are not the scores Google uses for ranking.

The ranking impact is real but bounded. Core Web Vitals are a tiebreaker: two pages with equivalent content will rank differently if one has a "Good" CWV profile and the other has "Poor." But a page with genuinely better content and "Needs Improvement" metrics will still outrank a mediocre page that passes CWV. Speed alone won't save thin content, and failing CWV alone won't tank a strong page.

The biggest practical risk is mobile rankings. Google uses mobile-first indexing — it evaluates the mobile version of your page for ranking. Mobile CrUX data is typically worse than desktop (slower connections, weaker CPUs), so sites that perform well on desktop but have unoptimized mobile experiences are most at risk.

LCP: largest contentful paint

LCP measures when the largest visible element renders. The LCP element is almost always one of: a <img> tag, a background-image CSS element, a <video> poster frame, or a large block of text.

Common causes of poor LCP:

  1. Unpreloaded hero image. The browser doesn't discover the hero image until it parses the <img> tag deep in the HTML. By then it may have already spent time on render-blocking CSS and JavaScript.

    Fix: Add a preload link in <head>:

    <link rel="preload" as="image" href="/hero.webp" fetchpriority="high" />

    In Next.js, set priority on the hero image:

    <Image src="/hero.webp" priority alt="Hero" width={1200} height={630} />

  2. Render-blocking resources. CSS and synchronous JavaScript in <head> block rendering. Every millisecond spent parsing a synchronous script before the browser paints is milliseconds added to LCP.

    Fix: Load third-party scripts with async or defer. Use next/script with strategy="afterInteractive" or strategy="lazyOnload" for analytics, chat widgets, and tag managers.

  3. Slow server response (TTFB > 600ms). If the server is slow, everything downstream is delayed. LCP can't be fast if the HTML arrives late.

    Fix: Use a CDN for static assets, enable HTTP/2, add server-side caching, or move to edge rendering for pages with personalised content.

  4. Image not in WebP/AVIF format. Serving JPEG or PNG images adds download time compared to modern formats.

    Fix: Use next/image (automatically converts to WebP/AVIF) or convert images during build. Serve via a CDN with image optimisation (Cloudflare Images, Imgix, Vercel Edge).

  5. Large image without width and height attributes. The browser can't allocate space until the image downloads, delaying paint.

    Fix: Always specify width and height on <img> and <Image> elements. Next.js enforces this; raw HTML doesn't.

INP: interaction to next paint

INP measures how long it takes for the page to visually respond to user input. A user clicks a button; INP measures from the click to when the browser next paints something — a loading state, updated content, or any visible change.

Common causes of poor INP:

  1. Long JavaScript tasks on the main thread. JavaScript runs on the browser's main thread. A synchronous task that takes 300ms blocks all user interactions during that time. The browser can't respond to clicks while a long task is running.

    Fix: Break long tasks into smaller chunks using setTimeout(fn, 0) or scheduler.postTask(). Defer non-critical initialisation until after first user interaction.

  2. Heavy third-party scripts. Chat widgets, analytics platforms, and A/B testing scripts often run expensive initialisation on the main thread, creating long tasks that hurt INP.

    Fix: Lazy-load third-party scripts. Use loading="lazy" on iframes, and next/script strategy policies to defer non-critical third parties.

  3. Unoptimised event handlers. A click handler that synchronously re-renders a large component, re-queries the DOM, or makes a synchronous network request can produce high INP.

    Fix: Debounce high-frequency event handlers. Move expensive work off the critical path. Use startTransition in React to mark non-urgent state updates as interruptible.

  4. Large React bundles causing slow hydration. In server-rendered React apps, the page HTML is visible but non-interactive until JavaScript hydrates the DOM. During hydration, the main thread is busy — any user interaction during this window will have high INP.

    Fix: Use React Server Components to reduce the JS that needs to hydrate. Code-split aggressively. Defer hydration of non-critical islands.

CLS: cumulative layout shift

CLS measures unexpected layout movement. When an image loads without reserved space, an ad slot expands, or a cookie banner pushes content down, CLS accumulates.

Common causes of poor CLS:

  1. Images without explicit dimensions. When the browser downloads an image without knowing its size, it allocates no space — then shifts content when the image dimensions are known.

    Fix: Always set width and height on images. Use aspect-ratio CSS as an alternative:

    img {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
}

  2. Ads, embeds, and iframes without reserved space. Ad slots that expand after load are a top CLS source.

    Fix: Reserve space for ad slots with a minimum height. Use min-height on the container so the layout doesn't shift when the ad loads.

  3. Web fonts causing FOUT/FOIT. When a custom font loads and replaces the fallback font, text reflows if the fonts have different metrics, producing layout shift.

    Fix: Add font-display: swap to @font-face declarations. Use next/font — it self-hosts fonts and automatically adds font-display: swap and size-adjust to minimise reflow.

  4. Dynamic content injected above existing content. Banners, cookie notices, and personalised content blocks that appear above existing page content push everything down.

    Fix: Position banners so they don't affect surrounding layout (fixed positioning, or pre-reserved space). Inject personalised content into pre-reserved containers.

Field data vs. lab data

Lab data (Lighthouse, PageSpeed Insights lab tab, DevTools):

  • Simulated on a fixed device profile (desktop: no throttling; mobile: simulated Moto G4 on 4G)
  • Deterministic and reproducible — useful for debugging specific issues
  • Does NOT reflect real user experiences on their actual devices and connections
  • NOT the data Google uses for ranking

Field data (CrUX, PageSpeed Insights field tab, Search Console Core Web Vitals report):

  • Real measurements from Chrome users over a 28-day rolling window
  • Varies by device, connection, geography, and traffic patterns
  • IS the data Google uses for ranking
  • Available only for pages/origins with sufficient traffic (Google anonymises small-traffic pages)

The implication: a page can score 98 on Lighthouse and still have "Poor" CrUX field data because real users are on slow connections or low-power devices. Always check the CrUX field data, not just the lab score, when evaluating ranking impact.

How to check your Core Web Vitals

  1. Google Search Console → Core Web Vitals report. Shows field data per URL and page group, segmented by mobile/desktop. The most direct signal for ranking impact.

  2. PageSpeed Insights (pagespeed.web.dev). Shows both CrUX field data (if available) and a fresh Lighthouse lab run for any URL, with specific fix recommendations.

  3. Chrome Web Vitals extension. Shows live CWV measurements as you browse your own site — useful for identifying which specific user interactions cause INP spikes.

  4. DeepSEOAnalysis audit. The full audit pulls CrUX field data for every audited page and scores performance against the Good/Needs Improvement/Poor thresholds — alongside all other SEO checks in a single prioritised report.

The performance/SEO interaction to watch

JavaScript rendering and LCP: Pages that render content via client-side JavaScript have longer LCPs because Googlebot must download, parse, and execute JavaScript before it can see any content. Even if Googlebot eventually renders the page (it does, in a second wave), the render time is added to perceived LCP for field-data users. Static HTML pages and server-rendered pages have a fundamental LCP advantage.

Font loading and CLS: Switching from Google Fonts CDN to self-hosted fonts (via next/font) typically improves both LCP (eliminates a cross-origin DNS lookup) and CLS (eliminates font-swap reflow with size-adjust). This is a high-impact, low-risk change.

Image optimisation and LCP: For most content sites, the LCP element is a hero image. Getting this right — preloaded, appropriately sized, served in WebP/AVIF from a CDN — typically produces the largest single LCP improvement.

Frequently asked questions

Does page speed directly affect Google rankings?

Yes — Core Web Vitals (LCP, INP, CLS) became an official Google ranking signal with the Page Experience update in June 2021. INP replaced FID as the interaction metric in March 2024. The effect is real but bounded: speed is a tiebreaker when content quality is similar between two competing pages. Better content with mediocre speed typically still outranks thin content with perfect scores.

Which is more important for ranking: Lighthouse score or CrUX field data?

CrUX field data is what Google uses for ranking — not Lighthouse. Lighthouse is a lab simulation useful for debugging, but it doesn't measure real user experiences on their actual devices. A page can have a Lighthouse score of 95 and "Needs Improvement" CrUX field data if your real users are on slow mobile connections. Always check the CrUX data in Google Search Console or PageSpeed Insights to understand your ranking signal.

What is a good LCP time for SEO?

Google's "Good" threshold for LCP is 2.5 seconds or faster, measured at the 75th percentile of real user visits (CrUX field data). This means 75% of visits must render the LCP element within 2.5 seconds. "Needs Improvement" is 2.5–4.0 seconds; "Poor" is above 4.0 seconds. For ranking purposes, the "Good" threshold is what you're aiming for.

My Lighthouse score is 90+ but my Search Console shows "Poor" CWV. Why?

Lighthouse runs a controlled lab simulation on a fast desktop or a mid-range mobile profile. Your real users may be on slower connections (3G, rural broadband) or older devices where JavaScript execution takes much longer. CrUX field data aggregates actual visits, which can be dramatically slower than a lab simulation. This discrepancy is most common for JavaScript-heavy sites where real device performance varies widely. Fix priority: focus on what CrUX shows, not what Lighthouse shows.

MORE FROM THE BLOG

Related articles

10 min read

On-Page SEO: The Complete Checklist for 2026

On-page SEO covers every element you control on the page itself — title tags, headings, content, internal links, structured data, and image optimisation. Here's the full checklist and what to prioritise.

Read →

8 min read

Duplicate Content and SEO: What Causes It, What Harms Rankings, and How to Fix It

Duplicate content means the same text appears at multiple URLs — Google picks one version to index and ignores the rest. Here's what actually causes it, when it damages rankings, and the canonical tags and redirects that fix each case.

Read →

8 min read

XML Sitemap: What It Is, How to Create One, and What to Check

What an XML sitemap does, what to include and exclude, how to submit it to Google, and how to check it for common errors — with examples for Next.js, WordPress, and static sites.

Read →

Run DeepSEOAnalysis on your own site.

Free, no signup. Technical SEO, Core Web Vitals, structured data, and AI visibility in one report.

Run a free audit →