How to Improve Your Google PageSpeed Score in 2026

A Score of 92 That Should Have Been 42

Last month I spent three hours optimizing font loading on a client site — subsetting, preloading, swapping to font-display: swap, the whole nine yards. Final PageSpeed score: 92.

The client asked if we'd fixed the actual problem. Turns out the hero image was 4.2MB. One <picture> tag and an AVIF conversion later, we went from 92 to 58 — because now Lighthouse could actually see how slow the rest of the page was.

That's what happens when thing about PageSpeed scores. They don't tell you what's actually slow. They tell you what Lighthouse thinks is slow. And sometimes those are very different things.

What PageSpeed Actually Measures

Google PageSpeed Insights gives you a 0-100 score based on lab data from Lighthouse. It's not a ranking factor itself, but it correlates with Core Web Vitals — and those are ranking factors.

What I tell clients: if your score is below 50, you have real problems. If it's 50-89, you're in the "fix the obvious stuff" zone. If it's 90+, don't celebrate yet — go look at your actual page load time in Chrome DevTools.

The Five Things That Actually Move the Needle

After auditing 200+ sites, here's what consistently makes the biggest difference:

Images. Always images. I've never audited a site scoring below 70 where images weren't the primary issue. Not fancy JavaScript optimization, not critical CSS — images.

JavaScript execution time. This one's sneaky because it doesn't always show up in Lighthouse audits. Your page might score 95 but still have 3 seconds of main-thread blocking. Check the Performance tab in DevTools, not just Lighthouse.

Server response time. If your TTFB is over 800ms, nothing else matters. From my experience, sites with perfect images and zero JavaScript that still load slowly because the server takes 2 seconds to respond.

Caching. This is the gift that keeps on giving. Set it once, and every returning visitor benefits.

CDN. If your audience is global and your server is in one location, a CDN isn't optional anymore.

When PageSpeed Lies to You

After checking a Shopify store last quarter. PageSpeed score: 98. Actual load time: 4.2 seconds. The store had 47 tracking scripts, a chat widget, a popup, and three recommendation engines. Lighthouse didn't care — it tested a clean version without any of that.

This happens all the time. PageSpeed tests your page in a lab environment. Your real users have ad blockers, slow phones, and network conditions that no lab can simulate.

My Actual Workflow (Not a Checklist)

What I do when someone asks me to improve their PageSpeed score:

Step 1: Open DevTools, not PageSpeed Insights. I want to see the actual network waterfall. How big is the page? How many requests? What's taking the longest?

Step 2: Check the biggest offenders. Usually it's images, but sometimes it's a 2MB JavaScript bundle that's doing absolutely nothing useful. From my experience analytics scripts larger than entire landing pages.

Step 3: Fix images. This is almost always the first win. Convert to WebP, add srcset, lazy-load below-the-fold content. Takes 15 minutes, usually gains 10-20 points.

Step 4: Kill unused JavaScript. Open the Coverage tab in DevTools. You'll probably find 60-80% of your JavaScript is never executed. Remove it.

Step 5: Don't over-optimize. From my experience developers spend days trying to squeeze 3 more points out of a 95 score. That time is better spent fixing actual user experience issues.

The WebP Trap

Everyone tells you to convert images to WebP. I did that on a client site, and their score actually went down. Why? Because they were serving WebP to Safari users on older iOS versions that don't support it. The fallback JPEG was 3x larger.

Now I always test with <picture> tags and multiple sources:

<picture>
 <source srcset="hero.avif" type="image/avif">
 <source srcset="hero.webp" type="image/webp">
 <img src="hero.jpg" alt="Hero image">
</picture>

It's more code, but it works everywhere.

Fonts That Don't Block Rendering

I used to think font-display: swap was a silver bullet. Then I realized it just means "show invisible text briefly, then flash the real font." That's fine for body text, but for headlines it looks broken.

My current approach: use system fonts for body text, and for brand fonts, preload only the weights you actually use. I recently audited a site loading 12 font weights when they only used 3.

The 80/20 Rule (Actually True This Time)

Out of all the optimizations you could make, these three will get you 80% of the way:

1. Compress and resize images. Use Squoosh.app. It's free. Takes 5 minutes per image.
2. Remove unused JavaScript. Use the Coverage tab. Be brutal.
3. Enable caching and use a CDN. If you're on Vercel or Netlify, this is already done.

Everything else — critical CSS, font optimization, preloading — is polishing. Do the big three first.

When to Stop Optimizing

I had a client who was obsessed with hitting 100. We got to 99 and spent 8 hours trying to find the last point. It was a 12KB analytics script that was already async.

My honest take rule: if you're above 90 and your actual load time is under 2 seconds, stop. Your time is worth more than that last 10 points.

Quick Wins Before You Go

Before running another PageSpeed test, try these:

- Run your URL through AuditMe — it combines PageSpeed data with actual traffic metrics

- Check your largest image. If it's over 200KB, compress it

- Open DevTools → Network → check "Disable cache" → reload. If your page is over 2MB, something's wrong

- Look at your JavaScript bundle. If it's over 500KB, you have unused code

The Bottom Line

PageSpeed scores are useful, but they're not the whole story. From my experience, sites with perfect scores that are painfully slow, and sites with scores in the 60s that load faster than anything.

Focus on actual user experience. If your page loads in under 2 seconds and your Core Web Vitals are green, you're doing better than most.

Run a free SEO audit to see how your site actually performs.