Page Speed and SEO: How Site Speed Affects Your Rankings

Page speed affects SEO through Google's Page Experience system, which uses Core Web Vitals (LCP, INP, CLS) as a ranking signal. The bar to clear on mobile: LCP under 2.5s, INP under 200ms, CLS under 0.1, measured at the 75th percentile of real Chrome users over 28 days. Speed is a tiebreaker, not a magic boost: it will not outrank a stronger result with worse content, but it will pull you ahead of similar pages and stop you from being held back. Faster pages also win indirectly through better engagement, lower bounce, deeper crawl, and higher conversion rates that feed back into rankings over time. To improve fast: fix the LCP image, defer or remove heavy third party scripts, ship less JavaScript on mobile, and reserve space for anything that loads in. Then monitor CrUX field data rather than Lighthouse scores alone.

Yes. Page speed has been a confirmed Google ranking factor on desktop since 2010 and on mobile since 2018, and since 2021 it has been formalized inside the Page Experience system through Core Web Vitals. In 2026 the question is no longer whether speed matters for SEO, it is how much weight it carries and where it shows up.

The honest answer: speed is a relatively small ranking factor compared to relevance, content quality, and links, but it is real and it is measurable. Google describes it as a tiebreaker that helps decide between pages of similar quality. In low competition niches you may rank fine while being slow. In competitive verticals (ecommerce, SaaS, finance, travel) speed is often the difference between page one and page two, because every page that ranks already has strong content and a credible link profile.

For the deeper version of this answer, including the documented Google statements and the studies that quantify the effect, read Is Site Speed a Ranking Factor?.

Google does not measure page speed the way most marketers think. It does not run Lighthouse against your site and use that score as a ranking input. Instead it uses field data from the Chrome User Experience Report (CrUX), which aggregates real performance metrics from opted in Chrome users who actually visit your pages.

What Google evaluates per URL (and per origin when there is not enough URL level data):

1. Largest Contentful Paint (LCP): How long it takes the largest visible element (usually a hero image, headline, or video poster) to render. Threshold: under 2.5 seconds.
2. Interaction to Next Paint (INP): How responsive the page feels to clicks, taps, and keypresses across the whole visit, including the slowest one. Threshold: under 200 milliseconds.
3. Cumulative Layout Shift (CLS): How much the layout jumps around as content loads. Threshold: under 0.1.

These are evaluated at the 75th percentile of visits over a rolling 28 day window, separately for mobile and desktop. To pass, three out of four visits to your URL must hit each threshold. A URL is considered to pass Core Web Vitals only if all three metrics pass.

This is why your Lighthouse score of 95 can coexist with a failing Core Web Vitals status in Search Console. Lighthouse runs once, on a controlled emulated device, on a fast connection. Real users open your site on three year old Android phones over flaky 4G, with ad blockers off and background tabs eating CPU. Google ranks based on what those users experience, not what your lab test reports.

For the full breakdown of how each Core Web Vital is measured and what attribution Google provides, see the complete Core Web Vitals guide.

Core Web Vitals are the speed inputs to Google's ranking system. They affect SEO in three ways:

1. Direct ranking signal: Passing CWV is part of the Page Experience system, which Google uses as a ranking input. The effect is small per URL but consistent across a site.
2. Mobile first impact: Google ranks the mobile version of your pages. Mobile CWV scores are what count, and mobile is where most sites fail (especially INP).
3. Compound indirect signals: Faster pages keep users on the site longer, which produces better engagement signals (lower bounce, more pages per session, higher conversion). Those signals feed back into how Google evaluates content quality and intent match.

The direct ranking lift from passing CWV is modest, usually a few positions in close calls. The indirect lift from better engagement is often larger, because a 3 second LCP page loses around 40% of mobile users before they even see content. Those abandoned visits show up as pogo sticking in Google's logs, which is one of the strongest negative quality signals a page can produce.

For the full breakdown of the studies, the documented Google statements, and the verticals where CWV moves rankings most, read Does Core Web Vitals Affect SEO?.

The short answer: under 2.5 seconds LCP on mobile, with INP under 200ms and CLS under 0.1, at the 75th percentile of your real users.

The longer answer depends on what you are optimizing for:

• To pass Core Web Vitals and qualify for the Page Experience boost: hit the thresholds above for at least 75% of mobile visits.
• To stop losing users to abandonment: mobile LCP under 2.5s is the bar. Bounce rates climb sharply between 1 and 3 seconds and become severe past 4 seconds.
• To beat fast competitors in close ranking battles: aim for LCP under 1.8s and TTFB under 0.5s. The faster you are than the field, the more often you win the tiebreaker.
• To support high crawl budgets on large sites: server response under 600ms keeps Googlebot crawling at high frequency. Slow servers throttle crawl, which slows indexation of new and updated pages.

There is no SEO benefit to loading in 0.5s instead of 1.5s in most verticals. Once you are clearly inside the Good band, further speed improvements help conversion and user experience more than they help rankings. For the full breakdown by industry and context, see How Fast Should a Website Load?.

Even if Core Web Vitals were not a ranking factor, page speed would still affect SEO through engagement. Every published study on the topic shows the same shape:

• A 1 second delay in mobile load time reduces conversions by around 20% on average.
• 53% of mobile visitors abandon a page that takes longer than 3 seconds to load.
• Pages with LCP under 2.5s have meaningfully lower bounce rates and higher pages per session than pages over 4 seconds.

Our 2026 study of 37,000 ranking pages shows the ranking-side of the same relationship: page-one Google results pass Core Web Vitals more often than page-two results, and among competitive, high-traffic sites the gap widens to 7.6 points. Google does not directly use Google Analytics data in its ranking algorithm, but it does observe pogo sticking behavior in its own logs: a user clicks your result, bounces back to the SERP within a few seconds, and clicks the next result. That pattern, repeated across thousands of users, tells Google your page failed to satisfy the query. Slow pages produce this pattern at much higher rates than fast pages, and the search behavior signal is one of the inputs Google uses to evaluate result quality.

The practical takeaway: even small speed improvements pay back twice. Once through the direct CWV signal, and again through the better engagement that fast pages produce. For an ecommerce focused view of how speed and revenue connect, see the ecommerce conversion speed guide.

Google has been mobile first indexing for years. The mobile version of your site is what gets crawled, indexed, and ranked, which means mobile speed is what your SEO depends on.

Most sites have a mobile speed problem they do not realize. Their desktop Lighthouse score is 90+, their mobile field data is failing, and they assume the report is wrong. It is not. Mobile devices have weaker CPUs, slower network conditions, and smaller batteries, so JavaScript heavy pages that look fine on a MacBook collapse on a mid range Android.

The most common mobile specific issues:

• Heavy main thread work: too much JavaScript blocks user interactions, pushing INP into the Poor band.
• Unoptimized hero images: the LCP element on mobile is often a giant desktop image scaled down, costing 2 to 4 seconds.
• Layout shifts from late loading ads and embeds: CLS scores on mobile are often 2 to 5x worse than desktop.
• Slow TTFB on mobile networks: the same server response that takes 200ms over fiber takes 1 second over 4G.

For real world mobile behavior data and how it interacts with rankings, see the mobile website speed guide.

If your Search Console Core Web Vitals report shows failing URLs, work in this order:

1. Open the CWV report in Search Console and identify which metric (LCP, INP, CLS) is failing on which URL groups. Most sites have one dominant problem, not three equal problems.
2. Fix the LCP image on your top templates. Preload it with `fetchpriority="high"`, serve WebP or AVIF, set explicit width and height, and stop using hero images that weigh more than 200 KB.
3. Cut JavaScript on mobile. Audit third party scripts (analytics, chat, ads, A/B testing). Remove what you do not need, defer what you do, and consider facades for heavy embeds like YouTube and Intercom.
4. Reserve space for everything that loads in: ads, embeds, images, web fonts. CLS is usually the easiest of the three CWV to fix because the causes are mechanical.
5. Measure TTFB. If your server takes more than 800ms to respond, no amount of frontend optimization will save you. Look at hosting, caching, and database queries first.
6. Re measure with CrUX, not Lighthouse. Field data updates on a 28 day rolling window, so expect 4 to 8 weeks before improvements fully reflect in Search Console.

If you do not have the in house bandwidth to work through this list, our Core Web Vitals optimization service handles the diagnosis and the fixes end to end.

Speed monitoring for SEO is different from speed monitoring for engineering. The two questions you need answered are:

1. Are my URLs passing Core Web Vitals according to Google?
2. Are my speed metrics getting better or worse over time?

The minimum monitoring stack:

• Search Console Core Web Vitals report: the source of truth for what Google sees. Check weekly. It groups URLs by template and shows pass/fail trends.
• PageSpeed Insights: for any individual URL, shows both the CrUX field data and a Lighthouse lab run. Use field data for SEO decisions, lab data for diagnosis.
• CrUX Dashboard or BigQuery: for tracking month over month trends at the origin level, especially useful for large sites.
• A RUM tool (free options exist): for catching regressions before they show up in Search Console's 28 day window.

Do not rely on Lighthouse scores or PSI lab runs as your monitoring system. They tell you what one synthetic test on one device measured at one moment. They do not tell you what Google is using to rank your pages. For a deeper look at the trade offs between lab and field tools, see Website Speed Test Tools: How to Measure Performance the Right Way.

A lot of bad advice about page speed and SEO is still circulating in 2026. The most common myths:

• "A perfect Lighthouse score guarantees better rankings." False. Lighthouse is a lab tool. Google ranks on field data. A 100 Lighthouse score with poor real user metrics will not help your rankings.
• "Speed is only a tiebreaker so it does not really matter." False. Tiebreakers decide outcomes constantly in competitive search results. Most ranking positions are close calls between similar pages.
• "You need to be faster than every competitor." False. You need to pass the CWV thresholds. Being twice as fast as a passing competitor does not give you twice the boost.
• "Desktop speed is what counts." False. Google indexes and ranks the mobile version of your site. Desktop CWV are reported but mobile is what moves rankings.
• "Speed only matters for ecommerce." False. Engagement signals and Page Experience apply to every content type. Blog posts, landing pages, and product pages all benefit.
• "Caching plugin = fixed." False. A caching plugin can help with TTFB but it will not fix LCP image weight, JavaScript bloat, or layout shift. The wins always come from the specific cause of the failing metric.

For the detailed breakdown of where the speed and rankings link is real and where it is overstated, see Does Page Speed Affect SEO?.

This guide is the hub for page speed and SEO. To go deeper on any of the specific questions:

• Does Page Speed Affect SEO?: the documented evidence, the studies, and an honest read on how much speed actually moves rankings.
• Is Site Speed a Ranking Factor?: what Google has said on the record, where speed sits in the ranking pipeline, and how to think about its weight.
• Does Core Web Vitals Affect SEO?: the CWV specific ranking impact, what passing actually gets you, and what happens when you fail.
• How Fast Should a Website Load?: target load times by industry, by device, and by intent, with the data behind each benchmark.

For the broader Page Experience picture (mobile usability, HTTPS, interstitials), see the Google Page Experience guide. For the technical playbook on each Core Web Vital, the complete Core Web Vitals guide and the Core Web Vitals glossary entry are the right next stops.

Metric	Good	Needs Improvement	Poor
LCP (Largest Contentful Paint)	under 2.5s	2.5 to 4.0s	over 4.0s
INP (Interaction to Next Paint)	under 200ms	200 to 500ms	over 500ms
CLS (Cumulative Layout Shift)	under 0.1	0.1 to 0.25	over 0.25
TTFB (Time to First Byte)	under 0.8s	0.8 to 1.8s	over 1.8s
Mobile Lighthouse Performance	90 to 100	50 to 89	0 to 49
CrUX 75th percentile pass rate	all 3 CWV pass	1 to 2 pass	0 pass