Does a Slow Website Hurt SEO? How Speed Affects Rankings and Sales

Yes, a slow website hurts SEO, but mostly through lost visitors and sales rather than lost rankings. Google uses Core Web Vitals as a ranking signal, yet relevance outweighs speed, so a fast page with weak content still loses to a slower page that answers the query better. The larger cost of slow load times is conversions: in Google's 2020 study, a 0.1-second mobile speed gain raised retail conversion rates by 8.4%.

How much does page speed affect Google rankings?

Page speed is a confirmed but secondary ranking signal. Google's documentation states that "Core Web Vitals are used by our ranking systems", and in the same FAQ that "Google Search always seeks to show the most relevant content, even if the page experience is sub-par" (Google Search Central, Understanding page experience, updated 2026).

In practice this means speed works as a tiebreaker between pages of similar relevance and quality. It matters most in competitive results where 5 or 10 pages answer the query equally well. Fixing performance alone does not move a page from page 3 to page 1, and a page with poor Core Web Vitals still ranks first when it is clearly the best answer.

Speed also affects SEO indirectly. A slow server reduces how many pages Googlebot crawls on large sites, and visitors who leave before the page loads never link to it, share it or convert.

What are Core Web Vitals?

Core Web Vitals are the three metrics Google uses to measure page experience: loading, responsiveness and visual stability. Google assesses each one at the 75th percentile of real page loads, separately for mobile and desktop, and a page passes only when all three meet the "good" threshold (web.dev, Web Vitals, updated 2024). The hands-on fixes for each metric are in how to pass Core Web Vitals.

Largest Contentful Paint (LCP)

LCP measures how long the largest visible element, usually a hero image or headline, takes to render. A good LCP is 2.5 seconds or less.

Interaction to Next Paint (INP)

INP measures how quickly the page responds visually after a click, tap or key press. A good INP is 200 milliseconds or less. INP replaced First Input Delay as a Core Web Vital on 12 March 2024 (web.dev, 2024), so older guides that mention FID are out of date.

Cumulative Layout Shift (CLS)

CLS measures how much content jumps around while the page loads, such as a button that moves when an advert appears above it. A good CLS score is 0.1 or less.

What does a slow website cost in sales?

A slow website costs more in lost conversions than in lost rankings. The "Milliseconds Make Millions" study, commissioned by Google and carried out by 55 and Deloitte, tracked 37 European and American brand sites across more than 30 million user sessions at the end of 2019 (web.dev, Milliseconds make millions, 2020). A 0.1-second improvement in mobile site speed produced these results:

• Retail conversion rates rose 8.4% and retail shoppers spent 9.2% more.
• Travel conversion rates rose 10.1%.
• Lead generation sites saw 21.6% more visitors progress to the form submission page.

For a lead generation business, that last figure matters most. A service page that loads slowly on mobile loses enquiries every day, and no ranking report shows it. Watch for this pattern in GA4: mobile conversion rates well below desktop on the same pages usually point to a performance problem, not a content problem.

How to measure your website's speed

Measure speed with field data from real visitors first, then use lab data to find the cause. The two types answer different questions.

• Field data comes from the Chrome User Experience Report (CrUX), covers real Chrome users over a trailing 28-day period and is the data Google uses for the Core Web Vitals assessment (Google for Developers, About PageSpeed Insights).
• Lab data comes from Lighthouse running a simulated page load in a controlled environment. It is useful for debugging but does not decide whether you pass.

Use these 3 tools in this order:

1. Search Console > Core Web Vitals. This report groups URLs with a similar experience and marks each group Good, Needs improvement or Poor, using CrUX data (Google Search Console Help). Start here to see which templates fail.
2. PageSpeed Insights. Test one URL from each failing group. Read the field data at the top for the verdict and the diagnostics below for the causes.
3. Chrome DevTools > Performance and Network. Record a page load to see exactly which file, script or server response delays the page.

Small sites often show "no data" in the field section because CrUX needs enough Chrome traffic per URL. Rely on lab data and the origin-level summary in that case.

Why is my website slow? 7 common causes and fixes

Most slow websites suffer from a combination of the same 7 causes. Each one below names the symptom in PageSpeed Insights and the fix.

1. Unoptimised images

Large images are the most common cause of a slow LCP. Compress images, serve them as WebP or AVIF, size them to the space they fill and add width and height attributes to prevent layout shift. Lazy-load images below the fold, but never lazy-load the hero image.

2. Render-blocking JavaScript and CSS

Scripts and stylesheets in the page head stop the browser drawing anything until they download. Defer non-critical JavaScript, inline the small amount of CSS needed for the first screen and remove unused CSS and JavaScript that themes and plugins load on every page.

3. Too many plugins and third-party scripts

Every chat widget, heatmap tool, ad pixel and social embed adds network requests and main-thread work, which hurts INP. List every third-party script in DevTools > Network, remove the ones nobody uses and load the rest after the page becomes interactive.

4. Slow hosting and high TTFB

Time to First Byte is how long the server takes to start responding, and web.dev treats 0.8 seconds or less as good (web.dev, Time to First Byte). A TTFB above that delays every other metric. Move to better hosting, upgrade the PHP or Node version and fix slow database queries.

5. No caching or CDN

Without page caching, the server rebuilds every page for every visitor. Enable server-side or full-page caching and serve static files through a CDN so visitors download them from a location near them.

6. Heavy page builders

Visual page builders generate deeply nested HTML and load their own scripts and styles on every page. Replace the builder on the highest-traffic templates, such as the homepage and service pages, with lighter blocks or custom code.

7. Web fonts

Each font family and weight is a separate download that delays text. Limit fonts to 2 families and the weights you use, self-host them, preload the main file and use font-display: swap so text appears immediately.

When speed fixes need a developer rather than a plugin

Speed fixes need a developer when the cause sits in the code, the server or a security problem rather than in settings. A caching or optimisation plugin fixes causes 1, 2 and 5 on many WordPress sites. It does not fix these:

• Slow database queries, a bloated theme or a page builder that defines the whole site structure.
• Hosting or server configuration limits, such as old PHP versions or no object caching.
• Conflicts where an optimisation plugin breaks forms, checkout, tracking tags or structured data.
• Security problems that look like speed problems.

That last item is the one generic speed guides miss. My security background since 2011 is why I check this first: injected malware scripts, hidden spam pages and aggressive bot traffic all load the server and slow the site, and no speed plugin removes them. A site that becomes slow suddenly, with no recent changes, needs a security check before a performance tune-up. The steps for that are in what to do when your website is hacked.

A slowdown that coincides with a fall in organic traffic needs both checks, covered in why your website traffic dropped. For a structured review of speed alongside indexing, security and tracking, work through the website audit checklist.

Frequently asked questions

Is page speed a Google ranking factor?

Yes, page speed is a Google ranking factor through Core Web Vitals, which Google confirms its ranking systems use. It is a secondary signal: Google shows the most relevant content even when its page experience is poor.

What is a good page load time for SEO?

A good load time for SEO is a Largest Contentful Paint of 2.5 seconds or less, an Interaction to Next Paint of 200 milliseconds or less and a Cumulative Layout Shift of 0.1 or less. Google measures these at the 75th percentile of real visits.

Why does PageSpeed Insights give a different score each time?

PageSpeed Insights gives a different performance score each time because the score comes from a single simulated lab test, which varies with network and server conditions. The field data at the top of the report is stable because it summarises 28 days of real Chrome visits.

Will a faster website rank higher on Google?

A faster website ranks higher only when competing pages are similarly relevant, because speed acts as a tiebreaker rather than a primary signal. The more reliable gain from a faster site is a higher conversion rate from the visitors you already have.

Can a hacked website be slow?

Yes, a hacked website is often slow because injected scripts, hidden spam pages and malicious bot traffic consume server resources. Check for malware when a site slows down suddenly without any recent changes.