How to Get a 100 Google PageSpeed Score (and Why It Matters)

Every website owner has run their site through Google PageSpeed Insights at some point. Most see a score in the 40–70 range, sigh, and move on. But that score represents real problems: slow load times, bloated code, unoptimized images, and a poor user experience that costs you visitors, customers, and search rankings.

Achieving a 100 PageSpeed score is possible for most websites, and the process of getting there forces you to fix real performance problems. This guide walks you through every optimization, from the high-impact server-side changes to the fine-tuned frontend tweaks that push you from 90 to 100.

Understanding the PageSpeed Score

Google PageSpeed Insights (PSI) uses Lighthouse, an open-source tool, to audit your page's performance. The score is a weighted average of six metrics:

Notice that TBT (30%) and LCP (25%) account for 55% of the total score. If you can only fix two things, focus on reducing JavaScript execution time and speeding up your largest visible content.

Score Ranges

• 0–49 (Red): Poor. Significant performance issues affecting user experience and SEO.
• 50–89 (Orange): Needs improvement. Noticeable delays, especially on mobile devices.
• 90–100 (Green): Good. Fast, responsive, and well-optimized. 100 is the ceiling.

Step 1: Start with the Server

Frontend optimization is important, but it's limited by your server. A page that takes 800ms just for the server to respond (TTFB) has already lost one-third of its LCP budget before the browser even starts rendering.

Choose Fast Hosting

The single biggest performance improvement most websites can make is upgrading their hosting. Here's what to look for:

• NVMe SSD storage — 7x faster than traditional SSDs for database queries and file reads
• LiteSpeed web server — 3–5x faster than Apache, with built-in page caching
• PHP 8.3+ — 30–40% faster than PHP 7.4 for WordPress sites
• HTTP/3 support — Reduces connection time, especially on mobile networks

Enable Server-Level Caching

Server-level caching stores generated HTML pages so the server doesn't have to rebuild them for every visitor. On WordPress with LiteSpeed, the LiteSpeed Cache plugin provides full-page caching that reduces TTFB to under 50ms for cached pages.

Without caching, a typical WordPress page takes 400–800ms to generate. With proper caching, it takes 10–50ms. That's a 10–40x improvement in server response time.

Step 2: Optimize Images

Images are typically the largest resources on any webpage. They account for 40–60% of total page weight on most sites. Optimizing images has an outsized impact on LCP and Speed Index.

Convert to Modern Formats

WebP and AVIF offer dramatically better compression than JPEG and PNG:

Use the <picture> element to serve AVIF with WebP and JPEG fallbacks. For WordPress, plugins like ShortPixel or Imagify handle automatic conversion. Read our full image optimization guide for more details.

Properly Size Images

Never serve a 3000x2000px image in a container that's 800px wide. Use responsive images with the srcset attribute to serve appropriate sizes for each device. An image that's 300KB on mobile instead of 1.2MB on desktop makes a massive difference on cellular connections.

Lazy-Load Below-the-Fold Images

Add loading="lazy" to images below the fold. This tells the browser to only load them when they're about to enter the viewport. However, never lazy-load the LCP image (typically your hero image) — this delays LCP and hurts your score.

Step 3: Eliminate Render-Blocking Resources

Render-blocking resources are CSS and JavaScript files in the <head> that prevent the browser from rendering content until they're fully downloaded and parsed.

Inline Critical CSS

Critical CSS is the minimum CSS needed to render above-the-fold content. Instead of waiting for a full stylesheet to download, inline these styles directly in the <head>:

• Use tools like Critical, Critters, or PurgeCSS to extract critical CSS automatically
• Load the full stylesheet asynchronously using media="print" onload="this.media='all'"
• Keep inlined CSS under 14KB (the size of the first TCP roundtrip) for maximum benefit

Defer Non-Critical JavaScript

Add the defer attribute to all non-essential scripts. This tells the browser to download them in parallel but execute them only after the HTML is parsed. For scripts that don't need to interact with the DOM at all (analytics, tracking), use async instead.

Third-party scripts are the most common culprits. Google Analytics, chat widgets, social media embeds, and heatmaps all add JavaScript that competes with your content for the main thread. Defer or dynamically load them after the page is interactive.

Step 4: Minimize JavaScript Execution

TBT (Total Blocking Time) carries the highest weight in the PageSpeed score at 30%. It measures how long the main thread is blocked by JavaScript tasks longer than 50ms. Every millisecond of blocking time hurts your score.

Audit Your JavaScript

Use Chrome DevTools Coverage tab to identify unused JavaScript. Most websites ship 40–60% more JavaScript than they actually use on any given page. Common sources of bloat:

• jQuery — Many WordPress themes still load the full 90KB jQuery library for a few DOM manipulations that modern vanilla JS handles in 2KB
• Unused plugin scripts — Plugins that load their scripts on every page, even if only used on one page
• Full library imports — Importing the entire lodash library (72KB) when you only need one function
• Polyfills for modern browsers — Serving ES5 polyfills to browsers that already support ES6+

Code Split and Tree Shake

If you use a build tool (Webpack, Vite, Rollup), enable code splitting to only load the JavaScript needed for the current page. Tree shaking removes unused exports from your bundles. Together, these can reduce JavaScript payload by 50–70%.

Use Web Workers for Heavy Tasks

If you have computationally expensive JavaScript (data processing, complex calculations), move it to a Web Worker. Web Workers run in a separate thread and don't block the main thread, keeping TBT at zero for those tasks.

Step 5: Fix CLS Issues

CLS accounts for 25% of the PageSpeed score. The most common fixes:

1. 1Set explicit dimensions on images and videos. Always include width and height attributes.
2. 2Reserve space for ads. Use min-height on ad containers.
3. 3Preload web fonts. Use <link rel="preload" as="font"> and set font-display: swap with matched fallback metrics.
4. 4Avoid dynamically injecting content above existing content. Cookie banners, promotional bars, and notification popups should overlay, not push content.

Step 6: Enable Compression and Caching

Brotli or GZIP Compression

Compression reduces the size of text-based files (HTML, CSS, JavaScript) by 60–80%. Brotli is 15–20% more efficient than GZIP and is supported by 97%+ of browsers. Most modern web servers support both.

Browser Caching Headers

Set proper Cache-Control headers so browsers cache static assets locally. A returning visitor shouldn't re-download your CSS, JavaScript, or images. Recommended cache durations:

For a deeper dive into caching strategies, see our website caching guide.

Step 7: Use a CDN

A Content Delivery Network serves your static assets from edge servers close to your visitors. This reduces latency for users far from your origin server. CDNs typically improve FCP and LCP by 100–500ms for geographically distributed audiences.

Beyond speed, CDNs offer additional PageSpeed benefits:

• Automatic image optimization and format conversion (WebP/AVIF)
• Automatic Brotli compression
• HTTP/3 support (even if your origin server doesn't support it)
• Edge caching that reduces server load

Learn how to set up and configure a CDN in our CDN setup guide.

Step 8: Fine-Tune for 100

Getting from 90 to 100 requires attention to the small details:

Preconnect to Required Origins

If you load resources from third-party domains (fonts.googleapis.com, analytics, CDN subdomains), add preconnect hints to establish the connection early. Each preconnect saves 100–200ms:

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

Self-Host Google Fonts

Instead of loading fonts from Google's CDN, download and self-host them. This eliminates the DNS lookup and connection to fonts.googleapis.com and fonts.gstatic.com, saving 200–400ms. Use tools like google-webfonts-helper to generate optimized font files and CSS.

Minimize Main-Thread Work

Lighthouse flags "Minimize main-thread work" when total main-thread time exceeds 4 seconds. Common contributors beyond JavaScript: CSS parsing (from large stylesheets), layout calculations (from complex CSS selectors), and painting (from heavy visual effects like box-shadows on many elements).

Reduce DOM Size

Pages with more than 1,500 DOM nodes slow down JavaScript operations and layout calculations. WordPress page builders often generate 3,000–5,000+ nodes. Solutions include using simpler themes, reducing nested containers, and virtualizing long lists.

Does a 100 PageSpeed Score Actually Matter?

Yes and no. Here's a balanced perspective:

When It Matters

• SEO: Google uses page speed as a ranking signal. Sites scoring 90+ have measurably better rankings than sites scoring below 50, all else being equal.
• User experience: The optimizations required for a high score directly improve load times, interactivity, and visual stability.
• Conversions: every large retailer that has published on this has found the same direction — slower pages convert worse, and the effect is measurable in fractions of a second. The figures vary by industry, so measure your own funnel rather than borrowing someone else's number.
• Credibility: Fast sites feel professional. Slow sites feel broken, especially on mobile.

When It Doesn't Matter

• Chasing 100 at the expense of features: If removing an essential chat widget brings you from 95 to 100, keep the widget. User functionality matters more than a number.
• Lab vs. field data: The PageSpeed score is lab data. Google uses field data (Core Web Vitals) for ranking. A score of 85 with great field data beats 100 with poor real-user experience.
• Mobile vs. desktop: A desktop score of 100 is easy. A mobile score of 100 is much harder because Lighthouse simulates a mid-tier mobile device with a slow 4G connection. Focus on mobile first.

Aim for 90+ on mobile, and let 100 be the natural result of doing everything right. Don't sacrifice functionality for a perfect score — but don't use 'functionality' as an excuse for loading 2MB of unused JavaScript, either.

Frequently Asked Questions

Why does my PageSpeed score change between tests?

PageSpeed Insights runs Lighthouse on Google's servers, and conditions vary. Network latency, server load, and the specific machine running the test all introduce variability. Scores can fluctuate 5–10 points between runs. Run the test 3–5 times and use the median score for a reliable baseline.

Is the mobile score or desktop score more important?

Mobile. Google uses mobile-first indexing, meaning your mobile performance directly impacts rankings for all search results. The mobile test also simulates a throttled 4G connection and a mid-tier device, making it a much harder bar to clear. If you can score 90+ on mobile, desktop will follow naturally.

Can WordPress sites score 100?

Yes, but it requires a lightweight theme, minimal plugins, proper caching, and optimized images. Heavily customized WordPress sites with page builders, 20+ plugins, and unoptimized images typically score 30–60 on mobile. Stripping back to essentials and using a performance-focused theme can get you to 90–100.

How often should I test my PageSpeed score?

Test after every significant change (new plugin, theme update, content addition) and monthly as a baseline check. Set up Lighthouse CI in your deployment pipeline to catch regressions before they go live.

Do third-party scripts ruin my score?

They can. Google Analytics, Facebook Pixel, chat widgets, and ad scripts add JavaScript that increases TBT. The key is loading them after the page is interactive: use defer, async, or load them dynamically on user interaction. You can have third-party scripts and a high score — you just can't load them all synchronously in the <head>.