How to Improve Your Google PageSpeed Insights Score: 10 Actionable Tips

If you've ever run your site through Google PageSpeed Insights and cringed at a score in the 40s or 50s, you're not alone — and more importantly, you're in the right place. Improving your Google PageSpeed Insights score isn't just about vanity metrics. It directly affects your search rankings, bounce rates, and how quickly real users can interact with your pages. This guide walks you through every major optimization technique, from quick wins to deeper infrastructure changes, so you can move the needle on your score today.

Why Your Google PageSpeed Insights Score Matters

Before diving into fixes, it helps to understand what PageSpeed Insights actually measures. The tool uses Google Lighthouse under the hood and scores your page on a 0–100 scale across several Core Web Vitals:

Largest Contentful Paint (LCP) — How long it takes for the largest visible element to load
First Input Delay (FID) / Interaction to Next Paint (INP) — How quickly the page responds to user interactions
Cumulative Layout Shift (CLS) — How much the page visually shifts during load
First Contentful Paint (FCP) — When the first piece of content appears
Total Blocking Time (TBT) — The sum of time the main thread is blocked

A score of 90+ is considered "Good," 50–89 is "Needs Improvement," and anything below 50 is "Poor." Google uses these metrics as ranking signals, so a low score can genuinely hurt your organic traffic.

You can get a baseline measurement right now using the Website Performance Analyzer on OpDeck, which runs a Lighthouse-based audit and surfaces the same metrics PageSpeed Insights reports — giving you a clear starting point before you make any changes.

Step 1: Optimize Your Images (Often the Biggest Win)

Images are the number one cause of slow LCP scores and poor overall performance. A single unoptimized hero image can tank your score by 15–20 points.

Convert to Modern Formats

Switch from JPEG and PNG to WebP or AVIF. These formats offer comparable visual quality at 25–50% smaller file sizes.

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

The <picture> element with multiple sources lets browsers pick the best format they support, while falling back gracefully to JPEG for older browsers.

Add Width and Height Attributes

Always specify width and height on your <img> tags. This tells the browser how much space to reserve before the image loads, which directly prevents Cumulative Layout Shift.

Implement Lazy Loading

Images below the fold don't need to load immediately. Add loading="lazy" to defer off-screen images:

<img src="product.webp" alt="Product photo" loading="lazy" width="800" height="600">

Never apply lazy loading to your LCP image (typically the hero or first large image) — that will actually hurt your score.

Compress Aggressively

Use tools like Squoosh, ImageOptim, or Sharp (for Node.js pipelines) to compress images before uploading. Aim for under 100KB for most images and under 200KB even for large hero images.

Step 2: Eliminate Render-Blocking Resources

Render-blocking resources are JavaScript and CSS files that prevent the browser from displaying anything until they finish loading. This is one of the most common causes of poor FCP and LCP scores.

Defer Non-Critical JavaScript

Add defer or async to script tags that don't need to run immediately:

<!-- Blocks rendering — avoid this -->
<script src="analytics.js"></script>

<!-- Deferred — runs after HTML is parsed -->
<script src="analytics.js" defer></script>

<!-- Async — runs as soon as it downloads, out of order -->
<script src="widget.js" async></script>

Use defer for scripts that depend on the DOM, and async for completely independent scripts like analytics.

Move Scripts to the Bottom

If you can't add defer, move your <script> tags just before the closing </body> tag. This ensures the HTML renders before scripts execute.

Inline Critical CSS

The CSS needed to render above-the-fold content should be inlined directly in your <head> to avoid an extra network round-trip:

<head>
  <style>
    /* Critical CSS for above-the-fold content */
    body { font-family: sans-serif; margin: 0; }
    .hero { background: #1a1a2e; color: white; padding: 80px 20px; }
  </style>
  <link rel="stylesheet" href="full-styles.css" media="print" onload="this.media='all'">
</head>

The media="print" trick loads the full stylesheet asynchronously without blocking rendering.

Step 3: Enable Caching and Compression

Configure HTTP Caching Headers

Static assets like images, fonts, and CSS files should be cached aggressively. If you're using Apache, add this to your .htaccess:

<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/webp "access plus 1 year"
  ExpiresByType text/css "access plus 1 month"
  ExpiresByType application/javascript "access plus 1 month"
  ExpiresByType image/png "access plus 1 year"
  ExpiresByType image/jpeg "access plus 1 year"
</IfModule>

For Nginx:

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

Enable Gzip or Brotli Compression

Text-based files (HTML, CSS, JS) compress dramatically with Gzip or Brotli. Enable Brotli if your server supports it — it typically achieves 15–25% better compression than Gzip.

For Nginx:

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

Step 4: Reduce Server Response Time (TTFB)

Time to First Byte (TTFB) is how long the server takes to start responding. A slow TTFB hurts every subsequent metric because nothing can load until the server responds.

Use a Content Delivery Network (CDN)

A CDN caches your content on servers around the world, so users get responses from a nearby edge node rather than your origin server. This alone can cut TTFB from 800ms to under 100ms for geographically distant users.

Popular options include Cloudflare (which has a free tier), Fastly, and AWS CloudFront.

Optimize Your Database Queries

If your site is dynamic (WordPress, Laravel, etc.), slow database queries are often the hidden culprit behind high TTFB. Use query caching, add database indexes, and eliminate N+1 query patterns.

Implement Server-Side Caching

For CMS-based sites, full-page caching plugins make a massive difference:

WordPress: WP Rocket, W3 Total Cache, or LiteSpeed Cache
Laravel: Response caching middleware
Django: Django's cache framework with Redis or Memcached

Step 5: Optimize JavaScript Execution

Heavy JavaScript is the primary driver of poor TBT (Total Blocking Time) and INP scores.

Code-Split Your JavaScript Bundles

If you're using a modern bundler like Webpack or Vite, split your JavaScript into smaller chunks that load on demand:

// Instead of importing everything upfront
import { heavyChart } from './charts';

// Dynamically import when needed
const loadChart = async () => {
  const { heavyChart } = await import('./charts');
  heavyChart.render();
};

Remove Unused JavaScript

Use your browser's Coverage tab (DevTools → More Tools → Coverage) to identify JavaScript that's loaded but never executed. Third-party scripts are often major offenders — audit every script tag and remove anything you don't actively need.

Minimize Third-Party Script Impact

Third-party scripts (chat widgets, ad networks, social embeds) can be devastating to performance. Strategies to mitigate them:

Load them with async or defer
Use a tag manager with async loading
Delay non-critical scripts until after user interaction using a facade pattern:

// Load chat widget only after user scrolls or clicks
document.addEventListener('scroll', () => {
  loadChatWidget();
}, { once: true });

Step 6: Optimize Web Fonts

Web fonts are a common source of invisible text (FOIT) and layout shifts.

Use `font-display: swap`

This tells the browser to show fallback text immediately while the custom font loads:

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

Preload Critical Fonts

Add a preload hint in your <head> for fonts used above the fold:

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

Subset Your Fonts

If you only need Latin characters, subset your font file to remove glyphs you don't use. Tools like glyphhanger or Google Fonts' subsetting options can reduce font file sizes by 60–80%.

Step 7: Preconnect to Critical Third-Party Origins

If your page loads resources from external domains (Google Fonts, CDNs, APIs), add preconnect hints to establish connections early:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="preconnect" href="https://cdn.example.com">

This eliminates the DNS lookup, TCP handshake, and TLS negotiation overhead for these origins, shaving hundreds of milliseconds off your load time.

Step 8: Fix Cumulative Layout Shift (CLS)

CLS is often overlooked but can be surprisingly hard to fix. It measures unexpected visual shifts — the kind that make you accidentally click the wrong button.

Reserve Space for Ads and Embeds

Always define explicit dimensions for ad slots and embedded content:

.ad-container {
  min-height: 250px; /* Reserve space before ad loads */
  width: 300px;
}

Avoid Dynamically Injected Content Above Existing Content

If you're inserting banners, cookie notices, or other dynamic elements, ensure they either push content down predictably or are positioned absolutely/fixed so they don't affect document flow.

Use `aspect-ratio` for Responsive Media

.video-container {
  aspect-ratio: 16 / 9;
  width: 100%;
}

This reserves the correct space before the video or iframe loads.

Step 9: Audit Mobile Performance Specifically

PageSpeed Insights scores mobile and desktop separately, and mobile scores are almost always lower. Google's ranking algorithm uses the mobile score, so this is where you should focus most of your effort.

Common mobile-specific issues include:

Viewport not configured — Always include <meta name="viewport" content="width=device-width, initial-scale=1">
Touch targets too small — Buttons and links should be at least 48×48px
Text too small to read — Base font size should be 16px minimum
Unscalable content — Avoid fixed-width elements wider than the viewport

Step 10: Use a Performance Audit Workflow

Improving your Google PageSpeed Insights score isn't a one-time task — it's an ongoing process. Build a workflow around it:

Baseline audit — Run the Website Performance Analyzer to capture your current scores before making changes
Prioritize by impact — Focus on the opportunities that PageSpeed Insights marks as "High impact" first
Make one change at a time — This lets you measure the effect of each optimization individually
Re-test after each change — Compare scores to confirm improvements
Monitor continuously — Set up regular audits to catch regressions when you deploy new code or add third-party scripts

Interpreting Your Audit Results

When you run a Lighthouse audit, pay attention to three sections:

Opportunities — Specific changes with estimated time savings
Diagnostics — Deeper issues that affect performance indirectly
Passed Audits — Things already working correctly (useful for confirming your fixes worked)

Always test from multiple locations and devices. A score can vary by 5–10 points between runs due to network conditions, so take the average of 3–5 runs for a reliable baseline.

Common Mistakes That Hurt Your Score

Even experienced developers make these errors:

Lazy loading the LCP image — This delays your most important element and tanks your LCP
Using async on scripts that depend on each other — Causes race conditions and JavaScript errors
Forgetting to compress images after resizing — Resizing doesn't automatically reduce file size
Adding too many preconnect hints — Each preconnect opens a connection; too many can actually slow things down. Limit to 2–3 critical origins
Ignoring TTFB — All the frontend optimization in the world won't help if your server takes 2 seconds to respond
Testing only on desktop — Mobile is what Google actually uses for ranking

Conclusion

Improving your Google PageSpeed Insights score is entirely achievable with a systematic approach. Start with image optimization and render-blocking resources — these two areas alone typically account for the majority of score improvements. Then work through server response time, JavaScript execution, font loading, and CLS fixes. Each optimization compounds with the others, and it's common to see scores jump from the 40s to the 80s or 90s by working through this checklist methodically.

The key is to measure before and after every change. Use the Website Performance Analyzer on OpDeck to get a clear Lighthouse-based audit of your current state, track your improvements, and identify which issues are still holding your score back. It gives you the same data as PageSpeed Insights in a clean, actionable format — making it easy to prioritize what to fix next.

Start with your biggest opportunity, make the change, verify the improvement, and move to the next item. That's how you turn a 45 into a 95.