Does Website Speed Affect Google Rankings?

The short answer is yes. Page speed is a confirmed Google ranking factor. The longer answer is that it's a smaller factor than most speed-tool vendors suggest, it mostly acts as a tiebreaker, and chasing a perfect PageSpeed score is not the goal.

Here's what Google has actually said, what I've seen on real sites, and what to fix first.

Is page speed a ranking factor?

Yes. Google has confirmed it three times, each time more specifically:

2010: Google announced site speed as a ranking signal for desktop search, affecting a small percentage of queries.
2018: The "Speed Update" made speed a mobile ranking factor, aimed at the slowest pages.
2021: Core Web Vitals became part of the page experience signals used in ranking, with LCP, CLS, and FID (FID was replaced by INP in March 2024).

What Google has not said is that speed outweighs relevance. Its page experience documentation is explicit that Search will still show the most relevant result even when its page experience is poor, and that good Core Web Vitals don't guarantee good rankings. Page experience helps most when several pages are similarly relevant to a query — which, in a crowded local market, is often.

So: confirmed factor, real but modest weight, biggest effect as a tiebreaker.

What Core Web Vitals actually measure

Core Web Vitals are the three metrics Google uses to score loading, responsiveness, and visual stability:

LCP — Largest Contentful Paint. How long until the largest visible element (usually the hero image or headline) finishes rendering. Under 2.5s is "good," 2.5–4s "needs improvement," over 4s "poor."

INP — Interaction to Next Paint. How quickly the page responds when someone taps or clicks. Under 200ms is "good," 200–500ms "needs improvement," over 500ms "poor."

CLS — Cumulative Layout Shift. How much the layout jumps around while loading — images popping in, fonts swapping, buttons moving. Under 0.1 is "good."

Google assesses these at the 75th percentile of real visits, on mobile and desktop separately.

What it looked like on my own site

In October 2026 I ran this site's homepage through PageSpeed Insights on mobile. It scored 88, with the first content appearing after 3.0 seconds. For a business that sells fast websites, that's not a good look.

The diagnosis was specific: the browser couldn't draw anything until it had downloaded the Google Fonts stylesheet and two CSS files. PageSpeed estimated about 1.8 seconds of savings from fixing that alone. Two changes:

Self-hosted the fonts. Downloaded the two variable font files, served them from my own domain, preloaded them, and declared them inline — no third-party stylesheet in the critical path.
Inlined the CSS. SvelteKit can put each page's CSS directly into the HTML (the inlineStyleThreshold setting), so there's no separate stylesheet request blocking the first paint.

Result on the same test: mobile Performance 100, first content at 1.0s, largest content at 1.1s. Desktop went from 85 to 97–100.

Most speed checklists list "self-host your fonts" as a medium-impact tweak. On this site it was the single biggest fix. That's the point of running the test instead of following a generic list: the slowest thing on your page is what matters.

What I can't tell you yet is whether it moved rankings. It's too early, and — more on this below — a site this size doesn't have enough Chrome traffic for Google to have real-user speed data at all.

What a client's site shows: relevance beats speed

Hair Society Salon in Houston is a useful counterexample. Its homepage scores 94 on mobile, but its largest content takes about 3.0 seconds in the lab test — slower than the 2.5s "good" threshold.

It still ranks around position 5–6 for "hair salons near me" and has earned 844 organic clicks since launch, 84% of its impressions coming from people who didn't search the salon's name. The things doing the heavy lifting are relevance and local signals: the right Google Business Profile categories, a services page that matches what people search, schema, and reviews.

That's speed as a tiebreaker in practice. A 3-second page with strong relevance outranks a 1-second page with weak relevance. Speed is worth fixing — but not before the page is the best answer to the search.

Lab data vs. field data (and why small sites often have neither problem nor signal)

PageSpeed Insights shows two kinds of data:

Lab data — a simulated load on a throttled device. Useful for diagnosing why a page is slow. It's what produces the 0–100 score.
Field data — real measurements from Chrome users, collected over 28 days in the Chrome UX Report. This is what Google's ranking systems use for Core Web Vitals.

The catch for local businesses: field data only exists once a page or site gets enough Chrome traffic. Neither this site nor Hair Society's has field data yet — PageSpeed shows "no data" for real users. Google hasn't documented exactly how it treats pages without field data, so don't expect a lab-score improvement to show up as a ranking jump on a low-traffic site.

The faster page still pays off where it always does: visitors who don't bounce while waiting for a slow page to load. That benefit doesn't depend on Google at all.

The mobile-first reality

Google uses mobile-first indexing — the mobile version of your site is the one it evaluates. Local searches are mostly mobile too. A site that scores 85 on desktop and 42 on mobile should be judged on the 42.

Run PageSpeed Insights on your site and look at the mobile tab first. Rough guide:

Below 50: speed is likely costing you visitors and is worth fixing now.
50–89: real gains available; fix whatever the report lists with the biggest estimated savings.
90+: you're in good shape. Spend your time on content, your Business Profile, and reviews instead.

What to fix first

Fix in order of the savings PageSpeed estimates for your page — but these are the usual suspects:

Usually high impact

Render-blocking CSS and fonts — third-party font stylesheets and large CSS files that must download before anything appears. Self-host fonts, preload them, and inline critical CSS.
Oversized images — resize to the size actually displayed, serve WebP or AVIF, and lazy-load anything below the fold.
Page builders — Elementor, Divi, and similar tools ship a lot of code by default. Rebuilding on a lean framework often takes a mobile score from the 40s to the 90s.
Render-blocking JavaScript — scripts that load before content. Defer or remove them.

Usually medium impact

Caching and a CDN at the hosting level.
Removing unused third-party widgets (chat bubbles, review carousels, tracking pixels).

Usually low impact

Manual minification — modern build tools already do it.
Removing analytics entirely — the cost is small and the data is worth more.

The bottom line

Website speed affects Google rankings — confirmed, measurable, and more important on mobile than desktop — but it's a tiebreaker behind relevance, local signals, and reviews. Aim for Core Web Vitals in the "good" range on mobile (LCP under 2.5s, INP under 200ms, CLS under 0.1), fix the specific bottleneck PageSpeed points to, and then put your energy back into being the best answer for the search.