Does site speed affect SEO? Core Web Vitals, and AI search
·
Speed used to be a nice-to-have. Now Google measures it with three numbers, treats them as part of ranking, and they cut deeper than search: a slow, JavaScript-heavy page is also harder for AI engines to read and cite. Here is what actually matters, and what to fix first.
Yes, speed is part of how Google ranks
Google’s page-experience signals include Core Web Vitals, and Google states that good Core Web Vitals “align with what our core ranking systems seek to reward” (Understanding Core Web Vitals and Google Search). It is not the biggest lever, content relevance still wins, but between two comparable pages the faster, more stable one has the edge, and that edge compounds.
The three numbers (Core Web Vitals)
- LCP (Largest Contentful Paint) — loading: how fast the main content appears. Aim for under 2.5 seconds.
- INP (Interaction to Next Paint) — responsiveness: how fast the page reacts to a tap or click. Aim for under 200 ms. INP replaced FID as the responsiveness metric in March 2024 (Introducing INP).
- CLS (Cumulative Layout Shift) — stability: how much the layout jumps while loading. Aim for under 0.1.
Pass all three (web.dev: Web Vitals) and the page is “good.” These are real-user thresholds, not lab guesses.
It is a tiebreaker, not a trump card
The honest version: Core Web Vitals will not push thin content to the top, and a fast empty page will not beat a slow great one. But speed is a multiplier on everything else. It lowers bounce, lets Google crawl more of your site in the same budget, and removes a reason to rank you lower. Treat it as removing friction, not as a hack.
Slow pages lose AI traffic too (GEO)
This is the part people miss. AI answer engines, and the crawlers that feed them, fetch your page to read it. A page that is slow, or that only reveals its content after heavy JavaScript runs, is harder for those crawlers to render and parse, and many do not execute JavaScript fully or wait around. If the bot cannot see your content quickly, it cannot quote you. Fast, server-rendered, lightweight pages are easier for both Google and AI to read, so speed and clean HTML quietly decide whether you are even in the running to be cited.
What usually slows a page down?
- Render-blocking CSS and JavaScript in the
<head>that delay the first paint. - A heavy JavaScript bundle that ties up the main thread, the top cause of poor INP and slow interactivity.
- Images with no width/height (layout shift = CLS), and no compression or lazy-loading.
- A slow server response (TTFB) and no text compression (gzip/brotli).
- Too many third-party scripts (analytics, chat, ads), each blocking the thread.
Fix it in this order
- Stop blocking the first paint: defer or async non-critical JavaScript, inline only the critical CSS, load the rest asynchronously.
- Cut the JavaScript you ship: split it, lazy-load what is below the fold, drop unused libraries.
- Reserve space for images and embeds (set width/height) so nothing jumps.
- Turn on compression (gzip/brotli) and fix slow server responses.
- Audit third-party scripts and remove or defer the ones that are not earning their cost.
Quick answers
Is site speed a Google ranking factor? Yes, as part of page experience / Core Web Vitals, though content relevance matters more.
What is a good score? LCP under 2.5s, INP under 200ms, CLS under 0.1.
Does speed affect AI search? Indirectly but really: slow, JS-only pages are harder for AI crawlers to render and cite. Fast, server-rendered HTML helps.
Check your speed with GreenLight
GreenLight’s Speed check looks at the markup and server signals behind a fast page, render-blocking resources, heavy HTML, third-party scripts, image sizing, and compression, and tells you the exact thing to fix in plain language.