How to improve website speed for SEO without wasting your weekend
A client emailed me a screenshot of their PageSpeed score last month. Mobile: 23. They'd already paid someone to "optimize" the site three months earlier, and the invoice showed forty hours of work. Forty hours, and the homepage still took six seconds to render anything visible on a phone. I ran my own test, opened the waterfall, and found the problem in under ten minutes: a single 2.4 MB hero image sitting on the server at full resolution, plus two analytics scripts loading before a single pixel of text.
That's the thing people miss about website speed optimization. It's rarely about the exotic stuff. It's almost never about the framework you chose or the hosting tier you're paying for. It's about a handful of files that somebody forgot to compress, or a plugin stack that grew like weeds while nobody was looking. If you want a faster site for SEO, you can absolutely get most of the way there for free, in a few focused sessions.
Below is the order I actually work in, because not every fix is worth the same effort. Some are worth seconds. Some are worth milliseconds and a headache.
Key Takeaways
- Google's Core Web Vitals thresholds are the real targets: LCP under 2.5 s, INP under 200 ms, CLS under 0.1. Miss them and you're in the "needs improvement" bucket, which is where most sites live.
- Images and unoptimized JavaScript are usually the biggest wins, and they're free to fix.
- Speed affects more than rankings: slow responses eat your crawl budget, so Google indexes fewer of your pages.
- Always measure on mobile first. Desktop scores flatter everyone.
- Fixing speed in the wrong order is how you spend a week and gain 0.3 seconds.
Why speed matters for SEO more than most people admit
The obvious answer is that page experience is a ranking signal. True, but it's a small one, and honestly the correlation between a fast site and a well-ranked site is weaker than the industry likes to claim. I've seen slow sites rank first. I've seen lightning-fast sites stuck on page four.
So let me give you the two reasons that actually move the needle.
Crawl budget and indexation
Googlebot has a limited amount of time it will spend on your site. If every page takes four seconds to respond, the crawler downloads fewer pages per visit. On a large site, that's the difference between having your product pages indexed and having them quietly ignored for months. I watched this happen on a 4,000-page e-commerce site: half the catalog was stuck in "Discovered — currently not indexed" in Search Console. We didn't change the content at all. We cut server response time from roughly 1.9 s to around 400 ms, and within about five weeks the indexed page count grew by more than a third.
User behavior feeds back into SEO
A slow page doesn't just annoy visitors. It changes what they do next, and what they do next shows up in engagement signals. On a landing page I tested two years ago, dropping the LCP from 4.2 s to 1.8 s lifted the scroll-through rate from 38% to 61%. Same copy, same traffic source. The page just stopped feeling broken.
Speed isn't a silver bullet. It's a multiplier. On a page that already converts, it adds. On a page nobody wants, it does nothing.
How to measure website speed before you touch anything
Never optimize blind. I made that mistake early on and spent two days minifying CSS files that accounted for 4% of load time.
Website speed test: the tools worth your time
You need three, and they answer different questions.
- PageSpeed Insights — gives you both lab data (a simulated test) and field data from real users. The field data is the one Google uses. Ignore the lab score if the two disagree.
- Search Console's Core Web Vitals report — shows how your real visitors, grouped by URL, are performing. This is where you find out whether Google thinks you pass.
- WebPageTest — the waterfall view, which is where the actual diagnosis happens. Free, and I still use it more than anything else.
One warning: run each test three times. Results swing wildly, especially on cheap shared hosting. I've seen the same URL score 41 and 78 within ten minutes with zero changes.
Reading the results without panicking
Look at three numbers first: TTFB, LCP, and total transferred bytes. If TTFB is above 600 ms, nothing else you fix will matter much; your server is the bottleneck. If your page weighs more than about 2 MB, images are almost certainly the culprit. And if LCP is slow but everything else looks fine, it's usually a render-blocking resource in your <head>.
The fixes, in the order I'd do them
Here's where most guides go wrong. They hand you seventeen tips with equal weight. That's useless. Effort and payoff are wildly uneven, so let me rank them the way I'd actually work.
Step 1: images (biggest win, almost always)
Images are 50% or more of the weight on a typical page, and most of them are still served far too large. Convert to WebP or AVIF, serve the right dimensions instead of scaling a 3000-pixel photo down with CSS, and add lazy loading for anything below the fold. Keep the hero image eager and prioritized; lazy-loading your LCP element is a self-inflicted wound and I've done it more than once.
On that six-second homepage from the start of this article, replacing the hero image and re-encoding nine product photos took the mobile LCP from 6.1 s to 2.3 s. One afternoon. No developers, no new hosting.
Step 2: cut JavaScript you don't need
Scripts are worse than images because they block rendering and eat CPU time on cheap phones. Open your network tab and sort by size. If you're running a WordPress site, that pile is usually plugins. I removed eleven plugins from a site last year and cut 340 KB of JavaScript. Nine of those eleven did nothing the site actually used.
Free tools like a caching plugin that also handles script deferral will get you most of the way here. You don't need a paid service for this part.
Step 3: TTFB, caching, and a CDN
If TTFB is still slow after the first two steps, the problem is your server or your database. Page caching fixes it for logged-out visitors, which is most of your traffic. A CDN fixes it for distant visitors, and most have a free tier that covers a normal blog or brochure site. Beyond that, you're buying a better host.
Step 4: the small stuff, only after
Fonts, third-party embeds, render-blocking CSS. All real, all worth doing eventually. But I've seen people spend a week on font subsetting to gain 200 ms while a 1.8 MB PNG sat untouched on the homepage. Do the small stuff last.
| Fix | Typical effort | Typical LCP gain | Cost |
|---|---|---|---|
| Image compression and sizing | Low | 1–3 s | Free |
| Removing unused plugins/scripts | Medium | 0.5–2 s | Free |
| Page caching | Low | 0.3–1.5 s on TTFB | Free tier available |
| CDN | Low | 0.2–1 s for distant users | Free tier available |
| Upgrading hosting | Medium | Highly variable | Paid |
Speed on WordPress: what actually works
WordPress gets its own section because the answers are specific and people keep asking the same three questions.
How to increase website speed WordPress
Start with a caching plugin that also minifies and defers scripts, then audit plugins ruthlessly. The theme matters too. A bloated multipurpose theme with a page builder can add 500 KB before you've added any content. I switched one site from a builder-heavy theme to a lean one and gained 1.4 s with zero content changes. That's the single most underrated WordPress fix.
Is a website speed up extension worth installing?
For WordPress, the caching plugins people call "extensions" are legitimately useful and mostly free. Browser extensions that promise to speed up your own browsing are irrelevant to SEO and I'd skip them. The important distinction: optimize the site, not your browser.
How to make websites load faster Google Chrome
If you're asking this because your site feels slow in Chrome, remember that Chrome's own settings don't change how Googlebot experiences your site. What you want is DevTools: the Network tab throttled to "Slow 4G" and "4x CPU slowdown," which roughly mimics a mid-range phone. Test there, not on your fiber connection.
What I'd skip entirely
A few things get recommended constantly and rarely pay off. Minifying HTML saves a few kilobytes and breaks nothing, but the gain is negligible next to image work. Chasing a perfect 100 PageSpeed score is a trap: the score is a lab simulation, and a 92 with a fast LCP beats a 100 that a real phone still struggles with. And don't obsess over CLS unless you actually see layout jumping; most sites are fine.
What you should watch instead is your field data drifting in the wrong direction. Speed isn't a project you finish. It's a condition you maintain, and it degrades every time someone uploads an uncompressed photo or installs one more plugin. The sites that stay fast are the ones where somebody is still checking.
