11 min read · Technical SEO · Last updated July 2026
Quick answer: PageSpeed Insights shows two types of data: field data (real user CrUX measurements that affect rankings) and lab data (Lighthouse simulation for debugging). Always check field data first — a high Lighthouse score does not guarantee your site passes Core Web Vitals in Google’s eyes.
Introduction
PageSpeed Insights (PSI) is the most used — and most misread — performance tool in SEO. Teams celebrate a 90+ performance score without checking whether their real users are passing Core Web Vitals. Other teams see a 45 score and panic, not realizing their field data shows all three metrics in the Good range.
The score number is almost meaningless for ranking purposes. What matters is your field data Core Web Vitals status: Good, Needs Improvement, or Poor. The Lighthouse score (the big number) is a lab metric. Google does not use it for ranking.
Understanding what PSI is showing you, and why the two data sections say different things, is one of the most practically useful skills in technical SEO.
What you’ll learn:
– What field data vs lab data means and which one Google uses
– How the Lighthouse performance score is calculated
– Which PSI diagnostics have the highest ranking impact
– How to prioritize your fix list from PSI output
– Why your PSI score varies between runs
– How to use PSI at scale for site-wide analysis
Table of Contents
- The Two Sections of PageSpeed Insights
- Field Data: What Google Uses for Ranking
- Lab Data: Your Debugging Tool
- How Lighthouse Calculates the Performance Score
- Core Web Vitals vs Other PSI Metrics
- Reading the Diagnostics Section
- Prioritizing Fixes from PSI Output
- Why PSI Scores Vary
- Running PSI at Scale
- Frequently Asked Questions
The Two Sections of PageSpeed Insights
When you run a URL through PSI (pagespeed.web.dev), you get two distinct sets of data. They look similar but come from completely different sources and serve completely different purposes.
Field Data section (at the top, showing “Field Data” or “Chrome User Experience Report”): Real measurements from real Chrome users who visited your URL over the past 28 days. This is CrUX data. It shows LCP, CLS, INP, and FCP as actual distribution percentiles — the percentage of users experiencing Good, Needs Improvement, and Poor values. This is what Google uses for ranking.
Lab Data section (showing “Lighthouse”): A simulated page load run by Google’s Lighthouse engine under controlled, standardized conditions. It uses a specific device emulation (Moto G Power), specific network throttling (4G equivalent), and a fresh cache. It shows the performance score (0-100) and individual metric measurements. This is for debugging.
The two sections will often tell different stories. A site with a Lighthouse score of 78 might have all three field data Core Web Vitals in Good status. A site with a Lighthouse score of 91 might have LCP failing in the field because real users in rural areas are on slow connections.
Field Data: What Google Uses for Ranking
Field data in PSI comes from CrUX — the Chrome User Experience Report. Chrome automatically collects performance metrics from opted-in Chrome users. Google aggregates this into 28-day rolling windows by URL and page group.
What field data shows:
– The 75th percentile value for each Core Web Vital (the threshold Google uses for pass/fail)
– A distribution bar showing what percentage of page views were Good, Needs Improvement, and Poor
What field data does not show:
– Data for URLs with insufficient traffic (a minimum number of Chrome sessions are required — roughly 1,000 per 28 days)
– Data for pages only accessed by logged-in users (private sessions are not included in CrUX)
– Desktop vs mobile breakdown (PSI shows the device type with more data, usually mobile)
If your URL shows “The Chrome User Experience Report does not have sufficient real-world speed data for this page,” it means your URL does not have enough CrUX data to report. In this case, only lab data is available. Use lab data as your proxy, but understand it is less reliable for predicting ranking impact.
Lab Data: Your Debugging Tool
Lab data runs Lighthouse against your URL from Google’s infrastructure. The simulation uses:
– Device: Moto G Power (a mid-range Android device)
– CPU throttling: 4x slowdown
– Network throttling: Slow 4G (10 Mbps download, 40ms RTT)
– Cache: Empty (cold cache load)
These conditions are designed to reflect a “typical” mobile user experience — not the fastest device on fiber, not the slowest device on 2G. This is why lab scores tend to be lower than what you experience on your office computer and why sites in markets with predominantly fast internet (Singapore, UAE urban centers) often have better field data than their lab scores suggest.
Lab metrics shown:
– First Contentful Paint (FCP): When the first content appears
– Largest Contentful Paint (LCP): Same as the Core Web Vital
– Total Blocking Time (TBT): Sum of long task blocking time during load (proxy for INP in lab)
– Cumulative Layout Shift (CLS): Same as the Core Web Vital
– Speed Index: How quickly content is visually populated (not a Core Web Vital)
PSI Score Breakdown Visual
Enter your Lighthouse metrics to see how each contributes to your overall performance score.
How Lighthouse Calculates the Performance Score
The Lighthouse performance score (0-100) is a weighted combination of five metrics:
| Metric | Weight | Good Threshold |
|---|---|---|
| First Contentful Paint | 10% | ≤ 1.8s |
| Speed Index | 10% | ≤ 3.4s |
| Largest Contentful Paint | 25% | ≤ 2.5s |
| Total Blocking Time | 30% | ≤ 200ms |
| Cumulative Layout Shift | 25% | ≤ 0.1 |
TBT carries the most weight (30%). This is intentional — Total Blocking Time is the lab-data proxy for interactivity, correlating strongly with INP in the field. A site with heavy JavaScript will have high TBT and a low Lighthouse score even if its images are optimized.
Each metric is scored on a curve (not linearly) and the weighted scores sum to 100. A site with perfect scores on four metrics but a terrible TBT can still score in the 50s overall.
This is why sites with lots of JavaScript frameworks, heavy page builders, and many plugins tend to score lower than static sites or well-optimized CMS sites, even with equivalent content delivery speeds.
Lab vs Field Data Comparison
See how the same site can show different data in lab vs field — and which one Google uses.
Reading the Diagnostics Section
Below the metrics, PSI shows Opportunities and Diagnostics. These are Lighthouse’s recommendations — things detected in the lab load that are likely contributing to poor scores.
Opportunities (marked with an estimated time saving) are the most actionable: they suggest specific changes and estimate the impact in seconds saved. Always start with the highest-estimated-saving opportunities.
Common high-impact opportunities:
– Eliminate render-blocking resources (often 1–4 seconds): Render-blocking JS and CSS in the <head>
– Properly size images (often 1–3 seconds): Images served larger than displayed
– Remove unused JavaScript (often 0.5–2 seconds): JS bundles with dead code
– Serve images in next-gen formats (often 0.5–2 seconds): JPEG/PNG instead of WebP
Diagnostics do not have estimated time savings but flag technical issues: missing image dimensions (CLS risk), oversized DOM trees (rendering performance), inefficient cache policies (repeat visit performance).
The “Passed Audits” section at the bottom lists what is already working. Check it to confirm your recent fixes registered.
Prioritizing Fixes from PSI Output
Not everything in PSI matters equally for rankings. Use this hierarchy:
-
Fix field data CWV failures first. If your field data shows LCP Poor, that is your top priority — not the diagnostics, not the score. The field data section tells you what is failing in the real world.
-
Then work through lab Opportunities by estimated savings. Tackle the highest-estimated-saving items in the Opportunities section. These are the lab-data issues most likely to also improve field data.
-
Use Diagnostics to catch future regressions. Image dimensions, cache policies, and DOM size issues are worth fixing even if they are not driving your field data failures — they prevent future problems.
-
Ignore cosmetic score improvements. A change that bumps your Lighthouse score from 78 to 84 but does not address a field data CWV failure has zero ranking impact.
Key takeaway: If your field data section shows all three Core Web Vitals are Good, your Lighthouse score is irrelevant for ranking purposes. Stop chasing the number.
Why PSI Scores Vary Between Runs
Running PSI twice on the same URL can produce scores 5–15 points apart. This is normal and expected.
Reasons for variance:
– Server load: Your server’s response time varies based on current traffic
– Third-party scripts: Ad scripts, A/B testing tools, and chat widgets vary in their load time between runs
– Google’s infrastructure: PSI runs from different Google data center locations
– In-flight requests: Other requests happening simultaneously on the Google testing infrastructure affect network simulation
To get a stable reading, run PSI 3–5 times and use the median. Or use Lighthouse in Chrome DevTools locally, which removes Google’s infrastructure variability.
Running PSI at Scale
For site-wide audits, the PageSpeed Insights API allows you to query multiple URLs programmatically:
curl "https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=https://example.com&strategy=mobile&key=YOUR_API_KEY"
Build a simple script to loop through your top 50 organic landing pages (from Google Search Console), run PSI on each, extract the field data CWV values, and output a CSV. This is faster and more comprehensive than manual URL-by-URL testing.
For ongoing monitoring, integrate the PSI API with a Google Sheet or use a dedicated CWV monitoring service that alerts you when field data degrades.
Frequently Asked Questions
What Lighthouse score should I target?
For ranking purposes, there is no score target — field data CWV status is what matters. For overall site quality, a score above 90 on mobile is a reasonable internal target, but do not sacrifice business functionality chasing it.
Why is my mobile PSI score so much lower than desktop?
PSI runs two separate Lighthouse audits — one with mobile emulation (Moto G Power, throttled 4G) and one with desktop settings (fast network, no CPU throttling). Mobile is harder because of CPU constraints and network throttling. Google’s ranking uses mobile field data for most sites.
Can I run PSI on pages behind a login?
The PSI API and web UI can only test publicly accessible URLs. For authenticated pages, use Lighthouse in Chrome DevTools (you can run it while logged in) or set up Lighthouse CI in your testing pipeline with authenticated sessions.
Does PSI test above-the-fold content specifically?
PSI and Lighthouse measure above-the-fold performance because LCP and FCP focus on initial viewport rendering. But CLS is measured across the full page load lifecycle, including below-the-fold content that shifts before the user scrolls to it.
How often should I run PSI audits?
Run PSI manually after any significant deployment. Set up automated monitoring (via PSI API or a tool like SpeedVitals, Treo, or DebugBear) to track trends weekly. Check Google Search Console’s Core Web Vitals report monthly.
Conclusion
PageSpeed Insights is most useful when you understand that it shows you two completely different things. The field data section is your ranking signal — the score that tells you whether your users are having Good, Needs Improvement, or Poor experiences on Core Web Vitals. The lab data section is your diagnostic tool — the detailed breakdown that helps you understand what is causing those field data values.
Always start with field data. If everything is Green (Good), stop worrying about the Lighthouse score. If something is Yellow or Red in field data, use the lab data Opportunities to pinpoint the cause and fix it.
Let Ignited Nepal Handle This
We run PSI audits across your full site, map field data failures to specific templates, and prioritize fixes by ranking impact — not by Lighthouse score aesthetics.
→ Request a Free Technical SEO Audit
Written by the Ignited Nepal SEO team. We build organic search systems for businesses across Nepal, Australia, UAE, USA, UK, and beyond. ignitednepal.com