Google PageSpeed Insights: Understanding Your Score and What to Fix

Lab Data vs Field Data: The Critical Distinction

PageSpeed Insights (PSI) shows you two completely different types of data, and confusing them leads to wrong conclusions. Understanding the difference is the most important thing to grasp before you start optimizing.

Lab data (Lighthouse) is a simulated test run in a controlled environment: a single Chrome instance with a throttled CPU (4x slowdown) and throttled network (simulated 4G). The Lighthouse Performance score (0-100) you see at the top of PSI comes from this lab test. Lab data is reproducible and precise — you can test before and after a change and see the impact immediately. But it doesn't represent your real users' experience.

Field data (Chrome User Experience Report / CrUX) comes from real Chrome users visiting your page over the past 28 days. This is what Google actually uses for ranking purposes. Field data shows your Core Web Vitals — LCP, INP, CLS, FCP, and TTFB — measured on real devices with real network conditions. If your page lacks sufficient real-user traffic (typically a few hundred visits in 28 days), PSI won't show field data and will display only lab data.

The Core Web Vitals Thresholds in PSI

PSI reports three Core Web Vitals that Google uses as ranking signals, plus additional metrics for context:

LCP (Largest Contentful Paint): Good = under 2.5s. Needs improvement = 2.5s–4.0s. Poor = over 4.0s. Measures when the largest visible element (usually a hero image or heading) finishes rendering.

INP (Interaction to Next Paint): Good = under 200ms. Needs improvement = 200ms–500ms. Poor = over 500ms. Measures responsiveness — how quickly the page responds to user interactions (clicks, taps, keyboard input).

CLS (Cumulative Layout Shift): Good = under 0.1. Needs improvement = 0.1–0.25. Poor = over 0.25. Measures unexpected layout shifts — content jumping around while the page loads.

Additional metrics in PSI: FCP (First Contentful Paint, good < 1.8s), TTFB (Time to First Byte, good < 800ms), and FID (deprecated, replaced by INP). Google's page experience ranking signal requires "good" scores on all three Core Web Vitals at the 75th percentile of real users.

How to Interpret Opportunities vs Diagnostics

PSI's Lighthouse section divides recommendations into two categories:

Opportunities are specific, estimated improvements — each shows the potential time saving if you fix the issue. "Properly size images" might show a saving of 2.1s. These are the highest-priority items to address because they have the most measurable impact on your score. Focus on opportunities first.

Diagnostics provide additional context about your page's performance characteristics but don't have direct time estimates. "Avoid an excessive DOM size" or "Minimize main-thread work" are diagnostics. They matter, but fixing them has a less direct correlation to score improvement than opportunities do.

Not all opportunities have equal real-world impact. An image opportunity showing "2.1s savings" is calculated under throttled lab conditions — the actual real-world improvement may be smaller (or larger on slower mobile devices). Prioritize image-related opportunities, render-blocking resource opportunities, and unused JavaScript — these typically have the highest real-world impact.

The Most Impactful PSI Audits to Fix First

1. Eliminate render-blocking resources: Scripts and stylesheets loaded in the document head that block HTML parsing. Defer or async non-critical JS; inline critical CSS. This commonly contributes 0.5–2s to FCP.

2. Properly size images / Use next-gen formats: Large, unoptimized images (especially the LCP image) are the most common cause of poor LCP scores. Convert JPEG/PNG to WebP or AVIF, and use srcset to serve appropriately sized images on mobile.

3. Reduce unused JavaScript: JavaScript bundles that include code not executed on the current page increase parse time and delay interactivity. Use dynamic imports, tree shaking, and route-based code splitting.

4. Preload LCP image: If your LCP element is an image, add <link rel="preload" as="image" href="..."> in your document head and fetchpriority="high" on the image element itself. This is often the fastest LCP improvement you can make.

Mobile vs Desktop Scores and Why Mobile Matters More

PSI tests both mobile and desktop. The mobile score uses a simulated mid-tier Android device with a 4x CPU slowdown and 4G throttling. The desktop test uses minimal throttling. This is why mobile scores are almost always significantly lower than desktop scores — the simulated device is much slower than a typical laptop.

Google uses mobile-first indexing, meaning it uses the mobile version of your page for ranking. More critically, Google's Core Web Vitals ranking signal is based on mobile CrUX data. A desktop score of 95 and a mobile score of 45 means your page has performance problems that matter for ranking. Always optimize for mobile first.

Running PSI from the Command Line

For automated testing, use the Lighthouse CLI or the PageSpeed Insights API. The Lighthouse CLI runs the same tests as PSI but locally:

Integrate PSI API calls into your CI/CD pipeline to catch performance regressions before they reach production. Set a threshold (e.g., Lighthouse performance score must not drop below 70) and fail the build if it's crossed.

Related Guides

• Core Web Vitals: Complete Guide to LCP, INP, and CLS
• LCP Optimization: How to Improve Largest Contentful Paint
• CLS Fix: How to Eliminate Cumulative Layout Shift
• INP Optimization: Improve Interaction to Next Paint
• TTFB Optimization: Reduce Time to First Byte
• Core Web Vitals Fix Guide: Step-by-Step for 2026