Open PageSpeed Insights for the first time and the big coloured circle can feel like a verdict on your whole site. It is not. It is one lab test, run on one simulated phone, and it is most useful as a to-do list.
This guide explains how that score is worked out, and then walks through the fixes in the order that usually pays off most: images, JavaScript, CSS, the server, fonts and layout shifts. There are notes for WordPress sites along the way.
By the ClearAITools team · Last updated October 26, 2026
Quick answer: the PageSpeed Insights score is a Lighthouse lab score from 0 to 100, and 90 or above counts as good. Three metrics make up 80% of it: Total Blocking Time (30%), Largest Contentful Paint (25%) and Cumulative Layout Shift (25%). To raise it, shrink and prioritise your main image, cut or delay JavaScript, reserve space so nothing jumps, and make sure your server and caching are fast.
What your PageSpeed Insights score really measures
A PageSpeed Insights report has two parts, and people often mix them up. The top section, “Discover what your real users are experiencing”, shows field data collected from real Chrome visitors over roughly the last 28 days. The big circle below it is the lab score, produced by Lighthouse loading your page once in a controlled, throttled environment.
The lab score is colour coded: 0 to 49 is poor, 50 to 89 needs improvement, and 90 to 100 is good. It is a weighted average of five metrics, and the weights changed in Lighthouse 10, so older guides that list different numbers are out of date.
| Metric | What it tells you | Weight in the score |
|---|---|---|
| Total Blocking Time (TBT) | How long scripts keep the page from responding while it loads | 30% |
| Largest Contentful Paint (LCP) | When the biggest visible element appears | 25% |
| Cumulative Layout Shift (CLS) | How much the layout jumps around | 25% |
| First Contentful Paint (FCP) | When anything first appears | 10% |
| Speed Index | How quickly the visible area fills in | 10% |
Time to Interactive (TTI) was removed in Lighthouse 10, and its weight went to CLS, which used to count for 15%. Notice too that INP, the responsiveness metric in Core Web Vitals, is not in the lab score. Lighthouse uses TBT as a stand-in for it. If you want the full story on those three metrics, read our Core Web Vitals guide.
One more thing to keep in perspective: Google’s ranking systems look at real-user Core Web Vitals, not at your lab score. The lab score is a diagnostic tool. Use it to find problems, and check the field data and Search Console to see whether real visitors are affected.
Before you change anything
- Test the mobile tab first. It simulates a slower phone and network, so it is the tougher and more honest test.
- Run the test three times and note the range. Scores wobble from run to run.
- Scroll to the diagnostics and write down which of the five metrics is weakest, and what the “Largest Contentful Paint element” is.
- Change one thing at a time, then test again, so you know what actually helped.
Step 1: images (LCP and FCP)
Images are usually the easiest place to start, because the main image is often the LCP element. If a sluggish hero image is what you see in the report, fix this first.
Use modern formats at the right size
Convert photos to WebP or AVIF, compress them, and export them at the size they are shown. A 2400-pixel image in a 600-pixel slot is wasted download. Use srcset so phones receive a smaller file. If you need a refresher, see our WebP guide.
Prioritise the main image, lazy-load the rest
Tell the browser which image matters most, and don’t lazy-load it. Images further down the page should be lazy-loaded.
<!-- The main image at the top: load it early -->
<img src="hero.webp" width="1200" height="630" alt="Describe the image"
fetchpriority="high" loading="eager">
<!-- Images further down: load them when needed -->
<img src="section.webp" width="800" height="400" alt="Describe the image"
loading="lazy" decoding="async">If the main image is set in CSS as a background, add a preload hint in the <head> so the browser does not find it late:
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">Always give images dimensions
Set width and height on every image. It lets the browser reserve the space before the file arrives, which protects your CLS score.
Step 2: JavaScript (TBT, the heaviest metric)
Total Blocking Time carries the biggest weight, and scripts are what cause it. This is where many sites lose the most points, especially sites with lots of plugins, ads and widgets.
- Remove what you do not use. Deactivating an unused plugin or script is better than optimising it.
- Find unused code. In Chrome DevTools, open the Coverage panel to see how much of each script actually runs on the page.
- Don’t block rendering. Add
deferto scripts that need the page, andasyncto scripts that stand alone. - Handle third-party scripts carefully. Analytics, chat widgets, tag managers and ad scripts add up fast. Load the ones you can after the page is usable.
- Split big bundles. If you build your own front end, load heavy components only when they are needed.
<!-- Blocks rendering -->
<script src="app.js"></script>
<!-- Does not block: runs after the page is parsed, in order -->
<script src="app.js" defer></script>
<!-- Does not block: runs as soon as it arrives, order not guaranteed -->
<script src="widget.js" async></script>// Heavy component, loaded only when it is needed (React example)
const HeavyChart = React.lazy(() => import('./HeavyChart'));If a single task keeps the browser busy for a long time, split it into smaller pieces so the page can respond in between:
async function processAll(items) {
for (let i = 0; i < items.length; i++) {
handle(items[i]);
if (i % 50 === 0) await new Promise(r => setTimeout(r, 0)); // let the browser breathe
}
}Step 3: CSS (FCP and LCP)
- Remove unused CSS. The same Coverage panel shows how much of each stylesheet is used. Tools such as PurgeCSS can strip the rest from your own builds.
- Inline the critical CSS. The styles for what appears first can go directly in the page, and the rest can load without blocking. On WordPress, a performance plugin can generate this for you.
- Minify. Remove whitespace and comments. Most build tools and caching plugins do this with one switch.
- Avoid
@import. It makes the browser fetch files one after another.
<!-- Load a large stylesheet without blocking the first paint -->
<link rel="preload" href="styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="styles.css"></noscript>Step 4: server and network (LCP and FCP)
A slow server delays everything that follows. These are the settings that matter most:
- Page caching. Serving a saved copy of the page is much faster than building it on every visit.
- Compression. Brotli usually compresses text files a little better than GZIP. Most hosts and CDNs enable one or both.
- A CDN. It serves files from a location near the visitor. Cloudflare’s free plan is a common starting point.
- Modern protocols. HTTP/2 and HTTP/3 let the browser load many files at once. Your host or CDN normally controls this.
- Cache headers. Give files that rarely change (images, fonts, versioned CSS and JS) a long cache lifetime, and let HTML revalidate.
# Static files that never change: cache for a year
Cache-Control: public, max-age=31536000, immutable
# HTML pages: always check for a fresh copy
Cache-Control: no-cacheStep 5: fonts
Web fonts can delay text and cause layout shifts. Use as few families and weights as you can, host them yourself if you can, preload the main one, and let the browser show fallback text while the font loads.
<link rel="preload" href="/fonts/main.woff2" as="font" type="font/woff2" crossorigin>
@font-face {
font-family: "Main Font";
src: url("/fonts/main.woff2") format("woff2");
font-display: swap;
}Step 6: layout shifts (CLS is a quarter of the score)
Since the 2023 weighting change, CLS counts for 25% of the lab score, so it is worth a look even if your page already loads quickly. Give images and videos fixed dimensions, reserve space for ads and embeds, and avoid inserting banners above content that has already loaded. A fixed-height slot is often all an ad needs:
.ad-slot { min-height: 280px; }Shortcuts for WordPress sites
- Install one good caching plugin and turn on page caching, minification and lazy loading.
- Use an image optimisation plugin, or convert and resize images before you upload them.
- Deactivate and delete plugins you don’t use. Each one can add scripts and styles to every page.
- Keep a lightweight theme, and be careful with heavy sliders, page builders and animation libraries.
- Be cautious with “Delay JavaScript” options. They can lift the score quickly but may break interactive tools, so test every important page afterwards.
Which fix first?
Gains depend entirely on your site, so don’t trust anyone who promises an exact number of points. This table shows what each fix mainly improves and how much work it usually takes.
| Fix | Mainly improves | Effort |
|---|---|---|
| Compress and resize images, use WebP | LCP, FCP | Low |
| Prioritise the main image, lazy-load the rest | LCP | Low |
| Add width and height to images, reserve ad space | CLS | Low |
| Remove unused plugins and scripts | TBT | Low to medium |
| Defer or delay non-essential JavaScript | TBT, FCP | Medium |
| Page caching and a CDN | FCP, LCP | Medium |
| Remove unused CSS and inline critical CSS | FCP, LCP | Medium to high |
| Self-host and preload fonts | FCP, CLS | Medium |
Checklist
- Run PageSpeed Insights on mobile three times and note the weakest metric.
- Find out what your LCP element is.
- Compress, resize and convert images to WebP.
- Preload the main image and keep it out of lazy loading.
- Set width and height on every image.
- Remove unused plugins and scripts, then defer what remains.
- Turn on page caching, compression and a CDN.
- Reserve space for ads and embeds.
- Test again, and check the field data and Search Console after a few weeks.
Frequently asked questions
Do I need a score of 90 or more?
No. A score in the green is a good target, but what matters most is passing the Core Web Vitals for real visitors. Some pages with heavy but necessary features will never reach 100.
Why is my mobile score lower than my desktop score?
The mobile test simulates a slower processor and network, so scripts and large images hurt more. Fix mobile first, and desktop usually follows.
Why does my score change between tests?
Lab tests vary with server load, network conditions and background tasks. Run the test a few times and look at the trend instead of a single number.
Does the PageSpeed score affect my Google ranking?
The score itself is a diagnostic. Google’s ranking systems use real-user Core Web Vitals data, and content relevance still matters more than a perfect result. Speed helps because it keeps visitors on your page.
How long until improvements show up in Search Console?
Lab results change right away, but field data is gathered over about 28 days, so give it a few weeks.
Keep reading: Core Web Vitals explained · WebP guide: how to convert images