DEV Community

Cover image for How to Actually Raise Your Google PageSpeed Score in 2026
Eduard
Eduard

Posted on • Edited on

How to Actually Raise Your Google PageSpeed Score in 2026

#performance #webperf #seo #webdev

A few weeks ago I finished a three-hour deep dive into font loading for a client. Subsetting, preloading, font-display: swap — the works. PageSpeed came back at 92.
The client asked the only question that mattered: “Did we fix the real problem?”

The hero image was still 4.2 MB. One conversion to AVIF and a proper <picture> tag later the score dropped to 58. Suddenly Lighthouse could see everything else that was broken.

That’s the thing about PageSpeed scores. They show you what the lab thinks is slow. Real users often experience something completely different.

Table of Contents

What PageSpeed Insights Really Measures

Google PageSpeed Insights runs Lighthouse in a controlled lab. You get a 0–100 number. That number itself is not a ranking factor. Core Web Vitals are. And the two are related, but not identical.

Here’s the simple rule I give clients:

  • Below 50 → real problems that users feel
  • 50–89 → fix the obvious stuff
  • 90+ → open Chrome DevTools and look at actual load time before you celebrate

For a deeper look at the ranking metrics that actually matter, see our guide on how to fix Core Web Vitals issues.

Real Case Study: 42 → 91 in One Afternoon

Last month a mid-size e-commerce client came in with a mobile PageSpeed score of 42. Field data from CrUX showed LCP at 4.1 s and INP at 380 ms. Users were bouncing hard on product pages.
We did two things only:

  1. Converted the 3.8 MB hero JPEG to AVIF (primary) + WebP (fallback) and served it with a proper <picture> element.

  2. Removed or deferred 1.2 MB of third-party trackers and chat widgets that were blocking the main thread.

Results after one afternoon of work:

Metric Before After
Mobile PageSpeed 42 91
LCP 4.1 s 1.3 s
INP 380 ms 95 ms
Total page weight 6.4 MB 1.9 MB

No fancy critical CSS, no server migration, no CDN change. Just images and JavaScript hygiene. That’s why I keep saying the big wins are almost always the boring ones.

Want to see where your own site stands right now? Open the free SEO analyzer in another tab and run your URL while you keep reading.

The Five Things That Move the Needle Most

After looking at more than two hundred sites, the same five issues keep showing up.

Images. Almost always the biggest culprit. I have yet to audit a site under 70 where images weren’t the main drag. Full details in our Image SEO complete guide.

JavaScript execution time. This one hides. You can score 95 and still have three seconds of main-thread blocking. Check the Performance panel, not just the Lighthouse report. Slow JS is also the primary reason INP fails on mobile.

Server response time (TTFB). If the server takes more than 800 ms to answer, nothing else you do will feel fast.
Caching. Set it once and every return visitor benefits.
CDN. If your audience is spread across countries and your origin is in one place, a CDN is no longer optional.

When the Score Lies

Last quarter I checked a Shopify store that scored 98. Actual load time for a real user: 4.2 seconds. Forty-seven tracking scripts, a chat widget, a popup, and three recommendation engines. Lighthouse tested a clean version without most of that noise.
Lab data and field data are different animals. Real visitors have ad blockers, older phones, and flaky connections that no lab simulation fully captures.

My Real Workflow (Not a Checklist)

When someone asks me to improve their score, this is what I actually do.

  1. Open DevTools first. Look at the network waterfall. Total size, number of requests, longest assets. Try it now: open Chrome DevTools on your own site, go to Network, disable cache, reload, and sort by size. If anything over 200 KB is an image or a third-party script, you already know your first target.
  2. Find the biggest offenders. Usually images. Sometimes a 2 MB JavaScript bundle that does almost nothing useful.
  3. Fix images. Convert to modern formats, add srcset, lazy-load everything below the fold. Fifteen minutes of work often gains 10–20 points.
  4. Kill unused JavaScript. Open the Coverage tab. Sixty to eighty percent of the code is frequently never executed. Remove it.
  5. Stop over-optimizing. Chasing the last three points on a 95 score is rarely worth the time. If you want a broader technical check after these steps, run a full SEO audit.

The WebP (and AVIF) Trap + Code Example

Everyone says “just convert to WebP.” I did that once and the score went down. Older Safari versions didn’t support it cleanly, and the fallback JPEG was three times larger.
Now I always use the full <picture> element with multiple sources and a solid fallback. More markup, but it works everywhere.

Here’s the exact pattern I ship:

<picture>
  <source
    srcset="hero-800.avif 800w, hero-1200.avif 1200w, hero-1600.avif 1600w"
    type="image/avif"
    sizes="(max-width: 768px) 100vw, 1200px">
  <source
    srcset="hero-800.webp 800w, hero-1200.webp 1200w, hero-1600.webp 1600w"
    type="image/webp"
    sizes="(max-width: 768px) 100vw, 1200px">
  <img
    src="hero-1200.jpg"
    width="1200"
    height="675"
    alt="Product hero showing the main benefit"
    fetchpriority="high"
    decoding="async">
</picture>
Enter fullscreen mode Exit fullscreen mode

Key points:

  • AVIF first, WebP second, JPEG last.
  • Explicit width and height prevent CLS.
  • fetchpriority="high" on the LCP image.
  • Never put loading="lazy" on the hero.

For third-party scripts that are not needed on first paint, the same principle applies:

<!-- Bad: blocks parsing and execution -->
<script src="https://example.com/tracker.js"></script>
<!-- Better: does not block parsing -->
<script src="https://example.com/tracker.js" defer></script>
<!-- Best for non-critical widgets: load only after interaction or idle -->
<script>
  window.addEventListener('load', () => {
    const s = document.createElement('script');
    s.src = 'https://example.com/chat-widget.js';
    s.async = true;
    document.body.appendChild(s);
  });
</script>
Enter fullscreen mode Exit fullscreen mode

Fonts That Don’t Block the Page

font-display: swap is not a magic bullet. It just means invisible text for a moment, then a flash. Fine for body copy. Ugly for headlines.
My current approach: system fonts for body text, and for brand fonts — preload only the exact weights you actually use. I still see sites loading twelve font files when they need three.

Why INP Matters More Than the Old FID

FID (First Input Delay) only measured the delay before the very first interaction. Google replaced it with INP (Interaction to Next Paint) in 2024, and by 2026 it is the only interactivity metric that counts for ranking.

INP looks at every interaction throughout the page life — clicks, taps, key presses — and reports the worst ones (98th percentile). That is why a site can have a perfect lab score and still feel laggy on a mid-range Android phone.
The main cause of poor INP is almost always JavaScript that monopolizes the main thread for longer than 50 ms. Long tasks from analytics, chat widgets, A/B testing libraries, or heavy event handlers are the usual suspects.

Practical ways to improve INP:

  • Break long tasks into chunks under 50 ms (setTimeout, requestIdleCallback, or the newer Scheduler API).
  • Defer or remove third-party scripts that run on every page load.
  • Use the Coverage tab and the Performance panel together — Coverage shows unused code, Performance shows the actual long tasks. If your INP is above 200 ms on mobile, fixing JavaScript will usually give a bigger ranking and conversion lift than shaving another 5 points off the PageSpeed score.

The Real 80/20

Three actions deliver most of the gain:

  1. Compress and correctly size every image (Squoosh is still free and excellent).
  2. Remove unused JavaScript with the Coverage tab.
  3. Turn on caching and put a CDN in front of the site. On platforms like Vercel or Netlify this is already handled. Everything else — critical CSS, advanced preloading, Speculation Rules — is polishing. Do the big three first.

When to Stop

I once spent eight hours with a client trying to turn a 99 into a 100. The missing point was a 12 KB analytics script that was already async.
My rule now: if the score is above 90 and real load time is under two seconds, stop. Your time is more valuable than that last point.

Quick Checks Before the Next Test

  • Run the URL through a proper combined audit (PageSpeed + real traffic signals) at AuditMe.
  • Look at your largest image. Anything over 200 KB needs attention.
  • In DevTools → Network, disable cache and reload. If the page is over 2 MB, something is wrong.
  • Check the JavaScript bundle size. Over 500 KB usually means dead code.
  • For a focused score check, use the dedicated SEO Score Checker.
  • Want the full picture in under a minute? The free SEO analyzer pulls it all together. ## Bottom Line PageSpeed scores are useful signals, not the final truth. I have seen perfect 100s that felt sluggish and mid-60s that loaded faster than most sites. Focus on what users actually experience. Under two seconds, green Core Web Vitals (especially LCP under 2.5 s and INP under 200 ms) put you ahead of the majority of the web. That’s the only score that really matters.

Related Guides

Continue with these practical guides from the same series:

Sources & Further Reading

This article draws on practical audit experience and the following public resources:

Top comments (0)