Does page speed affect SEO? What Google has said and what the data does

Speed matters for SEO, but only up to a point. Google uses Core Web Vitals as a ranking signal at the Good thresholds. It is smaller than relevance and content.

Google applies this from field data. That is what real Chrome users saw over the last 28 days at the 75th percentile, per URL or, if there is not enough data, per origin.

If you pass the thresholds, faster still will not move rankings much. If you fail, fixing the specific vital can help, but content wins ties. Build for users first, then clear the vitals.

Core Web Vitals, as of 2026:

• Largest Contentful Paint, Good up to 2.5 s, Poor above 4 s
• Cumulative Layout Shift, Good up to 0.1, Poor above 0.25
• Interaction to Next Paint, Good up to 200 ms, Poor above 500 ms

INP replaced First Input Delay in March 2024. INP measures the worst interaction in the visit, while ignoring one extreme outlier per fifty on very interactive pages. It covers input delay, processing, and the time to paint the next frame.

Field data comes from opted in Chrome users on Android and desktop. iOS Chrome is not counted. The Search Console Core Web Vitals report and the field section in PageSpeed Insights read this dataset.

Mobile first indexing is complete since 2023. Googlebot uses the smartphone crawler. The mobile field data is the one you should watch first for Search.

Your rankings care about field data. Your debugging uses lab data. You need both, in that order.

Lighthouse gives four category scores from 0 to 100. The Performance score weights Total Blocking Time 30%, LCP 25%, CLS 25%, First Contentful Paint 10% and Speed Index 10%. Scores vary between runs. The score is not a ranking factor.

PageSpeed Insights shows both. The top card, Discover what your real users are experiencing, is the one that maps to Search. If that shows Not enough data it falls back to origin level or shows nothing. The lower section is a Lighthouse run from a Google server. If the two disagree, the field data wins for SEO decisions, and the lab run guides your fixes.

Conversion. Faster pages convert better. You feel it on a checkout and a sign up. It is the simplest reason to care even if you already pass the thresholds.

Crawl. Faster servers respond sooner, so Googlebot can fetch more without strain. For a small site, this keeps new pages and changes fresher in the index. It will not make weak pages rank, but it removes a bottleneck.

AI answers that fetch pages. Some assistants pull and cache sources. Fast responses cut timeouts and reduce the chance your content is skipped when many sources are fetched at once. You want your HTML and your hero content to arrive first.

Aim to pass the three Core Web Vitals on mobile: LCP under 2.5 s, CLS under 0.1, INP under 200 ms. Focus on the 75th percentile in field data. Fix the one that fails first. Do not chase a perfect Lighthouse score for its own sake.

• FCP and TTFB are helpful diagnostics. Good FCP is up to 1.8 s and good TTFB is up to 0.8 s. They are not ranking factors by themselves.
• Total Blocking Time is lab only. Good up to 200 ms. It proxies INP during a Lighthouse run. Reduce it to improve INP.

1. 1

   Test the exact page and device that matters

   Paste the URL of a money page, for example https://yourproduct.com/pricing. Start with Mobile. Desktop later.

2. 2

   Read the field card first

   Look for Core Web Vitals assessment: Passed or Failed. If it shows origin data, you need more real visits before a per URL view appears.

3. 3

   Note which vital fails, and by how much

   If LCP is 3.1 s at p75, you need to save at least 0.6 s. If INP is 320 ms, plan for smaller scripts and fewer long tasks.

4. 4

   Use the lab audits to find causes

   Open the Opportunities and Diagnostics. Look for render blocking resources, large LCP element, third party impact, main thread work, font display.

5. 5

   Re run after each change

   Expect score variance. You are looking for consistent patterns, not one perfect run. Check field data again after changes roll out and you have 28 days of traffic.

If your URL has too little traffic, Search Console’s Core Web Vitals report can show sitewide patterns. It also uses the same CrUX data and the same pass or fail thresholds. Group level issues point you to template fixes.

Start with the largest element first. LCP is often the hero image or a headline block. Then remove layout shifts. Then keep interaction snappy. Here is what usually pays on a marketing site or a SaaS app shell.

• Do not lazy load the hero image. Add fetchpriority=high to it. If it is a CSS background, add a <link rel="preload" as="image">. Serve AVIF or WebP with responsive srcset and sizes.
• Inline critical CSS for above the fold. Load the rest with media=print and onload. Remove @import. Defer or async scripts. type=module defers by default.
• Set width and height or aspect-ratio on every img, video and iframe. Reserve min-height for ad and embed slots. Show notices in overlays, not as banners that push content down.
• Match font metrics to avoid shifts. Use font-display: swap or optional. Preload only the face used above the fold as WOFF2 with crossorigin. Self host. Subset with unicode-range. A variable font can replace several files.
• Cut third party scripts to what you truly need. Load embeds on interaction behind a facade. Defer analytics. Preconnect to the few origins that must load early. Keep the tag manager container small.
• Reduce server time to first byte. Cache HTML or pre render. Put a CDN in front. Serve over HTTP/2 or HTTP/3. Keep connections warm with keep alive. If your stack supports it, send 103 Early Hints for critical assets.
• Tame hydration. If you use a large framework, split routes, avoid blocking the main thread, and prioritise visible updates. Long tasks should yield. Use scheduler.yield or small setTimeout chunks. Move heavy work to a Web Worker.
• Keep the DOM smaller. Avoid deep nested wrappers that do nothing. Batch style reads and writes to avoid forced reflows after changes.

A fixed page looks like this: on /pricing, the hero image is not lazy loaded and uses AVIF with srcset, the CSS above the fold is inlined, only one font is loaded with swap and matched metrics, third party scripts wait until after load, and the server caches the HTML. LCP drops under 2.5 s and CLS is under 0.1 on mobile field data after the release has seen enough visits.

• INP problems: long tasks on the main thread, heavy event handlers, hydration of large frameworks, a large DOM, sync layout reads after writes, third party scripts. Remedies: break long tasks, render the visual change first, fewer and smaller scripts, Web Workers, a smaller DOM.
• CLS problems: media without fixed dimensions, banners injected above content, web fonts that change metrics, content inserted above the fold after load, animations of layout. Remedies: width and height on media, reserved space for dynamic slots, overlays for notices, size adjust and ascent override for fonts, transform only for animations.
• LCP problems: slow TTFB, lazy loaded or late discovered hero, unoptimised images, no priority. Remedies: cache or pre render HTML, no loading=lazy on hero, fetchpriority=high, preload when it is a CSS background, responsive images, AVIF or WebP, a CDN, server rendered HTML that names the image in the document.

1. 1

   Pick two URLs that earn

   For example, /pricing and /guides/getting-started. Test Mobile in PageSpeed Insights. Note the field pass or fail and which vital is over the line.

2. 2

   Save the obvious LCP seconds

   Remove loading=lazy from the hero image, add fetchpriority=high, serve a compressed next gen format, preload if it is a CSS background. Re test.

3. 3

   Stop layout shifts at the top

   Add width and height to the hero image, set min-height for any dynamic bars, and move notices into an overlay. Re test CLS in lab.

4. 4

   Defer what you can

   Add defer or async to scripts, load embeds on click, and move analytics after load. Check the main thread time and third party impact in Lighthouse.

5. 5

   Ship one font or a system stack

   Self host one WOFF2 face above the fold with font-display: swap and matched metrics. Remove unused weights and families.

6. 6

   Cache HTML and enable HTTP/2 or HTTP/3

   Turn on server caching for the home and top templates. Put a CDN in front if you have it. Check TTFB in the next run.

Then leave it to gather field data. The Core Web Vitals assessment updates as your 28 day window fills with the new loads. If you still fail one metric, target that one next. Do not keep polishing a Lighthouse score that already points to the same fixes.

• First Contentful Paint is a leading indicator. Good up to 1.8 s. If FCP is slow, your HTML or render blocking CSS is late.
• Time to First Byte covers the network and server. Good up to 0.8 s. If you are on a distant origin without caching, expect a slow LCP after it.
• Render blocking resources stall first paint. Inline critical CSS. Load the rest with media=print and onload. Defer scripts and remove @import.
• Fonts can shift layouts. Use font display swap or optional. Preload only what paints above the fold. Match metrics or use a system stack.
• Lazy loading is native for images and iframes. Do not lazy load anything visible at first paint. decoding=async lets the browser decode off the critical path.
• Tag managers can grow without anyone noticing. Audit the container. Remove dead tags. Load marketing tools after the first paint unless a team needs them on first view.