PageSpeed Insights Explained: How to Read Your Report

You ran your site through PageSpeed Insights, got a red or orange number, and now you are looking at a long list of warnings you don’t fully understand. You are not alone. The good news: you don’t have to read the whole report. In my experience, only a few parts of it really matter for SEO and for your visitors.

Here is the short answer. PageSpeed Insights shows two kinds of data. Field data is how real Chrome users experienced your page over the last 28 days. Lab data is one test run in a simulated setup. Google’s Core Web Vitals and page experience signals use the field data, not the 0–100 score. In this guide I walk through every section of the report and show you what to fix first.

What PageSpeed Insights Actually Measures

PageSpeed Insights (PSI) is Google’s free tool for checking how fast and stable a page feels. You paste in a URL and it gives you a report for mobile and a report for desktop. Each one sits on its own tab at the top.

The tool pulls together two separate sources:

• The Chrome User Experience Report (CrUX). This is data from real Chrome users who opted in to share usage statistics. It is the “field data” part of the report.
• Lighthouse. This is Google’s open-source testing tool. PSI runs it once on your page from Google’s servers. It is the “lab data” part, and it produces the performance score.

Most confusion about PSI comes from mixing these two up. They answer different questions. Field data answers “How did real people experience this page?” Lab data answers “What happens when we load this page once under fixed test conditions, and what could be slowing it down?”

The Two Main Parts of a PageSpeed Insights Report

Since the redesign in late 2021, the report is split into two clear blocks. The top block is titled “Discover what your real users are experiencing”. That is your field data. The lower block is titled “Diagnose performance issues”. That is your Lighthouse lab test.

When I open a report, I always read the top block first. If the field data looks fine, the lab warnings are a nice-to-have list, not an emergency. If the field data fails, the lab section helps me find out why.

Mobile and Desktop Tabs

PSI opens on the mobile tab by default. Mobile results are almost always worse, because the lab test simulates a mid-range phone on a slow mobile connection. Don’t panic when your mobile score is far below your desktop score. That gap is normal.

Still, check both. Google started using page experience as a ranking signal on mobile in 2021, and it extended page experience to desktop in early 2022. So both versions of your page now count.

How to Read the Field Data Section

This is the part of the report that matters most for SEO. It shows how real Chrome visitors experienced your page over the previous 28 days.

The Core Web Vitals Assessment

At the top you will see a line that says “Core Web Vitals Assessment” followed by Passed or Failed. Core Web Vitals are three metrics Google uses to judge page experience:

• Largest Contentful Paint (LCP): how long it takes for the biggest piece of content, usually a main image or headline block, to show up. Good is 2.5 seconds or less. Poor is over 4 seconds.
• First Input Delay (FID): how long the browser takes to respond when someone first taps or clicks. Good is 100 milliseconds or less. Poor is over 300 milliseconds.
• Cumulative Layout Shift (CLS): how much the page jumps around while it loads. Good is 0.1 or less. Poor is over 0.25.

To pass, your page needs a “good” result for these metrics at the 75th percentile. That means at least three out of four visits had a good experience. Google explains why it picked this cut-off in its write-up on how the Core Web Vitals thresholds were set.

The Coloured Bars

Under each metric there is a bar split into green, orange and red. It shows the share of real visits that were good, needed improvement or were poor. The number above the bar is the 75th percentile value.

For example, an LCP of 3.1 s means a quarter of visits waited 3.1 seconds or longer for the main content. That sits in the “needs improvement” range. I find the bars more useful than the single number. A page with 70% green and 20% red has a different problem from a page with 70% green and 25% orange.

Other Field Metrics

You will also see First Contentful Paint (FCP), which is when the first text or image appears. It is helpful but not a Core Web Vital. The report may also show experimental metrics such as Interaction to Next Paint (INP) and Time to First Byte (TTFB). These don’t affect the pass or fail result today. I glance at them because a slow TTFB often explains a slow LCP.

This URL vs Origin

There are two toggles in the field data block: “This URL” and “Origin”. “This URL” shows data for the exact page you tested. “Origin” shows data for your whole domain combined.

If a page doesn’t get enough Chrome traffic, PSI can’t show URL-level data. It may fall back to origin data or show “No Data”. This is common for new pages and small sites. It doesn’t mean anything is wrong. It just means there aren’t enough visits for Google to report on that page alone.

How to Read the Lab Data Section

The “Diagnose performance issues” block is a single Lighthouse test. It runs in a controlled setup with a simulated device and throttled network. Because it is one test, the result can change from run to run.

The Performance Score

The big number in a circle is the Lighthouse performance score, from 0 to 100. The colours work like this:

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

Here is the part many people miss. Google Search does not use this score for ranking. The page experience signals use Core Web Vitals from field data. The score is a lab summary that helps developers spot problems. Chasing a perfect 100 on mobile is rarely worth the effort.

The Lab Metrics

The score is a weighted mix of six lab metrics shown below it:

Notice that First Input Delay is not in the lab list. FID needs a real person to click something, so a lab test can’t measure it. Total Blocking Time (TBT) is the closest lab stand-in. If your field FID is poor, look at TBT in the lab section. It usually points at heavy JavaScript.

Also notice that TBT and LCP together make up more than half of the score. In my experience, those two metrics explain most low mobile scores.

Opportunities

Opportunities are suggestions with an estimated saving next to them, such as “Reduce unused JavaScript” or “Properly size images”. The estimate shows how much faster the page could load if you fixed that item.

Treat those savings as rough guides, not promises. They are calculated from the single lab run. Still, the list is sorted by estimated impact, so the top few items are usually where I start.

Diagnostics

Diagnostics give more detail about how your page is built. Examples include “Avoid an excessive DOM size”, “Reduce JavaScript execution time” and “Avoid large layout shifts”. They don’t have a time saving next to them, but they often explain why an opportunity exists.

Two diagnostics I always open are “Largest Contentful Paint element” and “Avoid large layout shifts”. The first tells you exactly which element is your LCP. The second lists the elements that moved. Those two lines alone often tell you what to fix.

The Metric Filter and Treemap

Above the opportunities you’ll see “Show audits relevant to:” with buttons for FCP, LCP, TBT and CLS. Click one and the list filters down to issues that affect that metric. This is the fastest way to focus. If your field data fails on CLS, click CLS and work only on that list.

There is also a “View Treemap” button. It opens a visual map of your JavaScript files by size and shows how much of each file went unused. It is a handy way to spot one large plugin or third-party script that drags everything down.

Why Your PageSpeed Insights Score Changes Every Time

Run the same URL three times and you may get three different scores. That is normal. Common reasons include:

• Server response time. Your hosting may be slower at some moments than others.
• Third-party scripts. Ads, chat widgets and tag managers can load different amounts of code each time.
• A/B tests and personalised content. Different visitors, including the test bot, may get different versions of the page.
• Network conditions between Google’s test servers and your server.

My rule of thumb: run the test three times and look at the middle result. Don’t celebrate or worry over a change of a few points. Field data is far steadier, because it is built from many real visits over 28 days.

Why Field Data and Lab Data Disagree

It is common to see a red lab score next to a “Passed” field assessment. The opposite can happen too. Here is why:

• The lab test uses one simulated phone and one slow connection. Your real visitors may have faster phones and better networks.
• The lab loads the page with an empty cache. Returning visitors often have files cached already.
• Real users scroll, click and interact. Layout shifts that happen after load, like a late banner, show up in field CLS but may not appear in the lab.
• Field data covers 28 days. A fix you made yesterday shows up in the lab right away, but takes weeks to show fully in the field data.

When they disagree, I trust the field data for “Do I have a problem?” and use the lab data for “Where is the problem coming from?”

How to Use the Report to Decide What to Fix

Here is the order I work in when I open a PageSpeed Insights report for a client page.

1. Check the Core Web Vitals assessment on the mobile tab. Note which metric fails: LCP, FID or CLS.
2. Switch to Origin if there’s no URL data. This tells you if the issue is site-wide, which usually means a template, theme or hosting problem.
3. Use the metric filter in the lab section. Click the button for the failing metric. Use TBT if FID is the problem.
4. Find the LCP element or the shifting elements in Diagnostics. This turns a vague warning into a specific image, font or block.
5. Fix the top two or three items for that metric. Hand them to your developer with the exact element and file names from the report.
6. Re-test in the lab to confirm the change made a difference.
7. Wait for the field data to catch up. Check again after about four weeks, or watch the Core Web Vitals report in Search Console.

Common Fixes by Metric

These are the fixes I see work most often. They are not every possible fix, but they cover the usual causes.

• Slow LCP: compress and resize the hero image, serve it in a modern format like WebP, don’t lazy-load the main image above the fold, and improve server response time with better hosting, caching or a CDN (content delivery network).
• Poor FID or high TBT: remove unused plugins and scripts, delay non-essential third-party code like chat widgets, and break up long JavaScript tasks.
• High CLS: add width and height to images and videos, reserve space for ads and embeds, and avoid inserting banners above existing content after the page loads.

I usually see CLS problems on sites that added a cookie banner or ad slot without reserving space. LCP problems on WordPress sites often come down to a huge slider image and a slow host.

PageSpeed Insights vs the Search Console Core Web Vitals Report

PageSpeed Insights tests one URL at a time. The Core Web Vitals report in Search Console uses the same CrUX field data, but groups similar URLs together across your whole site. It shows which groups are good, need improvement or are poor.

I use them together. Search Console tells me which page groups have problems. PSI lets me open one example URL from that group and see the details. If you are doing a broader technical review, the Mobile Usability report is worth checking at the same time, since many slow mobile pages also have tap target or viewport issues.

The Other Lighthouse Categories

Scroll to the bottom of the lab section and you’ll see scores for Accessibility, Best Practices and SEO. These are also from Lighthouse.

The SEO score checks basics like a title tag, meta description, crawlable links, a valid robots.txt and a viewport tag. A score of 100 here means the basics are in place. It doesn’t mean the page will rank. I use it as a quick sanity check, nothing more.

Common Mistakes When Reading a PageSpeed Insights Report

• Chasing a perfect score. A mobile score of 100 is rare on real business sites with analytics, fonts and forms. Aim to pass Core Web Vitals in the field.
• Testing only the homepage. Your product, category and blog templates may behave very differently. Test one URL from each main template.
• Ignoring the origin data. If the whole origin fails, fixing one page won’t move the needle much.
• Treating every opportunity as urgent. Some suggestions save a few milliseconds. Focus on items tied to your failing metric.
• Expecting instant field results. The 28-day window means real gains show up slowly.

How Much Page Speed Matters for SEO

Speed and Core Web Vitals are part of Google’s page experience signals. They matter, but they are not the main thing. Google has said many times that relevant, helpful content still comes first. A fast page with weak content won’t outrank a slower page that answers the question better.

My honest view: page speed is often a tie-breaker in search, and a much bigger factor for conversions. Visitors leave slow pages. So even if your rankings don’t move after a fix, your sales or leads may. That makes speed work worth it. Just keep it in proportion with your other priorities, like the ones in my SEO checklist for 2022.

Conclusion

PageSpeed Insights is much less scary once you know where to look. Start with the field data and the Core Web Vitals assessment, because that is what Google uses. Then use the lab data, the metric filter and the diagnostics to find the exact elements slowing your page down. Don’t lose sleep over the 0–100 score.

Your next step: open the Core Web Vitals report in Search Console, pick one failing URL group, and run a sample page through PageSpeed Insights using the steps above. Fix the top items for the failing metric, then check back in about a month.