A Complete Guide to Improving Your Google PageSpeed Score
A low PageSpeed Insights score is frustrating precisely because the report gives you dozens of suggestions without much sense of priority. Some fixes move the needle enormously; others barely register. Here's how to actually prioritize your effort and get real improvement, not just chase a number.
Understand What's Actually Being Measured
PageSpeed Insights scores are built from several weighted metrics, primarily: Largest Contentful Paint (LCP), Total Blocking Time (TBT), Cumulative Layout Shift (CLS), and First Contentful Paint (FCP). TBT and LCP carry the most weight in the scoring formula, so if you're only going to fix a couple of things, start there — a small CLS fix won't move your score nearly as much as reducing your JavaScript execution time.
Reduce JavaScript Execution Time
Heavy JavaScript is the single most common cause of poor scores on modern websites. This usually comes from bloated third-party scripts — analytics tools, chat widgets, ad scripts, tracking pixels — that all execute on page load whether the user needs them immediately or not.
- Audit every third-party script and remove ones you're not actually using.
- Defer non-critical scripts so they load after the main content renders.
- Load chat widgets, popups, and similar tools only after user interaction (scroll, click, or a short delay) rather than immediately.
- Split large JavaScript bundles so the browser only downloads what's needed for the current page.
Optimize Images Properly
Unoptimized images remain one of the biggest, easiest wins available:
- Convert to WebP or AVIF format.
- Serve responsive images sized appropriately for different screen widths using
srcset. - Lazy-load images below the fold (but not your LCP element — see our LCP guide for that nuance).
- Compress aggressively; most visitors can't tell the difference between 100% and 80% JPEG quality, but the file size difference can be substantial.
Eliminate Render-Blocking Resources
CSS and synchronous JavaScript loaded in the <head> block the browser from painting anything until they're downloaded and processed:
- Inline critical above-the-fold CSS directly in the HTML.
- Load the rest of your CSS asynchronously or defer it.
- Add
async/deferattributes to script tags that don't need to run immediately.
Minimize Main-Thread Work
Total Blocking Time measures how long the browser's main thread is too busy to respond to user input. Heavy JavaScript parsing, style recalculations, and large DOM sizes all contribute. Simplifying your DOM structure (fewer nested elements, less redundant markup) and reducing JS execution both help here directly.
Enable Text Compression and Caching
Small technical wins that add up:
- Enable gzip or Brotli compression on your server for all text-based responses.
- Set long cache lifetimes for static assets (CSS, JS, images) that don't change frequently, using proper
Cache-Controlheaders. - Use a CDN to reduce latency for visitors far from your origin server.
Fix Layout Shift Issues
Even though CLS carries less weight in the score than LCP/TBT, it's often an easy fix: always specify width and height attributes on images and video embeds so the browser reserves space before the asset loads, and avoid injecting content (ads, banners) above existing content without reserving space for it first.
Re-Test in Context, Not Just Once
PageSpeed scores can vary run to run due to network conditions and server load variability. Test multiple times, and pay more attention to the field data (real user data from Chrome UX Report, shown as "Discover what your real users are experiencing") than the lab data alone, since lab tests are a single simulated run and can be misleading.
The Bottom Line
Chasing a perfect 100 score is usually not worth the effort-to-benefit ratio. Focus on the metrics that carry the most weight — JavaScript execution time and render-blocking resources — and you'll typically see the biggest score jump from the smallest number of changes.