Does slow hosting hurt your Google rankings? Core Web Vitals, TTFB and what to fix first

Two myths compete here. One says page speed is a huge ranking factor and a faster host will lift you to page one. The other says Core Web Vitals don't matter at all. The truth is in between. Google confirms page experience signals, including Core Web Vitals, are used in ranking. But relevance and content quality dominate, and speed acts more like a tie-breaker between similar pages. Speed matters much more for conversion and for Google Ads costs, where landing-page experience feeds into Quality Score.

The three metrics and their thresholds

INP replaced First Input Delay as a Core Web Vital in March 2024. Google evaluates all three on field data (real Chrome users, the Chrome UX Report) at the 75th percentile, over a rolling 28 days. A perfect Lighthouse score on your laptop doesn't count. What your visitors experience on their phones does.

Where hosting fits in

Hosting mostly affects Time to First Byte (TTFB): how long the server takes to start sending HTML. Every millisecond of TTFB delays LCP, because the browser can't render anything before the HTML arrives. Hosting has little effect on INP and CLS. Those come from your theme, scripts and layout.

That gives a quick diagnosis:

• High TTFB + poor LCP: hosting, caching or database. A better host or proper caching helps.
• Fine TTFB + poor LCP: images, fonts or render-blocking resources. A new host won't fix it.
• Poor INP or CLS: front-end code. Hosting is irrelevant.

Measure it properly

1. PageSpeed Insights: the top section ("Discover what your real users are experiencing") is field data and is what counts. The lower Lighthouse section is a lab simulation, useful for debugging.
2. Search Console → Core Web Vitals: groups of URLs failing each metric, on mobile and desktop.
3. TTFB from the command line, run a few times and from servers in the regions your customers are in:

curl -o /dev/null -s -w "dns %{time_namelookup}s | connect %{time_connect}s | tls %{time_appconnect}s | ttfb %{time_starttransfer}s | total %{time_total}s\n" https://yourstore.com/

As a working target, aim for TTFB well under ~0.8 seconds for real users. For cached pages served from a CDN, it should be a small fraction of that.

Fixes, in order of impact

1. Full-page caching (biggest win for WordPress/WooCommerce)

Without caching, every visit runs PHP and database queries to build the same page. With page caching (server-level, a caching plugin, or a CDN that caches HTML), most visitors get a pre-built page in milliseconds. Exclude cart, checkout and account pages from the cache.

2. A CDN close to your visitors

Serve static files, and ideally cached HTML, from edge locations. A store in Europe hosted in the US loses 100+ ms per round trip before any optimization.

3. Server-side basics

• A current PHP version, an object cache (Redis) for WooCommerce, and enough RAM that the database isn't swapping.
• Move off oversold shared hosting if TTFB is consistently slow even with caching. That's when managed cloud hosting or a VPS earns its price.

4. The LCP element

• Serve the hero image in a modern format (WebP/AVIF), sized for the viewport.
• Don't lazy-load the LCP image. Give it fetchpriority="high".
• Avoid hero sliders, which delay LCP and rarely help conversion.

5. JavaScript diet (for INP)

• Audit apps and plugins. Each chat widget, review app, pop-up and tracker adds script that competes for the main thread.
• Delay non-essential third-party scripts until after interaction or load.

6. Layout stability (for CLS)

• Always set width and height (or aspect-ratio) on images and embeds.
• Reserve space for banners and cookie notices instead of pushing content down.
• Use font-display: swap with metric-compatible fallbacks, and preload only the one or two critical fonts.

Choosing a host

Hosts don't differ much on raw speed once caching is set up correctly. What differs is how much of that work they do for you. Managed WordPress and cloud hosts (Kinsta, Cloudways, ScalaHosting and others) include server-level caching, a CDN and staging, which saves setup time. A plain VPS is cheaper but leaves the tuning to you. Compare them in ScalaHosting vs Cloudways vs Kinsta, and measure TTFB on a trial before you migrate.