Short answer: yes, site speed affects your rankings, but not by nearly as much as most website owners assume, and not for the reason most people think. Google has said publicly, more than once, that Core Web Vitals are one of hundreds of ranking signals and function closer to a tie-breaker between pages that are already similarly relevant — not a lever that will push a mediocre page above a genuinely better one. If your content and links are weak, fixing your Largest Contentful Paint score will not rescue your rankings.
Where site speed earns its reputation isn’t the search results page — it’s what happens after someone clicks through. That’s the part worth actually fixing, and it’s also, increasingly, relevant to whether AI systems can fetch and cite your content at all. Let’s separate the myth from the mechanism.
What are Core Web Vitals, actually?
Core Web Vitals are three specific, measurable aspects of how a page feels to load and use. Google publishes thresholds for “good,” “needs improvement,” and “poor” for each:
| Metric | What it measures | Good threshold |
|---|---|---|
| LCP (Largest Contentful Paint) | How long until the biggest visible element (usually a hero image or heading) finishes loading | Under 2.5 seconds |
| INP (Interaction to Next Paint) | How quickly the page responds when someone clicks, taps, or types | Under 200 milliseconds |
| CLS (Cumulative Layout Shift) | How much visible content jumps around as the page loads (think: a button that moves right as you’re about to tap it) | Under 0.1 |
Note that INP replaced the older First Input Delay (FID) metric as the responsiveness measure — if you’re reading older advice that mentions FID, it’s out of date. All three metrics are measured from real visitor data (what Google calls the Chrome User Experience Report, or CrUX), not a lab test, which is part of why two websites that look equally fast to a developer can score very differently depending on their actual audience’s devices and connections.
How big of a ranking factor is this, really?
When Google rolled out the page experience update, the company was explicit that it acts more like a tie-breaker: among pages with comparable relevance and content quality, the faster, more stable one gets a small edge. Google later clarified that it’s “more than a tie-breaker” in some cases, but the core message hasn’t changed — content relevance, search intent match, and the quality and structure of what’s actually on the page carry far more ranking weight than millisecond-level speed differences.
In practice, we’ve never seen a page in serious contention with strong content and backlinks get outranked purely on Core Web Vitals scores. We have seen genuinely thin or poorly structured pages fail to rank even with a perfect 100 PageSpeed score. If you’re choosing between spending a week on technical speed optimization or a week improving thin content, the content work almost always pays back faster in ranking terms.
So why does everyone obsess over page speed?
Because the ranking argument was never the strongest reason to care about it. The real payoff is downstream of the click, in three places:
1. Conversion rate
This is where speed earns its keep. Slow-loading pages lose visitors before the content even renders, and every extra second of load time compounds bounce rate. We’ve covered this from the CRO side in our piece on mobile conversion rate optimization — a page that scores “poor” on LCP is very often losing mobile visitors for reasons that have nothing to do with your offer or your copy. They simply never see it.
2. Layout shift and trust
A high CLS score isn’t just annoying, it actively damages trust. When a page’s “Buy now” button jumps as ads or images load in, and a visitor accidentally taps the wrong element, that’s a bad first impression that has nothing to do with your product. We’ve written about the mechanics of first impressions in our 5-second test for landing pages — layout instability is one of the fastest ways to fail that test without realizing it.
3. AI crawler completeness — the reason this matters more in 2026 than it used to
Here’s the angle that’s newer and genuinely underappreciated: AI systems building answers for ChatGPT, Perplexity, or Google’s AI Overviews fetch and process pages on a budget, both in time and compute. A page that takes eight seconds to fully render its content, or that loads key information via a slow client-side script after the initial page load, risks being partially read or skipped entirely by a crawler that doesn’t wait around. This isn’t the same mechanism as classic Google ranking — it’s closer to a completeness and accessibility problem. If your key facts, pricing, or FAQ content only appear after heavy JavaScript execution, you’re making it harder for both traditional crawlers and AI answer engines to fully “see” your page. We go into this in more depth in our GEO audit checklist — fast, clean, mostly-server-rendered pages simply get read more completely.
What actually moves the needle (ranked by typical impact)
If you’re going to spend time on this, spend it in this order:
- Compress and correctly size images. This is still the single biggest LCP win for most small business sites — a hero image saved at 4x the display resolution is the most common cause of a slow load we see in audits.
- Reduce third-party scripts. Chat widgets, marketing pixels, and embedded videos each add their own loading and execution cost. Audit what’s actually still needed.
- Reserve space for images and ads before they load. This single fix eliminates most CLS problems — set explicit width and height attributes so the browser knows how much space to leave.
- Move to a proper caching and CDN setup. For WordPress sites specifically, a caching plugin plus a CDN handles a large share of server response time issues without touching code.
- Defer non-critical JavaScript. Anything that isn’t needed for the visible, above-the-fold content shouldn’t block the initial render.
Notice that “buy a faster server” isn’t at the top of the list. For the vast majority of small business sites we audit, the bottleneck is unoptimized media and unnecessary scripts, not raw hosting power.
How do you check your own scores?
Two free tools cover almost everyone’s needs. Google’s PageSpeed Insights (which pulls from the same CrUX field data Google uses for ranking) gives you both a lab test and, for sites with enough traffic, real-world field data broken down by metric. Search Console’s Core Web Vitals report shows the same field data across your whole site, grouped by URL pattern, which is more useful for spotting a template-wide problem — like every product page sharing the same oversized banner image — rather than chasing one page at a time.
A simple test to know if speed is actually costing you something
Skip the ranking debate entirely and look at your own analytics: compare bounce rate and conversion rate for visitors on “good” Core Web Vitals pages against visitors on “poor” ones, if you have both. If the gap is small, your speed problem is mostly theoretical. If poor-scoring pages show meaningfully higher bounce and lower conversion, you’ve found a real, measurable reason to fix it — one that has nothing to do with whether Google notices.
The bottom line
Site speed is real, it’s measurable, and it’s worth fixing — just not primarily for the ranking boost most people are chasing. Treat it as a conversion and accessibility project first, and a minor ranking edge second. If you’re deciding where to spend your next week of website work, a genuinely useful piece of content will usually outperform a faster LCP score. Do both eventually, but don’t mistake one for a substitute for the other.