PageSpeed Insights (PSI)

TL;DR — PageSpeed InsightsPageSpeed 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. (PSI) is a free Google tool that grades a page two different ways: how real visitors actually experienced it (field dataPerformance metrics captured from real users, not lab tests.), 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 (CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.), 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 VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. Assessment — a simple Passed or Failed.
2. Lab data — one simulated test. PSI also runs Google LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. 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 PaintLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., Interaction to Next PaintInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., 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 VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data..

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 LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. and Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.? Switch to the Advanced tab.

TL;DR — PSI (pagespeed.web.dev) reports two independent analyses of one URL: field dataPerformance metrics captured from real users, not lab tests. from the Chrome UX ReportChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. — real users over a rolling 28 days, which drives the Passed/Failed Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. Assessment at the 75th percentile — and lab data, a single LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. 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 VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. (LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good./INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good./CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.). Field data needs enough CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. 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; LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. is the engine; Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.’s report is yet another CrUX view.

PSI is two tools wearing one coat

The single most important thing to understand about PageSpeed InsightsPageSpeed 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. 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 FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. and TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. as “Other metrics” — informative, but not part of the verdict.
• There’s one documented exception, and it’s INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good.-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 LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. 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.

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 redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. 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 resourcesRender-blocking resources are CSS and synchronous JavaScript files a browser must download and process before it can paint any visible content. They sit on the critical rendering path and delay First Contentful Paint and Largest Contentful Paint., oversized images, layout shift sources, long tasksAny main-thread task over 50 ms — the primary cause of INP regressions..
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.

TIP Read no field data as unavailable, not passing

PSI's field and lab sections answer different questions. When CrUX has no stable sample, a Lighthouse run can diagnose the page but cannot supply a field verdict.

Check the same boundary with my free Page Speed Test Free

1. Look for URL-level or origin-level field data before reading the lab score.
2. If field data is unavailable, use the lab audit to find testable causes rather than declaring a pass.
3. Compare later checks by source, device, and scope so field and lab numbers are never blended.

Tap to enlarge

The result reports no stable CrUX sample at URL or origin level, marks mobile and desktop not evaluated, and offers a fresh lab audit whose simulated numbers can vary between runs.

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 ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance.’s Core Web Vitals reportThe Google Search Console report (under Experience) that shows how your indexed URLs perform on the Core Web Vitals — LCP, INP, and CLS — using real-user field data from CrUX, grouped by device, status, and clusters of similar-performing URLs.. 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 / WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. / 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 dataPerformance metrics captured from real users, not lab tests. from the Chrome UX ReportChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. (real users) and lab data from a single LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. run, for the same URL, at pagespeed.web.dev. Free, no login, any public URL, mobile + desktop.
• Field data drives the Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. Assessment — Passed/Failed, at the 75th percentile, across LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. (<2.5s), INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. (<200ms), and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. (<0.1). Rolling 28-day window, updated daily. FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. and TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. 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 VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. (CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.-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” (LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. 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 ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. 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 InsightsPageSpeed 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.

• 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 ReportChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. (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 dataPerformance metrics captured from real users, not lab tests..
• CrUX overview — how CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. feeds the page experienceGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. ranking signal.

web.dev / Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data.

• What are the Core Web Vitals tools? — where PSI fits among CrUX/LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. tooling.
• Core Web Vitals — the LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good./INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good./CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. 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 dataPerformance metrics captured from real users, not lab tests. from CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. and lab from LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. 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, CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. in PSI. Jump to quote
• “To pass, the percentile must be categorized as ‘good’ in all three Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data.. 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 VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data.. 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 InsightsPageSpeed 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. does not impact SEO directly. However, the real-user Core Web VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors. 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 VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. “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 InsightsPageSpeed 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. (pagespeed.web.dev) — the tool itself: field (CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.) + lab (LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal.), mobile and desktop, any public URL.
• Google LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. — 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 dataPerformance metrics captured from real users, not lab tests.).
• Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. — Core Web Vitals reportThe Google Search Console report (under Experience) that shows how your indexed URLs perform on the Core Web Vitals — LCP, INP, and CLS — using real-user field data from CrUX, grouped by device, status, and clusters of similar-performing URLs. — the other CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.-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 WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. / 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 LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. lab run. The ranking-relevant Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. assessment comes from CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. field dataPerformance metrics captured from real users, not lab tests..
• 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. CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. 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 CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. result, but the LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. report runs.

Likely cause: The URL and origin do not meet CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. 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 ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. group is poor, or the reverse.

Likely cause: PSI may show URL- or origin-level data, while Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. 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 VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. 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 LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. 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 FIDFirst Input Delay — a retired Core Web Vital that measured the delay before the browser could begin processing a page's first interaction. Good was ≤100 ms. Replaced by INP in March 2024.→INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. swap).
• Core Web Vitals: A Complete Guide — field vs. lab and my take on how much CWVGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. 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, LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal., CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program., and Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. 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 dataPerformance metrics captured from real users, not lab tests. is a 28-day rolling average. A fix can take up to ~28 days to be fully reflected in the Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. 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 LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. 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 dataPerformance metrics captured from real users, not lab tests. section (“Discover what your real users are experiencing”) comes from the Chrome UX ReportChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. (CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.) — real Chrome users over a rolling 28-day window — and powers the Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. Assessment, a Passed/Failed verdict based on the 75th-percentile values of Largest Contentful PaintLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., Interaction to Next PaintInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., and Cumulative Layout ShiftCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.. The lab data section is a single LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. 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 VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. (the same CrUX data). A page can score below 90 and still pass Core Web VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors., because they’re different numbers from different systems. PSI is the web UI; LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. is the engine it runs, and Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.’s Core Web Vitals reportThe Google Search Console report (under Experience) that shows how your indexed URLs perform on the Core Web Vitals — LCP, INP, and CLS — using real-user field data from CrUX, grouped by device, status, and clusters of similar-performing URLs. is a separate CrUX-based view.

Related: Lighthouse, CrUX, Core Web Vitals

Changelog