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:
| Metric | Weight | What It Measures | Good Threshold |
|---|---|---|---|
| First Contentful Paint (FCP) | 10% | Time until first content appears | ≤ 1.8s |
| Largest Contentful Paint (LCP) | 25% | Time until largest element renders | ≤ 2.5s |
| Total Blocking Time (TBT) | 30% | Sum of blocking time from long tasks | ≤ 200ms |
| Cumulative Layout Shift (CLS) | 25% | Visual stability score | ≤ 0.1 |
| Speed Index (SI) | 10% | How quickly content is visually complete | ≤ 3.4s |
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
Serverlys Tip: Our cloud hosting includes NVMe SSDs, LiteSpeed servers, PHP 8.3, and HTTP/3 out of the box. Most sites see a 15–25 point PageSpeed improvement just from switching to faster hosting, before any code changes.
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:
| Format | Typical File Size (vs. JPEG) | Browser Support | Best For |
|---|---|---|---|
| JPEG | Baseline | 100% | Legacy fallback |
| WebP | 25–35% smaller | 97%+ | Photos, general use |
| AVIF | 40–50% smaller | 92%+ | Photos, maximum compression |
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:
- Set explicit dimensions on images and videos. Always include width and height attributes.
- Reserve space for ads. Use min-height on ad containers.
- Preload web fonts. Use
<link rel="preload" as="font">and setfont-display: swapwith matched fallback metrics. - Avoid 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:
| Asset Type | Cache Duration | Strategy |
|---|---|---|
| CSS/JS (versioned) | 1 year | Cache-bust with filename hash |
| Images | 1 year | Use content-based URLs |
| Fonts | 1 year | Self-host with versioned filenames |
| HTML | No cache or short (5 min) | Always fresh content |
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.
Serverlys Tip: Getting to 100 requires both fast hosting and optimized code. Our cloud hosting handles the server side — NVMe storage, LiteSpeed caching, HTTP/3, and built-in CDN. You focus on your code; we handle the infrastructure. Compare our plans.
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: Amazon found that every 100ms of latency cost them 1% in sales. Walmart found that every 1-second improvement in load time increased conversions by 2%.
- 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>.