Website Speed: Why It Decides Your Rankings (and Revenue)
Website speed affects rankings and revenue through Core Web Vitals — Google's three field metrics: LCP (loading, keep under 2.5s), INP (responsiveness, under 200ms), and CLS (visual stability, under 0.1). Slow sites rank lower and lose roughly half of mobile visitors before the page even renders.
- Google's LCP threshold
- 2.5 seconds
- Mobile visitors who abandon 3s+ loads
- 53% (Google research)
- Typical template site
- 4–7 seconds
- Well-built hand-coded site
- under 1 second
The three numbers Google actually measures #
LCP (Largest Contentful Paint) — how fast the main content appears. INP (Interaction to Next Paint) — how fast the page responds when tapped. CLS (Cumulative Layout Shift) — whether things jump around while loading. Google collects these from real Chrome users, not lab tests — so only real-world speed counts.
Why most local business sites are slow #
The usual culprits stack: a $60 theme carrying 2MB of unused code, a page builder rendering nested div soup, 15 plugins each injecting scripts, unoptimized 4MB photos, and cheap shared hosting. Each alone is survivable; together they produce the 4–7 second loads we see in most scans.
The order to fix things (biggest wins first) #
1) Images — convert to WebP/AVIF and size them properly (often 60% of the win). 2) Kill unused scripts and plugins. 3) Caching and a CDN. 4) If you're on a heavy theme or builder, the honest answer is a rebuild: you can't tune your way out of structural bloat — it's why our rebuilds routinely take sites from 6 seconds to under one.
// before: 4.2MB hero photo, invisible to Google until loaded
<img src="hero.jpg">
// after: WebP, sized, prioritized — sub-second LCP
<img src="hero.webp" width="1200" height="630"
fetchpriority="high" alt="Plumber in Mesa fixing a water heater">Speed is a revenue metric, not a vanity metric #
Large-scale studies put it around 1% revenue per 100ms. For a local business the effect is blunter: a visitor comparing three plumbers doesn't wait for the slow one. The fast site gets the call — that's the whole game.
The three Core Web Vitals, translated #
LCP (Largest Contentful Paint) is how long the main content takes to appear — under 2.5 seconds is good. INP (Interaction to Next Paint) is how fast the page responds when tapped — under 200ms. CLS (Cumulative Layout Shift) is how much the page jumps around while loading — under 0.1. Google measures these on real visitors (field data), not just lab tests, and folds them into rankings as page-experience signals. Fix them in that order: LCP is usually images and server speed, INP is usually JavaScript bloat, CLS is usually images without dimensions and injected banners.
Images: where most of the seconds hide #
The average page's weight is mostly images, and the fixes are mechanical: serve modern formats (WebP/AVIF cut 30–70% versus JPEG), size images to their display size instead of shipping 4000-pixel originals, lazy-load everything below the fold, and never lazy-load the hero (it IS your LCP). An afternoon of image discipline routinely halves load time on small-business sites.
The third-party script tax #
Every analytics pixel, chat widget, heatmap tool and 'marketing tag' someone installed over the years loads on every visit, forever. We regularly find sites carrying 15+ third-party scripts where three still serve a purpose. Audit the tag manager, delete the zombies, and load what survives after the page becomes interactive. This is frequently the single biggest INP fix available.
Hosting: the floor under everything #
No optimization outruns a slow server: TTFB (time to first byte) above ~600ms drags every metric and no cache fully hides it. Cheap shared hosting is slow because it's oversold — hundreds of sites per server. The fix costs little: a modest VPS or quality host brings TTFB under 200ms, and everything built on top of it inherits the speed.
A 30-minute speed audit you can run yourself #
Run PageSpeed Insights and read the field data first (that's real visitors). Note LCP, INP, CLS. Open the waterfall in the browser's Network tab: what loads first, what's biggest, what blocks? Usually the story is instantly visible — a 3MB hero image, a parade of third-party scripts, a slow first byte. Fix the top item, re-measure, repeat. Speed work is iterative diagnosis, not a plugin purchase.
FAQ
What's a good PageSpeed score?
90+ on mobile is good; we ship 95–100. Below 50 means you're leaving rankings and customers on the table every day.
Do I need to leave WordPress to be fast?
No — but you need to leave the heavy-theme-plus-20-plugins pattern. Lean WordPress can hit 90+; a hand-coded site makes 95+ the default instead of a project.
Does speed really affect rankings directly?
Yes — Core Web Vitals are a confirmed ranking signal. The indirect effect is bigger: slow pages get abandoned, and Google reads that behavior too.
Do speed plugins like WP Rocket actually work?
Good caching plugins genuinely help WordPress sites — caching, minification and lazy loading are real. What they can't fix: slow hosting, oversized images, plugin bloat and heavy themes. Sites stacking multiple optimization plugins usually get slower — they conflict. One good caching layer on top of fixed fundamentals is the working recipe.
How fast should my website be?
User-facing targets: main content visible under 2.5 seconds (LCP), interaction response under 200ms (INP), no layout jumping (CLS under 0.1) — Google's own 'good' thresholds. Business reality: every additional second of load measurably increases abandonment, and Google's research found 53% of mobile visits abandon at 3 seconds. Under 2 seconds should be the working goal.
Does website speed really affect Google rankings?
Yes — Core Web Vitals are confirmed page-experience ranking signals, slow pages get crawled less thoroughly, and the indirect effect is bigger: slow pages bounce visitors, and engagement patterns feed rankings. Speed is rarely why a site ranks #1, but it's routinely why a site can't crack page one despite good content.
Was this helpful?