How to Improve Page Speed for SEO: A Step-by-Step Guide

Your PageSpeed Insights score is 34. Your competitor's is 91. You've spent the whole weekend compressing images and it hasn't moved. Sound familiar?

Here's what took me embarrassingly long to understand: most of that score has nothing to do with how fast your page actually loads for real visitors. The number you're staring at is lab data — a synthetic test run on a throttled connection from a single Google server. It's useful. It's also the single biggest source of wasted effort in technical SEO.

This guide is about improving page speed for SEO in a way that actually affects rankings: which metrics matter, which fixes move the needle, and which "optimizations" you can safely ignore. I'll tell you the ones I got wrong, too.

Does page speed impact SEO? Yes — but not the way most people think

Speed is important enough that Google turned it into an actual ranking factor. Over the years the company has also shipped a set of tools — Lighthouse, PageSpeed Insights — to help webmasters and developers measure and improve their loading times. So the answer to the question is a flat yes.

The nuance is which speed Google looks at.

Google ranks pages using what real visitors experienced, aggregated over time. That's field data. Your Lighthouse report is lab data: a controlled test. The two can disagree wildly. I've had pages score 95 in the lab and still fail Core Web Vitals in the field, because real users were on cheap Android phones over congested mobile networks, not a clean desktop connection from a data centre.

What actually ranks

Three metric families form the Core Web Vitals, and it helps to think of them as answers to three separate questions:

• LCP (Largest Contentful Paint) — how long until the main content appears? Usually that's your hero image or your biggest heading block.
• INP (Interaction to Next Paint) — when someone taps a button, how long until the page visibly reacts? This replaced First Input Delay, and it's stricter about what counts as "reacting".
• CLS (Cumulative Layout Shift) — how much does the layout jump around while loading?

On top of those, there's TTFB (Time to First Byte): the gap between the browser asking for your page and your server's first byte coming back. TTFB isn't a Core Web Vital, but it constrains all of them. A slow server makes everything downstream slower no matter how tidy your CSS is.

Why your PageSpeed score doesn't match reality

PageSpeed Insights shows you both. Scroll past the score circle and you'll find a section with real-user data — that's the one Google's ranking systems care about. If you only ever read the top number, you're optimising for a robot that visits your site once.

My rule: treat the lab score as a diagnostic tool, and field data as the scoreboard. If the lab says 60 and the field says "good", you have a testing-environment problem, not a speed problem.

How to diagnose page speed before you touch anything

Every mistake I've made in this area started with changing something before measuring it. Resist that.

The tools that earn their place

You don't need eleven speed testers. You need two, used properly:

• PageSpeed Insights for the combined view — lab diagnostics plus field data in one screen.
• WebPageTest when you need to see the waterfall: which request blocks which, and where the time actually goes.

GTmetrix and Pingdom are fine for a quick second opinion, and I still run them occasionally when a result looks weird. But if you're collecting scores from five tools, you're collecting opinions, not data. Pick your source of truth and stick with it for at least a month, because page speed measurements fluctuate by 10-20% between runs on the same unmodified page. I once "improved" a site by 8 points just by re-running the test at a quieter time of day. That wasn't an improvement. That was noise.

Read the waterfall, not the score

The waterfall tells you a story the score hides. Is your first byte arriving after 1.2 seconds? Then your problem is hosting, not assets. Is there a 600 ms gap where nothing happens before the largest element paints? Then something is render-blocking — usually a font, a stylesheet, or a third-party script.

One client site I worked on had a score of 41. Everyone assumed images. The waterfall showed a chat widget loading synchronously in the head, blocking everything for 900 ms. Removing it from the critical path took the field LCP from 4.1 seconds to 2.3 in under an hour.

How to make your page load faster: the fixes that actually matter

Ordered by impact, not by how fun they are to implement.

1. Images, images, images

On the vast majority of content sites, images are the heaviest thing on the page. This is where you'll find your biggest win, and it's rarely exciting work.

Three things, in order:

1. Serve modern formats. WebP and AVIF typically cut file size well below what JPEG delivers at comparable quality. On one blog I migrated, the median image dropped from around 380 KB to under 110 KB. No visible difference.
2. Size them correctly. A 2400-pixel-wide image displayed in a 700-pixel column is wasted bytes. Resize before upload, or let a CDN do it on the fly.
3. Lazy-load everything below the fold — and nothing above it. This is the part people get wrong. Lazy-loading your hero image is one of the fastest ways to wreck your LCP, because you've told the browser to wait before fetching the thing you're being judged on.

Also set explicit width and height attributes on every image. That single habit was the difference between a CLS of 0.21 and 0.02 on a project I inherited. The layout stopped jumping because the browser finally knew how much space to reserve.

2. Server response time

If TTFB is above roughly 600 ms, stop reading about image compression and go talk to your host. Nothing downstream compensates for a slow server.

What usually helps:

• Full-page caching, so most requests never hit your database at all.
• A CDN in front of everything, so static assets are served from a location near the visitor.
• Upgrading to a host that supports current PHP versions (or whatever runtime you're on) — outdated runtimes are slow by design.

Full-page caching alone took a site I manage from a 1.4-second TTFB to 190 ms. Same content, same theme, one plugin.

3. Reduce render-blocking resources

The browser can't paint your page until it has parsed the CSS and any synchronous JavaScript in the head. Trim that critical path:

• Inline the small amount of CSS needed for above-the-fold content.
• Defer or async non-essential scripts.
• Audit third-party tags ruthlessly. Analytics, chat, heatmaps, A/B tools — each one is a request you don't control. I removed four tracking scripts from a client's site and INP improved noticeably within a week, with zero complaints from the marketing team.

4. Fonts

Custom fonts are a quiet killer. Self-host them rather than pulling from a third-party domain, subset them to the characters you actually use, and use font-display: swap so text shows immediately in a fallback face. The flash of unstyled text is uglier than a blank page that never loads.

What are common SEO mistakes to avoid?

Most of the damage in page speed work comes from these:

• Optimising for the score instead of the user. A 100 that loads in three seconds on a real phone is worse than a 78 that loads in one.
• Lazy-loading the hero image. Directly harms LCP.
• Adding plugins to fix plugins. Caching plugins stacked on minification plugins stacked on image optimisers can slow a site down. I've unwound this on three separate sites, and each one got faster after removing tools, not adding them.
• Ignoring mobile entirely. Most sites get the majority of their traffic from phones on mediocre connections. If you only test on desktop, you're testing the wrong visitor.
• Assuming a host migration will fix it. Sometimes it does. Usually the biggest problem is on your side of the server boundary.

How to optimise a page for SEO without breaking speed

Speed and on-page SEO pull in opposite directions more often than people admit. Every keyword-rich element you add is weight.

Element	SEO benefit	Speed cost	Verdict
Title tag and meta description	High	None	Always do it
Structured data (JSON-LD)	Moderate	Negligible if inline	Do it, keep it small
Alt text on images	Moderate	None	Free — never skip
Multiple heavy hero images	Low	Severe	Cut it down to one
Embedded video above the fold	Low	Severe	Facade-load it
Nine font weights	None	Real	Two weights, maximum

The pattern: things that cost nothing (titles, alt text, structured data) should be done fully. Things that cost a lot and give little (decorative video, five font weights) should be trimmed. That's the whole trade-off, and it's genuinely that simple.

If you want a repeatable checklist for on-page work that doesn't undo your speed gains, work in this order: content first, metadata second, media third, third-party embeds last. And re-measure after each step. Change one thing at a time, or you'll never know what worked.

Where to start tomorrow

Open PageSpeed Insights. Ignore the score. Scroll to the field data section and write down your LCP, INP, and CLS numbers on a piece of paper.

Then open the waterfall and find your TTFB. If it's above 600 ms, that's your project for the week — caching and a CDN, nothing else. If it's fast, go after images. Resize, convert, and stop lazy-loading your hero.

The uncomfortable truth about page speed is that the fixes that matter most are boring and repetitive, and the ones that feel clever usually don't move the number that counts. I've chased both. The boring ones won every time.