PageSpeed Insights: How to Read the Results and What to Fix First

Tired of staring at a PageSpeed Insights report and not knowing where to start? This is the PageSpeed Insights explained guide for technical SEOs. No fluff, just actionable advice.

What is PageSpeed Insights? (And Why Most People Read It Wrong)

Let’s be direct. Google’s PageSpeed Insights (PSI) is one of the most misunderstood tools in the SEO arsenal. It’s not just a vanity score generator to show your boss. It’s a diagnostic tool that combines real-world user data with a simulated lab test. This is the **PageSpeed Insights explained** guide for professionals who need to move beyond the score and get to the fixes.

The report is split into two critical, and often conflicting, data sources: Field Data and Lab Data. Understanding the difference is the first, and most important, step to using this tool effectively. One tells you what your actual users are experiencing; the other gives you a repeatable test environment for debugging.

Ignoring this distinction is why so many performance projects fail. You can chase a perfect lab score of 100 and still have a site that’s frustratingly slow for real people. Our goal here is to use the lab data to fix the field data—the data that actually matters for users and, by extension, for Google.

Lab vs. Field Data: PageSpeed Insights Explained in Two Parts

The top of your PSI report asks a simple question: ‘Discover what your real users are experiencing’. This is your Field Data, sourced from the Chrome User Experience Report (CrUX). It’s aggregated data from actual Chrome users who have opted-in to sharing it. This data is collected over the previous 28 days and represents a rolling average.

This is the ground truth. It’s what Google uses to evaluate your site’s performance for things like the Page Experience signal. If your Field Data is poor, you have a performance problem, regardless of what any other tool says. The catch? It’s a lagging indicator. You won’t see the results of your fixes here for up to a month.

Below that, you’ll find the Lab Data, which is a performance audit run by Lighthouse. This is a synthetic test run from a Google server on a throttled network connection and a simulated mid-tier mobile device. It’s a snapshot in time, a controlled experiment. This is where you test your changes and debug issues.

The Lab Data is immediate and actionable. You make a change, you re-run the test, you see the result. But it can be inconsistent and doesn’t always reflect the diverse network conditions and devices your real users have. Use it as your workshop, not your final report card.

Decoding the Metrics: LCP, INP, CLS, and the Rest of the Gang

The PSI report throws a lot of acronyms at you. Most of them boil down to measuring three core aspects of user experience: loading, interactivity, and visual stability. These are the Core Web Vitals (CWV).

For a deep dive, read our full Core Web Vitals guide. For now, here’s the cheat sheet on what you’re looking at in the report:

These metrics work together to paint a picture of the user’s journey. FCP tells you when the page starts to look like it’s loading, LCP tells you when the main content has likely loaded, TBT (and INP) tells you when you can actually interact with it, and CLS tells you if that experience is stable or jarring.

• Largest Contentful Paint (LCP): Loading performance. How long does it take for the largest image or text block to become visible? This is your user’s perception of speed.
• Interaction to Next Paint (INP): Responsiveness. How long does it take for the page to visually respond after a user clicks, taps, or types? This replaced FID as a Core Web Vital in March 2024.
• Cumulative Layout Shift (CLS): Visual Stability. Do elements on the page move around unexpectedly as it loads? This is a measure of user annoyance.
• First Contentful Paint (FCP): The point when the first piece of DOM content (text, image, etc.) is rendered. It’s the ‘something is happening’ metric.
• Total Blocking Time (TBT): A lab-only metric that measures the total time the main thread was blocked, preventing user input. It’s a strong proxy for what your INP will be in the field.

From Report to Roadmap: What to Actually Fix First

Scrolling past the metrics brings you to the ‘Opportunities’ and ‘Diagnostics’ sections. This is your prioritized to-do list, generated by the Lighthouse lab test. Don’t get overwhelmed; focus on the items with the largest estimated savings.

Your first priority should always be the critical rendering path. This is the sequence of steps a browser takes to convert HTML, CSS, and JavaScript into pixels on the screen. The biggest offenders here are render-blocking resources.

These are typically CSS and JavaScript files loaded synchronously in the “ of your HTML. The browser must download, parse, and execute these files before it can render any of the visible content below them. It’s like making a visitor wait in the lobby while you assemble all the furniture in the building.

You can fix this by deferring non-critical scripts. The `defer` attribute tells the browser to download the script in the background and execute it only after the HTML document has been fully parsed. For scripts that are completely independent, like a third-party analytics script, `async` can also be an option.

<!-- Bad: Render-blocking script in the head -->
<head>
  <script src="my-giant-script.js"></script>
</head>

<!-- Good: Script is deferred and non-blocking -->
<head>
  <script src="my-giant-script.js" defer></script>
</head>

The Usual Suspects: Images, Code Bloat, and Slow Servers

After you’ve dealt with render-blocking resources, the next biggest wins usually come from a few common areas. Images are almost always a problem. PSI will flag images that are not properly sized, poorly compressed, or served in legacy formats like JPEG instead of modern formats like AVIF or WebP.

Finding all these images across a large site can be a nightmare. This is where you can use a crawler like ScreamingCAT to audit your entire site. Configure it to crawl images and you can get a full list of every image file, its size, and where it’s located. Filter for anything over 100KB and you have an instant hit list.

Next is code bloat. The ‘Reduce unused JavaScript’ and ‘Reduce unused CSS’ opportunities can have a huge impact, but they’re often the most difficult to fix. This usually requires developer intervention to implement code-splitting, which breaks up large code bundles into smaller chunks that are loaded on demand.

Finally, look at your Time to First Byte (TTFB). This is a foundational metric. If your server is slow to respond to the initial request, every single metric that follows will be poor. No amount of front-end optimization can fix a slow backend. If you’re running a common platform, check out our guide on how to speed up WordPress performance, which covers caching, database optimization, and hosting.

Fixing these three areas—images, code, and server response time—will resolve the majority of issues flagged in a typical PageSpeed Insights report.

Thinking Beyond the Score: A Practical PageSpeed Insights Explained

Here’s the final, and perhaps most critical, piece of advice: stop chasing a score of 100. It’s a fool’s errand. A perfect score is often impossible on complex, dynamic websites with necessary third-party scripts for analytics, advertising, or customer support.

Your goal is not a green circle. Your goal is a fast experience for your users, confirmed by passing the Core Web Vitals assessment in your Field Data. A site with a score of 85 that passes CWV is better than a site with a score of 95 that fails.

Use PageSpeed Insights as the powerful diagnostic tool it is. Identify your primary page templates (homepage, product page, article page). Run them through PSI to get a baseline and a list of opportunities. Use a tool like ScreamingCAT to find where those issues exist at scale across your site.

Implement the high-impact fixes, focusing on the critical rendering path and asset optimization. Monitor your CrUX data over the next month to see your real-world scores improve. Rinse and repeat. Performance is not a project with an end date; it’s a process of continuous improvement.