How to Read Your PageSpeed Insights Report: A Plain-English Guide for Business Owners

You run your website through Google PageSpeed Insights, and it hands back a wall of coloured circles, acronyms and "opportunities." Some numbers are red, one says "Needs improvement," and it isn't obvious which of them actually matter to your customers — or to your search rankings.

This guide explains what the report measures, what a good result looks like, why the score moves every time you test, and which fixes usually make the biggest difference. No developer vocabulary required.

What PageSpeed Insights actually measures

PageSpeed Insights shows two different kinds of data on the same page, and mixing them up is the most common source of confusion.

• Lab data comes from Lighthouse, a test Google runs right now on a simulated device and network. It is one controlled run of one page, which makes it useful for diagnosing problems and checking whether a fix worked.
• Field data — the "Discover what your real users are experiencing" section — comes from the Chrome User Experience Report: how real Chrome users actually experienced your page over the previous 28 days. This is the data Google uses when it assesses Core Web Vitals.

Each report has a Mobile and a Desktop tab. Mobile is tested on a slower simulated phone and connection, so it almost always scores lower. For most businesses it is also where the majority of visitors arrive, so start there.

The four scores at the top

The lab report opens with four scores out of 100: Performance, Accessibility, Best Practices and SEO. Google colours them the same way every time:

• 90–100 (green): good
• 50–89 (orange): needs improvement
• 0–49 (red): poor

Accessibility, Best Practices and SEO are checklists — they stay put until you change the page. Performance is the one that moves between runs, and it is built from the lab measurements below.

Core Web Vitals, in plain English

Core Web Vitals are three measurements of how a page feels to a real visitor. Google publishes a threshold for each, judged on the 75th percentile of visits — so at least three out of four visits need to be "good" for the page to pass.

Largest Contentful Paint (LCP) — does the main content show up quickly?

LCP is the time until the biggest thing on screen — usually a hero image or headline — has loaded. Good is 2.5 seconds or less; over 4 seconds is poor. A slow LCP is what people describe as "the site takes ages to load."

Interaction to Next Paint (INP) — does the page respond when I tap?

INP measures how quickly the page visibly reacts after someone clicks, taps or types. Good is 200 milliseconds or less; over 500 milliseconds is poor. INP replaced First Input Delay as a Core Web Vital in March 2024. A poor INP feels like buttons that "don't work" the first time.

Cumulative Layout Shift (CLS) — does the page stay still?

CLS measures how much content jumps around while the page loads — the button that moves just as you go to tap it. It is a score rather than a time: good is 0.1 or less; over 0.25 is poor.

The other numbers in the lab report

• First Contentful Paint (FCP): when anything first appears on screen. Good is 1.8 seconds or less.
• Total Blocking Time (TBT): how long the page was too busy running scripts to respond. It is the lab stand-in for INP, because a simulated test can't tap buttons. Good is 200 milliseconds or less.
• Speed Index: how quickly the visible part of the page fills in overall.

"There is insufficient real-user data for this URL"

If the field data section is empty, your page simply doesn't get enough Chrome visits for Google to report on it. That is normal for smaller sites and individual pages, and it is not a penalty. Use the lab results to find and fix problems; the field data will appear as your traffic grows.

Why your score changes every time you run it

Run the same page three times and you may get three different Performance scores. Network conditions, the load on your server at that moment, and third-party scripts such as chat widgets, ad tags and analytics can all shift a single lab run by several points.

So don't chase one number. Run the test two or three times, look at the typical result, and compare like with like — mobile to mobile, same page — before and after a change. When you have field data, treat it as the final word: it reflects your real visitors, not a simulation.

The fixes that usually help most

The "Opportunities" and "Diagnostics" sections list issues for your specific page, roughly ordered by how much time they could save. On most business websites the biggest wins come from the same handful of changes:

• Right-size and compress images. Serve images no larger than they are displayed, in modern formats such as WebP or AVIF. Oversized hero images are the most common cause of a slow LCP.
• Don't lazy-load the main image. Lazy-load images further down the page, but load the hero image straight away — ideally preloaded — so LCP isn't delayed.
• Reserve space for everything that loads late. Give images, videos, embeds and banners a width and height (or an aspect ratio) so the page doesn't jump when they arrive. This is the main fix for CLS.
• Audit third-party scripts. Every chat widget, tracking pixel and embedded feed costs time. Remove what you no longer use, and load the rest after the page is interactive.
• Defer non-essential JavaScript. Scripts that aren't needed to show the first screen shouldn't block it. Breaking up long-running scripts is what improves TBT and INP.
• Speed up the server's first response. Page caching, a content delivery network (CDN) and adequate hosting shorten the wait before anything can load at all.
• Keep web fonts lean. Load only the weights you use, and use font-display: swap so text shows while fonts download.

Where to start

You don't need a perfect 100. Aim for the Core Web Vitals thresholds on the pages that bring in business — your home page, your top landing pages and your main service or product pages — starting with mobile. Fix one thing at a time and re-test after each change, so you know what actually helped.

Run it from your DMB-One dashboard

You can run these tests with Google's own tool at pagespeed.web.dev. If you use DMB-One, connect PageSpeed Insights under Connections to test any page on mobile or desktop from your dashboard, with the Lighthouse scores, lab measurements and real-user Core Web Vitals shown side by side — so tracking your site's speed becomes part of your regular marketing review rather than a one-off check.