10 Quick Wins to Improve Your Google PageSpeed Score

Why Your PageSpeed Score Matters

Google PageSpeed Insights gives your site a score from 0 to 100. It's not just a vanity metric — it directly influences your search rankings, your ad costs, and whether visitors stick around long enough to become customers.

The brutal truth: 53% of mobile users abandon a site that takes longer than 3 seconds to load. And Google has been using Core Web Vitals as a ranking signal since 2021, meaning a slow site is getting penalised in search results every single day.

The good news? Most sites fail for the same handful of reasons. Fix those, and you can move from a failing score into the green (90+) without a full rebuild.

Here are the 10 changes that deliver the biggest improvement for the least effort.

1. Compress and Convert Your Images

Images are almost always the single biggest contributor to slow load times. A single unoptimised hero image can be larger than your entire HTML, CSS, and JavaScript combined.

What to do:

Convert images to WebP format (typically 25–35% smaller than JPEG at the same quality)
Compress with a tool like Squoosh, ImageOptim, or Sharp
Use the element to serve WebP with JPEG fallback for older browsers

<picture>
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Hero image" width="1200" height="600">
</picture>

Expected impact: 10–30 point score improvement for image-heavy sites.

2. Set width and height on Images

This is a two-minute fix that prevents layout shift — one of Google's Core Web Vitals (CLS). When a browser doesn't know an image's dimensions before it loads, the page shifts as the image appears. That's jarring for users and penalised by Google.

What to do: Add explicit width and height attributes to every tag:

<img src="photo.jpg" alt="Team photo" width="800" height="450">

You don't need to match the displayed size exactly — just the aspect ratio. Modern CSS handles the actual display size.

3. Enable Text Compression (GZIP or Brotli)

HTML, CSS, and JavaScript files are text — and text compresses remarkably well. Enabling server-side compression can reduce file sizes by 60–80%.

For Nginx:

gzip on;
gzip_types text/plain text/css application/javascript application/json;
gzip_min_length 1000;

For Apache (.htaccess):

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/css application/javascript
</IfModule>

If your hosting doesn't allow server configuration, check if your CDN (Cloudflare, Fastly) can handle it — most do.

4. Lazy Load Below-the-Fold Images

There's no reason to download images the user can't see yet. Lazy loading tells the browser to wait until an image is about to scroll into view before fetching it.

What to do: Add loading="lazy" to any image that isn't visible on first load:

<img src="blog-thumbnail.jpg" alt="Blog post" loading="lazy" width="400" height="300">

Important: Do NOT add this to your hero image or any image visible above the fold. Those should load immediately — and you should actually mark your LCP image with fetchpriority="high" to ensure it loads as fast as possible.

5. Eliminate Render-Blocking Resources

If your CSS or JavaScript is loaded in the without async or defer, it blocks the browser from rendering the page until those files finish downloading. This directly inflates your Largest Contentful Paint (LCP) time.

For JavaScript:

<!-- Blocking (bad) -->
<script src="app.js"></script>
<!-- Non-blocking (good) --> <script src="app.js" defer></script>

Use defer for scripts that need to run after the DOM is built. Use async for independent scripts (analytics, chat widgets) that don't need to wait.

For CSS: Load critical CSS inline in the and load non-critical CSS asynchronously or at the bottom of the page.

6. Minify CSS, JavaScript, and HTML

Minification removes whitespace, comments, and redundant characters from your code files. It doesn't change functionality but can reduce file sizes by 20–30%.

If you're using a build tool like Webpack, Vite, Parcel, or Next.js, minification is often already happening in production mode. If you're working with plain files, tools like Terser (JS) and cssnano (CSS) can be added to your workflow.

Quick check: Compare your production JS/CSS file sizes with the same files uncompressed. If they're identical, minification isn't running.

7. Set Long Cache Lifetimes for Static Assets

The fastest request is the one that never gets made. Browser caching lets returning visitors load your site from their local cache instead of re-downloading everything.

For Nginx:

location ~* .(js|css|png|jpg|webp|woff2)$ {
  expires 1y;
  add_header Cache-Control "public, immutable";
}

Use long cache times (1 year) for versioned assets (files with a hash in the name, like app.a1b2c3.js). Use shorter times for files that might change, like your HTML.

8. Reduce Third-Party Script Overhead

Every third-party script — analytics, chat widgets, ad pixels, social embeds — adds weight and latency to your page. Some are unavoidable, but many are running on sites that never get value from them.

What to do:

Audit your third-party scripts (DevTools Network tab, filter by third-party domains)
Remove any you're not actively using
Load the rest with async or defer
For non-critical widgets (chat, social feeds), load them only after the main content is interactive

A single unused analytics tag from a platform you switched away from three years ago can cost you 200–500ms. Check for them.

9. Optimise Web Font Loading

Web fonts are a common source of both slow rendering and layout shift. The browser can't render text until the font is downloaded — unless you tell it what to do in the meantime.

Add font-display: swap:

@font-face {
  font-family: 'MyFont';
  src: url('myfont.woff2') format('woff2');
  font-display: swap;
}

This tells the browser to render text in a fallback font immediately, then swap in your custom font when it loads. Users see content instantly instead of a blank page.

Also: preload your most important font file in the :

<link rel="preload" href="/fonts/myfont.woff2" as="font" type="font/woff2" crossorigin>

10. Run a Full Audit and Fix the Site-Specific Issues

The nine fixes above are the most common wins — but every site has unique problems. A site on shared hosting with no CDN has different bottlenecks than a site on a fast CDN but with a 5MB JavaScript bundle.

The only way to know exactly what's holding your score back is to run a full audit. Look specifically at:

Largest Contentful Paint (LCP): What is the LCP element? Is it an image? A text block? Why is it loading slowly?
Cumulative Layout Shift (CLS): Are elements shifting after load? Usually caused by images without dimensions or late-loading ads.
Interaction to Next Paint (INP): Is JavaScript blocking interactivity?

Tools like PageScore run a comprehensive audit across performance, SEO, security, and accessibility in one go — including Core Web Vitals data and specific fix recommendations for each issue found. You can also check out our complete website audit checklist to make sure you're covering every angle beyond just performance.

Putting It Together

Don't try to implement all ten changes at once. Prioritise by impact:

1. First: Image compression and WebP conversion (biggest bang for effort) 2. Second: Lazy loading + width/height attributes (fast CWV wins) 3. Third: Enable text compression (server-side, one change, permanent benefit) 4. Then: Defer scripts, remove unused third-party tags, enable caching

Run PageSpeed Insights before and after each change to see the impact. Most sites with a score below 60 can reach 85+ by just working through this list.

---

Want to know exactly what's slowing your site down? Run a free PageScore audit — it checks performance, Core Web Vitals, SEO, security, and accessibility in 30 seconds, with specific code fixes for every issue found. No signup required.