PageSpeed Insights (PSI)

TL;DR — PageSpeed Insights (PSI) is a free Google tool that grades a page two different ways: how real visitors actually experienced it (field data), and how a single simulated test run went (the 0–100 lab score). The 0–100 number is the one everyone obsesses over — and it’s not what Google uses for ranking. So don’t panic over a red score.

What PageSpeed Insights is

PageSpeed Insights lives at pagespeed.web.dev. It’s free, there’s no login, and it works on any public URL — including your competitors’. You paste in a URL, and it tests both mobile and desktop (mobile is the default tab, and mobile scores are almost always lower).

The two things PSI shows you

This is the part that confuses everyone, so I’ll keep it simple. PSI shows two separate reports for the same page:

1. Field data — what real people experienced. This comes from the Chrome UX Report (CrUX), which is real Chrome users visiting your page over the last 28 days. It’s the section labeled “Discover what your real users are experiencing.” This is where you get the Core Web Vitals Assessment — a simple Passed or Failed.
2. Lab data — one simulated test. PSI also runs Google Lighthouse once, on a simulated phone and network, and spits out the 0–100 Performance score plus a list of suggested fixes.

The one thing to remember

The 0–100 score is not a ranking factor. Google ranks on the field Core Web Vitals — Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift, measured from real users. The 0–100 lab score is a separate number from a separate system. You can score a 72 and still pass Core Web Vitals.

A few more things that trip people up:

• The score changes every time you run it. It’s one simulated test, so the number bounces around. Run it a few times and don’t read into a 3–5 point swing.
• You don’t need a 100. Almost nobody scores 100. Aim to pass Core Web Vitals, not to hit a perfect number.
• A good score doesn’t guarantee a fast page for real users, and a “bad” score doesn’t mean real users are suffering.

Honestly, unless your site is genuinely slow, this isn’t where I’d start. Want the full breakdown — field vs. lab, the p75 thresholds, the data fallbacks, and how PSI differs from Lighthouse and Search Console? Switch to the Advanced tab.

TL;DR — PSI (pagespeed.web.dev) reports two independent analyses of one URL: field data from the Chrome UX Report — real users over a rolling 28 days, which drives the Passed/Failed Core Web Vitals Assessment at the 75th percentile — and lab data, a single Lighthouse run giving the 0–100 Performance score plus diagnostics. The 0–100 score is lab data and is not a ranking factor; ranking uses the field Core Web Vitals (LCP/INP/CLS). Field data needs enough CrUX samples (URL-level, falling back to origin-level, else “No data”). The lab score is also variable run-to-run — run it a few times. PSI is the web UI; Lighthouse is the engine; Search Console’s report is yet another CrUX view.

PSI is two tools wearing one coat

The single most important thing to understand about PageSpeed Insights is that it’s not one analysis — it’s two, surfaced in one interface. web.dev puts it cleanly: “PSI is a tool that reports field data from CrUX and lab from Lighthouse for a given page.” Those two halves come from different systems, measure different things, and matter for different reasons. Conflate them and nearly every PSI question becomes confusing; keep them separate and it all clicks.

Field data: what real users experienced

The top section — “Discover what your real users are experiencing” — is powered by the Chrome UX Report (CrUX). web.dev describes the CrUX API as giving “low-latency access to aggregated real-user experience data at page and origin granularity” as a “28-day rolling average.” PSI updates daily; the BigQuery CrUX dataset releases monthly.

A few mechanics that matter:

• The Core Web Vitals Assessment is Passed/Failed at p75. Per Chrome’s docs, “to pass, the percentile must be categorized as ‘good’ in all three Core Web Vitals. Otherwise, the assessment appears as ‘failed’.” The three are Largest Contentful Paint (good < 2.5s), Interaction to Next Paint (good < 200ms), and Cumulative Layout Shift (good < 0.1). PSI also shows FCP and TTFB as “Other metrics” — informative, but not part of the verdict.
• There’s one documented exception, and it’s INP-only. If a page doesn’t have enough CrUX samples to report INP specifically, PSI’s current guide says it can still assess Pass/Fail from good LCP and CLS p75 values alone. There’s no equivalent exception for LCP or CLS — if either of those is the one missing enough data, don’t read that as a pass; insufficient data isn’t a documented free pass on any metric except INP.
• p75 means the 75th percentile. The value shown is the experience 75% of page views were faster than. web.dev chose the 75th percentile so the number is “resistant to outliers” — a stricter target than a median.
• INP replaced FID in March 2024. If you’re looking at old screenshots or old guides (including my own older Ahrefs writing on PageSpeed Insights and Core Web Vitals), they may still show FID; the assessment now uses INP.
• URL → origin → “No data” fallback. If there isn’t enough CrUX data for the specific URL, PSI falls back to origin-level data (aggregated across the whole site). If there’s no CrUX data at all, you’ll see “No data,” but Lighthouse still runs. As web.dev notes, “CrUX data is only available when sites meet certain eligibility criteria” and “PSI is only available for public URLs.” Low-traffic pages and brand-new pages frequently have no URL-level field data.

Read the scope label before writing the finding. URL-level CrUX describes the eligible field sample attributed to that URL. Origin-level fallback is a useful site-wide signal, but it cannot diagnose the tested page on its own. “No data” means the field sample is unavailable or insufficient—not that the page passed, failed, or received no traffic. The Lighthouse result below can still diagnose that controlled lab run, but it does not fill the missing field-data gap.

Lab data: the 0–100 Lighthouse score

The lower section is a single Lighthouse run on a simulated device and network, producing the Performance score and a list of opportunities and diagnostics. Google’s banding: “A score of 90 or above is considered good. 50 to 89 is a score that needs improvement, and below 50 is considered poor.”

What to know about the lab run:

• It’s simulated, and the mobile run is deliberately slow. Mobile emulates a mid-tier phone on a throttled connection; desktop uses a faster emulated profile. That’s why your mobile score is almost always lower than desktop — and why real-user field data often looks better than the lab diagnostics suggest.
• The score is variable. Each run is a fresh, server-side Lighthouse audit — the page, Google’s datacenter, network conditions, and even the Chrome/Lighthouse version can all move the number between runs. I recommend running it a few times (3–5) and looking at the range rather than treating any single run as gospel. A few points of swing is noise.
• If you’re comparing runs, save more than the score. The API response carries a timestamp, the requested and final URL, form factor, the emulated environment, the Lighthouse version, and any warnings — keep those alongside each score. Two “72”s aren’t comparable if one ran on a different Lighthouse version or hit a redirect the other didn’t. Don’t average unlabeled scores; label them or don’t compare them.
• Lighthouse versions move independently of the PSI API. PSI stayed on API v5, but the Lighthouse engine underneath it keeps shipping new releases (the most recent noted in Google’s release notes as of this review is Lighthouse 13.0, dated 2025-10-20) — audit fields, weights, and bands can shift with the engine version even though the API contract doesn’t change.
• “Estimated savings” are not additive. The seconds shown next to each diagnostic assume that fix is made in isolation. Issues interact; real-world gains are almost always less than the sum of the individual estimates. Treat them as directional, not as a budget you can total up.
• The metric weights change with Lighthouse versions. The Performance score is a weighted blend of lab metrics (load-time metrics, Total Blocking Time, and CLS carry the most weight), but the exact weights shift between Lighthouse releases — check the current scoring calculator rather than trusting a fixed split.

The myth that causes the most damage: “the score is a ranking factor”

It isn’t. The 0–100 Performance score is a Lighthouse lab number, and I haven’t found any current official Google Search source that documents that score itself as a ranking input or ties a score change to a ranking change. Google’s page experience documentation instead points to field Core Web Vitals — CrUX-based real-user data, the same type of data PSI’s field section shows at p75. (One caveat worth being precise about: PSI’s public field display is a reporting surface with its own eligibility and fallback rules; Google hasn’t published the exact internal pipeline that feeds ranking, so treat “field data” as the same kind of signal rather than assuming byte-for-byte identity with what PSI shows you.) A page can sit at 72 in the lab and still pass the Core Web Vitals Assessment because its real-user data is good — different numbers from different systems. The corollary myth — “a good lab score equals a good real-user experience” — fails for the same reason: lab conditions aren’t your visitors’ conditions. When field and lab diverge, field data is the more relevant one for SEO.

And even the field Core Web Vitals are a fairly small ranking input. Google’s own people have downplayed them — Gary Illyes has called page experience closer to a tiebreaker than a major signal. My honest position hasn’t changed: I don’t think Core Web Vitals have much impact on SEO, and unless a site is extremely slow, I generally won’t prioritize fixing them over content and links. Fix them for users and for the genuinely-slow case — not out of panic over a red number.

How to actually read a PSI report

1. Read the field data first. Did it Pass or Fail the Core Web Vitals Assessment? That’s the SEO-relevant verdict. If it says “No data,” there isn’t enough CrUX traffic yet — you’re working from lab data alone.
2. Check mobile and desktop separately. Mobile is the default and usually the weaker one; it’s also what mostly matters, since Google indexes mobile-first.
3. Then use the lab diagnostics to find the cause. Lab data is your fast feedback loop for finding and fixing the root issue — render-blocking resources, oversized images, layout shift sources, long tasks.
4. Fix, then wait. Field data is a rolling 28-day window, so a fix you ship today can take up to 28 days to fully show up in the Core Web Vitals Assessment. Use lab data to confirm the fix immediately; use field data to confirm it actually moved real users.
5. Benchmark competitors. Because PSI works on any public URL, you can run a competitor’s pages and compare their field Core Web Vitals to yours — a use case most guides never mention.

PSI vs. the tools it gets confused with

• PSI vs. Lighthouse. Lighthouse is the engine; PSI is a web UI that runs Lighthouse and layers CrUX field data on top. Run Lighthouse yourself (in Chrome DevTools or the CLI) and you get the lab audit but on your machine and network, with no field data.
• PSI vs. Search Console’s Core Web Vitals report. Both are CrUX-based, so both reflect real users. The difference: Search Console groups similar URLs together and reports at scale across your whole property, while PSI is per-URL (or origin-level fallback). If GSC and PSI seem to disagree, it’s usually the grouping.
• PSI vs. Chrome DevTools / WebPageTest / DebugBear / Ahrefs Site Audit. These give more configuration (custom devices, locations, throttling) and, in some cases, real-user monitoring. PSI’s strength is being free, zero-setup, and tied to Google’s own CrUX dataset.

The PSI API (for bulk testing)

You don’t have to use the web UI one URL at a time. The PageSpeed Insights API (base https://www.googleapis.com/pagespeedonline/v5) returns the same data programmatically. Key parameters: url (required), strategy (mobile or desktop), and category (performance, accessibility, best-practices, seo). The response splits the same way the UI does: loadingExperience (URL-level field data), originLoadingExperience (origin-level field data), and lighthouseResult (the lab audit). That’s how you’d test a batch of URLs on a schedule rather than clicking through them by hand.

Don’t build durable field-data automation on this API. Google’s own API documentation now opens with a notice that it plans to discontinue including CrUX real-world data in the PSI API, and points automators at the dedicated CrUX API or CrUX History API instead. Keep using the PSI API for the Lighthouse lab audit — that part isn’t affected — but if you’re scheduling bulk field-data pulls, build against a CrUX-specific API, not loadingExperience/originLoadingExperience in the PSI response.

Where this sits in web performance

PSI is a measurement tool, not the destination. The metrics it surfaces — Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift — are the Core Web Vitals, and the hub for those (thresholds, what each one means, and how to improve them) is the place to go next. Lighthouse is the lab engine PSI runs on; CrUX (the Chrome UX Report) is the field-data source feeding the top of every PSI report. Understand those three and PSI stops being a mystery box.

AI summary

A condensed take on the Advanced version:

• PSI = two tools in one UI. Field data from the Chrome UX Report (real users) and lab data from a single Lighthouse run, for the same URL, at pagespeed.web.dev. Free, no login, any public URL, mobile + desktop.
• Field data drives the Core Web Vitals Assessment — Passed/Failed, at the 75th percentile, across LCP (<2.5s), INP (<200ms), and CLS (<0.1). Rolling 28-day window, updated daily. FCP and TTFB are shown but don’t count toward the verdict.
• Lab data is the 0–100 Performance score (90+ good, 50–89 needs work, <50 poor) plus diagnostics. Mobile is throttled and scores lower than desktop.
• The 0–100 score is NOT documented as a ranking factor. Google’s ranking systems use field Core Web Vitals (CrUX-based real-user data — the same type of data PSI’s field section shows, though Google hasn’t published the exact internal pipeline as identical to PSI’s public display). A page can score 72 and still pass CWV — different numbers from different systems.
• CrUX fallback: URL-level → origin-level → “No data” (Lighthouse still runs). Low-traffic and new pages often have no URL-level field data.
• The score is variable run-to-run — run 3–5 times. “Estimated savings” aren’t additive. You don’t need 100.
• Read field data first (Passed/Failed), then use lab diagnostics to find the cause; ship the fix, then wait up to 28 days for field data to reflect it.
• PSI vs. Lighthouse (engine vs. UI+field) and vs. Search Console CWV report (also CrUX, but grouped at scale). CWV is overall a minor ranking input.

Official documentation

Primary-source docs from Google and the Chrome / web.dev teams.

Google / PageSpeed Insights

• PageSpeed Insights tool — the tool itself.
• PageSpeed Insights API — About — what PSI does, the two data types, and the 0–100 score bands.
• PSI API — runPagespeed reference — parameters (url, strategy, category) and the response structure.

Chrome UX Report (the field-data source)

• Using CrUX in PageSpeed Insights — how the field section works and the Passed/Failed assessment.
• CrUX methodology — eligibility, opt-in, and which pages are included.
• CrUX API — the 28-day rolling average powering PSI’s field data.
• CrUX overview — how CrUX feeds the page experience ranking signal.

web.dev / Core Web Vitals

• What are the Core Web Vitals tools? — where PSI fits among CrUX/Lighthouse tooling.
• Core Web Vitals — the LCP/INP/CLS thresholds and the 75th-percentile rule.
• Defining the Core Web Vitals thresholds — why p75.
• Core Web Vitals & Google Search — the ranking-signal context.

Quotes from the source

Verbatim statements, each linked to the passage on the source page.

Google / Chrome / web.dev — how PSI works

• “PSI is a tool that reports field data from CrUX and lab from Lighthouse for a given page.” — web.dev. Jump to quote
• “PSI is only available for public URLs. It cannot be used on development sites that are not publicly accessible.” — web.dev. Jump to quote
• The field section is described as “Discover what your real users are experiencing.” — Chrome for Developers, CrUX in PSI. Jump to quote
• “To pass, the percentile must be categorized as ‘good’ in all three Core Web Vitals. Otherwise, the assessment appears as ‘failed’.” — Chrome for Developers, CrUX in PSI. Jump to quote
• The CrUX API gives “low-latency access to aggregated real-user experience data at page and origin granularity” as a “28-day rolling average.” — Chrome for Developers, CrUX API. Jump to quote

web.dev — thresholds

• “a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.” — web.dev, Core Web Vitals. Jump to quote
• “if at least 75 percent of page views to a site meet the ‘good’ threshold, the site is classified as having ‘good’ performance.” — web.dev, defining the thresholds. Jump to quote

Industry — the score-vs-ranking distinction (relayed, not Google)

• “The Performance score on PageSpeed Insights does not impact SEO directly. However, the real-user Core Web Vitals assessment does impact Google rankings.” — Matt Zeunert, DebugBear. Source
• “Core Web Vitals are the only metrics Google explicitly uses for grading.” and “Running the same URL just minutes apart can yield different scores.” — Ryan Sullivan, SiteCare. Source

PSI report cheat sheet

Each PSI section: field vs. lab, and what it means

Core Web Vitals “good” thresholds (field, p75)

Lighthouse score bands (lab)

• 90–100 — good · 50–89 — needs improvement · <50 — poor

Field-data fallback

• URL-level CrUX → if not enough, origin-level → if none, “No data” (Lighthouse still runs).

Fast facts

• Field data = rolling 28 days, updated daily → a fix can take up to 28 days to show.
• The 0–100 score is variable — run 3–5 times, ignore a 3–5 point swing.
• “Estimated savings” don’t add up — they assume each fix is made alone.
• Mobile is the default tab and usually scores lower than desktop.
• INP replaced FID in March 2024.

Tools around PSI

• PageSpeed Insights (pagespeed.web.dev) — the tool itself: field (CrUX) + lab (Lighthouse), mobile and desktop, any public URL.
• Google Lighthouse — the lab engine PSI runs. Run it locally in Chrome DevTools (Lighthouse panel) or via the CLI for the lab audit on your own device/network (no field data).
• Google Search Console — Core Web Vitals report — the other CrUX-based view; groups similar URLs and reports field data across your whole property.
• CrUX Vis / CrUX API / BigQuery — go straight to the field data behind PSI for trends over time. (The old CrUX Dashboard in Looker Studio was deprecated at the end of November 2025 — Google’s own release notes and its dedicated deprecation post both confirm the date and point to CrUX Vis (cruxvis.withgoogle.com) as the replacement. If a guide still tells you to use the Dashboard, it’s stale.)
• PSI API — bulk-test many URLs programmatically (url, strategy, category); response splits into loadingExperience, originLoadingExperience, and lighthouseResult. Google has announced it plans to discontinue including CrUX real-user data in this API and now recommends the dedicated CrUX API or CrUX History API for durable field-data automation — don’t build a pipeline that assumes the PSI API’s field objects stay around long-term.
• Ahrefs Site Audit and WebPageTest / DebugBear — more configuration and, in some cases, real-user monitoring beyond a single Lighthouse run.

PageSpeed Insights mistakes that distort priorities

• Treating the 0–100 score as a ranking factor. The score is one Lighthouse lab run. The ranking-relevant Core Web Vitals assessment comes from CrUX field data.
• Reading origin fallback as URL performance. When a URL lacks enough samples, PSI may show origin-level data. Check the scope label before claiming the page itself passed or failed.
• Reacting to one lab run. Server response and the synthetic environment vary. Repeat matched runs and use the range or median to distinguish signal from noise.
• Adding opportunity savings together. Audit estimates overlap and assume each fix happens independently. Treat them as directional clues, not a promised total.
• Expecting a deployment to change field data immediately. CrUX is a rolling 28-day view. Use the lab section for immediate diagnosis and the field section for confirmation over time.
• Comparing mobile and desktop scores as if conditions match. Evaluate each profile against itself and your audience rather than treating the numbers as one scale.

PSI says “No data”

Symptom: The field section has no CrUX result, but the Lighthouse report runs.

Likely cause: The URL and origin do not meet CrUX eligibility or sample-volume requirements, or the page is new or low traffic.

Fix and confirmation: Do not manufacture a field conclusion. Use lab diagnostics for immediate work, check representative higher-traffic templates, and return later to see whether a URL- or origin-level field result appears.

PSI and Search Console disagree

Symptom: A URL looks healthy in PSI while its Search Console group is poor, or the reverse.

Likely cause: PSI may show URL- or origin-level data, while Search Console groups similar URLs. Device, scope, and rolling-window timing can also differ.

Fix and confirmation: Match mobile/desktop, inspect PSI’s data scope, and sample several URLs from the Search Console group before concluding that either report is wrong.

The lab score swings between runs

Symptom: Repeating PSI produces materially different scores or metric values.

Likely cause: A variable server response, third-party request, or normal single-run lab noise changed the trace.

Fix and confirmation: Run the same strategy several times, compare individual metrics and request waterfalls, and investigate a repeated bottleneck rather than the score alone.

A fix is visible in Lighthouse but not field data

Symptom: The lab metric improves immediately, while the field Core Web Vitals assessment stays unchanged.

Likely cause: CrUX still includes pre-release visits in its rolling 28-day window, or the fix did not help the users and templates represented in the field dataset.

Fix and confirmation: Verify the deployment and lab trace now, annotate the release date, then watch the field distribution through the full reporting window.

Pull one PSI result from the API

The API exposes field and lab sections separately. Supply your own API key and URL:

curl --get 'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
  --data-urlencode "url=$TARGET_URL" \
  --data 'strategy=mobile' \
  --data-urlencode "key=$PSI_KEY" \
  --output psi.json

Keep the raw response so the test date, strategy, and data scope remain auditable.

Separate field scope from the lab score

With jq, extract the URL field category, origin fallback category, and Lighthouse score instead of collapsing them into one number:

jq '{
  url_field: .loadingExperience.overall_category,
  origin_field: .originLoadingExperience.overall_category,
  lab_score: (.lighthouseResult.categories.performance.score * 100)
}' psi.json

A missing field value is not a zero; it means that scope was unavailable in the response.

Repeat the lab run without hiding the samples

for run in 1 2 3; do
  curl --silent --get 'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
    --data-urlencode "url=$TARGET_URL" \
    --data 'strategy=mobile' \
    --data-urlencode "key=$PSI_KEY" \
  | jq -r "[$run, (.lighthouseResult.categories.performance.score * 100)] | @tsv"
done

Report all samples or a documented summary; do not select only the best score.

Test yourself: PageSpeed Insights

Five quick questions on reading PSI correctly. Pick an answer for each, then check.

Resources worth your time

My related writing

• Google PageSpeed Insights: A Beginner-Friendly Guide — my Ahrefs walkthrough (note: it predates the FID→INP swap).
• Core Web Vitals: A Complete Guide — field vs. lab and my take on how much CWV actually matters.
• The Beginner’s Guide to Technical SEO — where performance fits in the bigger picture.

Official

• Using CrUX in PageSpeed Insights — Chrome’s own explainer of the field section.
• What are the Core Web Vitals tools? — how PSI, Lighthouse, CrUX, and Search Console relate.

From others

• How To Use PageSpeed Insights — Matt Zeunert (DebugBear); strong technical depth on the score and diagnostics.
• PageSpeed Insights: Google’s Highly Misunderstood Diagnostic Tool — Ryan Sullivan (SiteCare); good myth-busting.
• Core Web Vitals Ranking Factor Is More Than A Tiebreaker — Search Engine Journal coverage of Gary Illyes’ comments putting CWV impact in context.
• Google Page Experience Update Is More Than A Tie Breaker — SE Roundtable; Barry Schwartz’s reporting on how Google reps have characterized the page experience signal.

Stats worth citing

• Almost nobody scores 100. Only about 2% of tested pages hit a perfect 100, and a score of 50 already puts you in the top 25% — useful context for anyone panicking over a sub-90 number. Source
• Field data is a 28-day rolling average. A fix can take up to ~28 days to be fully reflected in the Core Web Vitals Assessment — use lab data for fast feedback in the meantime. Source
• The “good” threshold is the 75th percentile. Google grades at p75 so that “a majority of visits experienced the target level of performance” — meaning even at a passing LCP of 2.5s, a quarter of visitors waited longer. Source

PageSpeed Insights

PageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking.

Related: Lighthouse, CrUX, Core Web Vitals

PageSpeed Insights

PageSpeed Insights (PSI) is Google’s free page-performance tool at pagespeed.web.dev. It needs no login and works on any public URL, and it analyzes mobile and desktop separately.

PSI reports two distinct things for the same page. The field data section (“Discover what your real users are experiencing”) comes from the Chrome UX Report (CrUX) — real Chrome users over a rolling 28-day window — and powers the Core Web Vitals Assessment, a Passed/Failed verdict based on the 75th-percentile values of Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. The lab data section is a single Lighthouse run on a simulated device and network that produces the 0–100 Performance score plus diagnostics and opportunities.

The key thing to keep straight: the 0–100 score is lab data and is not what Google uses for ranking. Ranking draws on the field Core Web Vitals (the same CrUX data). A page can score below 90 and still pass Core Web Vitals, because they’re different numbers from different systems. PSI is the web UI; Lighthouse is the engine it runs, and Search Console’s Core Web Vitals report is a separate CrUX-based view.

Related: Lighthouse, CrUX, Core Web Vitals

Changelog