What is PageSpeed Insights (PSI)?

What is PageSpeed Insights (PSI)?

PageSpeed Insights (PSI) is Google's free web performance analysis tool. Enter any URL at pagespeed.web.dev and PSI returns a performance scorecard combining two distinct data sources: lab data (a fresh synthetic Lighthouse audit run from a Google data center) and field data (real-user metrics from the Chrome User Experience Report covering the past 28 days). The tool then surfaces specific, prioritized recommendations for improving page speed.

PSI is the most-cited performance tool in SEO discussions for one reason: it's the public face of Google's Core Web Vitals program. The scores you see in PSI map directly to the signals Google uses for ranking. "Did PSI improve?" is the question that ends most performance debates.

The two halves of PSI: lab data vs. field data

Understanding PSI requires understanding the two completely different data types it shows. They answer different questions.

Field data (CrUX) — "how do real users experience this page?"

The Chrome User Experience Report (CrUX) is a public dataset of anonymized performance metrics collected from real Chrome users (those who've opted in to syncing browser history). PSI shows the 75th-percentile values across the past 28 days for that URL or origin.

The four CrUX metrics in PSI:

• LCP (Largest Contentful Paint) — when the largest above-fold element renders. Good: ≤2.5s.
• INP (Interaction to Next Paint) — responsiveness to user input. Replaced FID in March 2024. Good: ≤200ms.
• CLS (Cumulative Layout Shift) — visual stability. Good: ≤0.1.
• FCP (First Contentful Paint) and TTFB (Time to First Byte) — diagnostic, not pass/fail.

Field data is what Google uses for the Core Web Vitals ranking signal. If field data is missing (low traffic page), Google falls back to origin-level data, then no signal at all.

Lab data (Lighthouse) — "how fast can this page load in ideal conditions?"

Lab data comes from a fresh Lighthouse audit on a simulated mobile or desktop device with throttled network. It's reproducible (same conditions every run) and diagnostic (Lighthouse generates a list of opportunities).

The lab metrics in PSI:

• FCP, LCP, CLS — same metrics, but measured in lab conditions.
• TBT (Total Blocking Time) — proxy for INP. Time the main thread was blocked during page load.
• Speed Index — how quickly visible content paints during load.
• Performance Score (0-100) — weighted average of the lab metrics.

The PSI score: how it's calculated

The Performance score is a weighted combination of lab metrics with these weights (as of Lighthouse 10):

• LCP: 25%
• TBT: 30%
• CLS: 25%
• FCP: 10%
• Speed Index: 10%

Each metric is mapped to a 0-100 score using a log-normal curve calibrated against the top 1000 sites. A 100 means "in the top tier of fast pages". A 50 means median.

Google calls 90+ "good", 50-89 "needs improvement", and below 50 "poor." Most production sites in 2026 score 50-80 mobile and 80-95 desktop. Hitting 90+ on mobile is genuinely difficult and requires deliberate optimization.

Mobile vs. desktop scoring

PSI runs two audits: one with simulated Slow 4G + mid-tier mobile device throttling, and one with simulated cable-speed desktop. The mobile score is almost always lower because the simulated device is slower.

Google's ranking signal uses mobile field data. Desktop scores are useful for diagnosis but don't directly affect SEO. Optimize for the mobile experience first.

The recommendation engine: opportunities and diagnostics

Below the scores, PSI surfaces a prioritized list of issues. Two types:

• Opportunities — quantified savings, e.g., "Properly size images: estimated 1.2s savings." These are concrete things to fix that should improve your score.
• Diagnostics — qualitative findings, e.g., "Avoid an excessive DOM size." Useful context but no direct savings estimate.

The most common opportunities (in our experience auditing thousands of sites):

1. Properly size images (images served larger than displayed)
2. Defer offscreen images (images below the fold loaded eagerly)
3. Eliminate render-blocking resources (CSS/JS in head)
4. Reduce unused JavaScript (bundle bloat)
5. Serve images in next-gen formats (no WebP/AVIF)
6. Reduce unused CSS (over-shipped stylesheets)
7. Minify CSS/JavaScript (uncompressed assets)
8. Enable text compression (no gzip/brotli)
9. Preconnect to required origins (critical third-party domains)
10. Avoid chaining critical requests (waterfall depth)

Common PSI score interpretation mistakes

• Chasing a 100 score. Diminishing returns kick in hard above 90. Optimizing 95→100 often takes more dev time than 70→90 and brings less real-world benefit.
• Treating every PSI run as authoritative. PSI lab scores have ±5 point variance run-to-run because of network simulation noise. Don't react to a single score change; look at trends across multiple runs.
• Ignoring the field data. Lab data tells you what's possible; field data tells you what users actually experience. If your field LCP is bad but lab LCP is good, your problem is geographic distribution, real-device variance, or third-party scripts that don't load in lab conditions.
• Optimizing for the score instead of the experience. Some optimizations improve the score without helping users (e.g., aggressive code splitting that makes interactions slower). Always validate with real users (RUM data) after PSI changes.
• Forgetting the ranking signal lag. CrUX data is a 28-day rolling window. If you ship an optimization today, it'll take 4 weeks before field data fully reflects it.
• Comparing PSI to other tools without normalizing. WebPageTest, GTmetrix, and PSI use different throttling profiles. The same page can score 65 on PSI mobile and 85 on GTmetrix. The numbers aren't comparable across tools — pick one and stick with it.

PSI vs. Lighthouse vs. Chrome DevTools Performance

Three related tools, different use cases:

• PSI — public-facing, includes field data, easy to share. Best for product/exec audiences and quick checks.
• Lighthouse (DevTools or CLI) — runs on your local machine, no field data, faster iteration. Best for active optimization work.
• Chrome DevTools Performance tab — flame charts, JavaScript profiling, no scoring. Best for deep root-cause analysis.

Automating PSI checks in CI

Don't rely on manual PSI runs. Better practice: automate Lighthouse audits in your CI pipeline (using lighthouse-ci) and fail the build if performance regresses below a threshold. This catches regressions before they hit production. Most mature web teams have Lighthouse-CI gates for the main pages.

FAQ: PageSpeed Insights

Why is my PSI score so low?

Most likely culprits: render-blocking JavaScript in the head, unoptimized images, layout shifts from late-loading content, and third-party scripts (analytics, ads, chat widgets). PSI's diagnostics will rank these for you. Start at the top.

Does PSI score affect SEO ranking?

Indirectly. The ranking signal is Core Web Vitals, which uses field (CrUX) data — not the PSI lab score. A high lab score with bad field data won't help SEO. A perfect field-data passing rate with a mediocre lab score is fine.

Why do my PSI scores fluctuate?

Lab scores fluctuate because Lighthouse uses simulated network throttling that adds randomness. Run 3-5 audits and use the median. Field data fluctuates because of changes in user device mix, geographic distribution, and traffic patterns.

Why is desktop score 90+ but mobile in the 50s?

Mobile devices are dramatically slower than desktops, especially on simulated mid-tier hardware with Slow 4G throttling. JavaScript execution is 4-6x slower on mobile, network is throttled, and main-thread bottlenecks have more impact. Mobile-first optimization is harder.

How do I improve PSI scores?

Top three actions for most sites: (1) optimize images — proper sizing, WebP/AVIF format, lazy loading below-fold; (2) reduce JavaScript — code split, defer non-critical scripts, eliminate unused libraries; (3) eliminate render-blocking — inline critical CSS, defer/async JS, preload fonts. LoadFocus speed test shows the same diagnostics with multi-location coverage.

How often should I check PSI?

For active optimization work, daily. For monitoring, monthly is fine — set up automated Lighthouse-CI in your build pipeline so you don't need to remember.

How LoadFocus complements PSI

PSI tests one URL from one Google data center. LoadFocus website speed testing runs the same Lighthouse audit from 30+ locations worldwide, surfacing geographic performance differences PSI cannot see. Continuous monitoring tracks Core Web Vitals over time so you catch regressions the day they happen, not 4 weeks later when the field-data signal arrives.