Español
English
Yes, site speed affects SEO — but the real impact isn't where most people look. The biggest cost of a slow site is not ranking, it's lost conversions. And the metric Google actually uses for ranking is not the lab score PageSpeed Insights shows you; it's the real experience of your users over the last 28 days. This article translates the technical layer into the only question that matters for a business owner: is investing in speed worth it, and what do I fix first?
Does site speed affect SEO (and sales)?
Short answer: it affects both, but with very different weight. Impact on sales is large and measurable — every tenth of a second moves conversion rate. Impact on SEO is more of a tiebreaker signal: when relevant, high-quality pages compete for the same query, the one with better page experience has an edge; but when another page beats you on content, speed alone will not get you ranked.
Google says this in its own page experience documentation: "Google Search always seeks to show the most relevant content, even if the page experience is sub-par. Having a great page experience can contribute to success in Search" and "trying to get a perfect score just for SEO reasons may not be the best use of your time" (Google Search Central). Translated to the business layer: optimize speed because it makes you sell more and because it leaves you better positioned in a competitive SERP — not to "beat" anyone who outranks you on relevance.
Core Web Vitals explained plainly
Core Web Vitals are the three metrics Google uses to decide if a page's loading experience is good. They are the only three in the "Web Vitals" family currently used by ranking systems (web.dev).
| Metric | What it measures | "Good" threshold | "Poor" threshold |
|---|---|---|---|
| LCP (Largest Contentful Paint) | How long before the main visible element (hero image, headline) renders | ≤ 2.5 s | > 4 s |
| INP (Interaction to Next Paint) | How long the page takes to respond when the user taps or clicks | ≤ 200 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | How much content jumps around while loading | ≤ 0.1 | > 0.25 |
Source: Defining the Core Web Vitals metrics thresholds (web.dev, 2025).
Two things that matter and almost nobody explains. First: the 75th-percentile rule. Google doesn't average your loads — it looks at the value at which 75% of page views meet the threshold. If your LCP is "good" for 70% of users and "poor" for 30%, you classify as "poor". Second: as of March 2024, INP replaced FID as a Core Web Vital, and FID was retired in September 2024 (web.dev — INP launch). If anyone still reports your speed in terms of FID, the report is out of date.
The catch: field data (CrUX) vs lab data
This is the detail that saves you money and bad decisions.
When you open PageSpeed Insights, you see two blocks: one is "lab data" (a one-off simulation Lighthouse runs on a fixed device and network) and the other is "field data" (Chrome User Experience Report, aggregated from real Chrome users on your site over the past 28 days). The field data is what feeds Google's ranking signal — not the lab score. Lab data is for debugging, not for grading your site (PageSpeed Insights — field vs lab, CrUX methodology).
To show this with fresh public data, I ran the measurement on four high-traffic Argentine sites on October 16, 2026 — the pattern is universal, not local:
| Site (mobile home) | Lab: score · LCP | Real users (CrUX, 28 days) |
|---|---|---|
| lanacion.com.ar | 37 · 6.6 s | LCP 1.37 s · INP 236 ms · CLS 0.01 |
| tiendanube.com | 44 · 7.0 s | LCP 1.35 s · INP 488 ms · CLS 0.03 |
| mercadolibre.com.ar | 69 · 6.0 s | LCP 2.37 s · INP 180 ms · CLS 0.04 |
| despegar.com.ar | n/a | LCP 3.60 s · INP 543 ms · CLS 0.18 |
La Nación "fails" in the lab (37/100), but its real users see the main content in 1.37 seconds. Tiendanube too: lab score 44, real-user LCP 1.35 s. Chasing a lab score is chasing the wrong number. If an agency hands you a screenshot of a low lab score and sells you "urgent optimization", ask them to show you the Core Web Vitals report inside Google Search Console instead — that's the one built from real user data.
What does a slow site actually cost?
This is where speed stops being a technical metric and becomes a P&L line. The hard numbers, in order of relevance for decision-making:
- Every 0.1 second of mobile-speed improvement moves sales. Deloitte, commissioned by Google, measured 37 retail, travel, luxury and lead-gen sites (30 days, 30.5M sessions). A 0.1 s speed-up produced: in retail, +8.4% conversions and +9.2% order value; in travel, +10.1% and +1.9%; in luxury, +40.1% in detail-page views; in lead gen, +21.6% in form submissions (Deloitte — Milliseconds Make Millions; corroborated on web.dev).
- Conversion rate peaks between 1 and 2 seconds. Portent analyzed ~100M page views across 20 sites: a B2C ecommerce site loading in 1 second converts 2.5× more than one loading in 5 seconds. Average ecommerce conversion rate drops ~0.3 percentage points per additional second. In B2B the curve is steeper: 1 s converts 3× more than 5 s and 5× more than 10 s (Portent — Site Speed is Hurting Everyone's Revenue).
- Mobile bounce probability scales fast. Google/SOASTA, 11M mobile sessions: going from 1 to 10 seconds of load time pushes bounce probability up 123% (Think with Google).
- Improving Core Web Vitals moves revenue. Vodafone ran a controlled A/B test: a 31% LCP improvement produced +8% in total sales, +15% in visit-to-lead, and +11% in visit-to-cart (web.dev — Vodafone). Cdiscount reported +6% revenue on Black Friday after improving all 3 CWV; AliExpress reduced bounce by 15% (web.dev — CWV business impact).
The business-owner takeaway: you're not paying for "speed", you're paying for conversions you're already generating but losing. If your traffic lands on a page with an LCP of 4 seconds, every tenth you shave off is money collected on the same sessions and the same ad spend.
Is speed a ranking factor? What Google really says
What Google's official page-experience documentation says: Core Web Vitals "are used by our ranking systems", but "there is no single signal" — relevance leads, and page experience is one leg within the broader core algorithm. HTTPS, no intrusive interstitials, and mobile-friendly display are baseline requirements, not "boosts" (page experience in Search, Core Web Vitals in Search).
What this means in practice: when the SERP is tight — several similar-quality pages competing for the same query — the one with better experience wins the edge. And the signal is at the page level, not the domain level: each URL is evaluated on its own.
What it doesn't mean: there's no magic threshold that "unlocks" rankings. Going from a lab score of 70 to 90 without touching content, authority or intent will not move positions on its own. For the broader order of magnitude of SEO investment, see our take on how much SEO costs: speed is a line item in the budget, not the strategy.
What to measure and with what tool
Three tools, three uses:
- Core Web Vitals report in Google Search Console. This is Google's own view, built on field data. It groups your URLs into "good / needs improvement / poor" and tells you which metric is failing. If you only open one, open this one.
- PageSpeed Insights (
pagespeed.web.dev). Look at the top block first ("Discover what your real users are experiencing" / CrUX). The lab panel and "opportunities" are for your tech team, not for grading the site. - Analytics. Correlate the Search Console report with your per-page or per-segment conversion rate. If a URL improves on LCP and conversion goes up on the same traffic, the investment pays itself.
Things you can safely ignore as a business owner: GTmetrix, Pingdom, "internet speed" scores. They measure something else.
What to fix first: a prioritization framework
If your Search Console report flags URLs as "needs improvement" or "poor", the order we use in agency audits is almost always this:
- URLs that already generate revenue first. Product pages, category pages, landings with measurable conversion — before "improve the home page".
- LCP first, INP second, CLS as hygiene. LCP is the one that moves conversion and bounce the most. INP is usually third-party scripts (chat widgets, tags). CLS is cleanup: declare image
width/height, stop fonts from flashing. - Images and hero before CSS/JS. In 70% of the slow-ecommerce audits we see, the problem is the hero image: no WebP/AVIF, no declared dimensions, no preload. Highest effort-to-impact ratio by a wide margin.
- Hosting is a last resort, not a first. Migrating hosting is expensive and slow. Optimize what you have first: whenever an agency sells you "server migration" as step one of a WPO plan, demand the before-and-after measurement.
If you want the detail on how we handle this at Seotronix, it lives in our WPO (web performance optimization) service. The point isn't to chase a score — it's to move the needle on sales.
And if what you really want is for AI engines (ChatGPT, Perplexity, AI Overviews) to feature you, speed alone won't get you there — that's a different problem. For that, see our note on how to write content AI will quote verbatim.
FAQ
How do I check my website's speed?
Use PageSpeed Insights (pagespeed.web.dev) for a quick look, and — more importantly — the Core Web Vitals report in Google Search Console, which shows the real Chrome user data aggregated over the past 28 days. For a business owner, Search Console is enough.
What is a good site-speed score?
Not a lab score — a field threshold. You want 75% of your mobile loads at LCP ≤ 2.5 s, INP ≤ 200 ms, and CLS ≤ 0.1. Hit those and you pass the "good" bar for Core Web Vitals. These are the official thresholds published on web.dev (updated 2025).
Does page speed still affect SEO rankings?
It's a signal, not a primary factor. Core Web Vitals are used by ranking systems — in Google's own words — but relevance comes first. In a tight SERP of similar-quality pages, better experience helps. Chasing a lab score of 100 just for SEO is rarely the best use of your time.
Why is my website so slow?
In 7 out of 10 ecommerce audits we run, the main cause is the hero image (the large one at the top): no modern format (WebP/AVIF), no declared dimensions, no preload. Then come third-party scripts (chat, pixels), and far behind, hosting.
How do I get my website to load faster?
Fix the biggest leaks first. For most ecommerce sites that means: compress and modernize images (especially the hero), add width/height to all above-the-fold images, defer or remove third-party scripts you don't actively need, enable browser caching and HTTP/2 if your host supports it. Replace the host last, not first.
