Web Performance Tools

TL;DR — There are three main tools for measuring how fast your pages are, and people constantly confuse them. 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. runs a single test in a pretend “lab” and gives you a 0–100 score. 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 real data from real Chrome users — and it is the field-data source used for 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. reporting. PageSpeed Insights shows you both on one screen. The big lesson: your lab score isn’t what Google ranks you on.

Three tools, three jobs

When you start measuring page speed you’ll run into three names over and over — 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., 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., and 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.). Most people think they’re the same thing. They’re not. Here’s the simplest way to keep them straight:

• Google Lighthouse is a testing tool. It loads your page on a simulated slow phone, runs a bunch of checks, and gives you a 0–100 score. It’s a lab test — one machine, one moment, controlled conditions.
• The Chrome UX Report (CrUX) is real data from actual Chrome users visiting your site. It’s the field data — and it’s the data Google uses for ranking.
• 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 web page that shows you both: the real-user field dataPerformance metrics captured from real users, not lab tests. (from CrUX) at the top, and a Lighthouse lab test underneath.

Lab vs field — the one idea to remember

“Lab” means a controlled test: one device, one network setting, run on demand. “Field” means real people on real phones and laptops over real connections, measured as they actually use your site.

This matters because Google ranks on field data, not your lab score. You can get a 100 in Lighthouse and still have real users experiencing a slow page — or score poorly in the lab and pass just fine for real visitors. When the two disagree, the real-user (field) data is the one that counts for SEO.

So which do I use?

• “How am I doing for ranking?” → Look at the field data (CrUX), easiest seen in PageSpeed Insights or 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..
• “What’s making my page slow?” → Run Lighthouse (it lists what to fix).
• “I just want one place to see both.” → PageSpeed Insights.

Want the full picture — how Lighthouse scores work, what “p75” means, why so many pages have no field data, and the exact workflow I use to find and fix problems? Switch to the Advanced tab.

TL;DR — Web performance measurement comes down to lab vs field. 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: a simulated audit (Slow 4G, 4× CPU) scoring a page 0–100 (Performance = TBTTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital. 30%, 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. 25%, 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. 25%, 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. 10%, Speed IndexSpeed Index measures how quickly content is visually displayed during page load — the average time at which visible parts of the page appear, scored in seconds (lower is better). It's a lab-only Lighthouse metric, not a Core Web Vital and not a ranking factor. 10%). It’s a diagnostic, not a ranking signal, and it can’t measure INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. — it uses TBTTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital. as a proxy. 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: real opted-in Chrome users at the 75th percentile over a 28-day rolling window — the field dataset behind Google’s public CWV reporting. 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. = both in one UI: 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. on top (the Passed/Failed CWV Assessment that matters for SEO) and a 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 below (the 0–100 score, which doesn’t). Use field data to know where you stand, lab data to debug, and Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. to find failing page groups at scale. Only ~11.9% of the 43.66M unique Site Audit pages in my January 2022 sample had a CrUX metric, so many pages in that sample lacked field data and PSI shows you a lab score and nothing else.

The spine: lab data vs field data

Nearly every misunderstanding about these tools comes from conflating two kinds of data. web.dev’s own framing is the cleanest: “CrUX is a collection of real-user experiences from the field, while Lighthouse is a controlled test in the lab.”

• Lab data is “collected in a controlled environment with predefined device and network settings.” It’s reproducible, fast, and great for catching regressions — but it’s one synthetic visitor, not your audience.
• Field data “is determined by monitoring all users who visit a page and measuring a given set of performance metrics for each one of those users’ individual experiences.” It’s noisy, it lags, and it’s the truth.

Google’s priority guidance is explicit: “If you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts.” So the single question every SEO should ask before reading any number is: am I looking at lab data or field data right now?

Google Lighthouse — the lab diagnostic

Lighthouse is “an open-source, automated tool to help you improve the quality of web pages.” You hand it a URL, it “runs a series of audits against the page,” and returns a report across Performance, Accessibility, Best Practices, and SEO. Lighthouse 12 dropped the old PWA category — but as of Lighthouse 13.3 (shipped May 2026), there’s a fifth category again: Agentic Browsing, an experimental audit of how well a page works for AI agents (accessibility-tree quality, layout stability, and WebMCP tool registration). It doesn’t use the 0–100 weighted score the other four do — it reports pass/fail checks and a fractional readiness count instead — so don’t fold it into the Performance number below.

The Performance score is a weighted average of five lab metrics (current as of Lighthouse 10 — Google versions these weights, so treat the exact numbers as checkable, not permanent):

Color bands: 0–49 red (poor), 50–89 orange (needs improvement), 90–100 green (good). A couple of things people miss:

• It throttles by design — Slow 4G and a 4× CPU slowdown — which is why your score is often lower than the snappy experience you get on your own fast machine.
• It can’t measure INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good.. As web.dev puts it, tools “that load pages in a simulated environment without a user cannot measure INP… the Total Blocking Time (TBT) metric is lab-measurable and is a proxy for INP.” A perfect TBT does not guarantee a passing INP in the field.
• The score varies run-to-run — Google says so plainly. Run it 3–5 times in incognito with extensions off and treat the result as a range.
• It is not a ranking signal. Lighthouse is a diagnostic for finding what to fix. → Deep dive: Google Lighthouse.

Chrome UX Report (CrUX) — the real-user dataset Google ranks on

CrUX is “a dataset that reflects how real-world Chrome users experience popular destinations on the web,” and crucially: “CrUX data is used by Google Search to inform the page experience ranking factor.” This is the data behind the Core Web Vitals program — the one that actually feeds ranking.

What to know:

• It’s Chrome-only and opt-in. Desktop and Android Chrome from users who opted into reporting — no Chrome on iOS, no WebViews, no Edge/Safari/Firefox. For a Safari-heavy audience, CrUX may capture a minority of your real users.
• It’s a 28-day rolling average at the 75th percentile. p75 means “75% of page loads experienced the given metric at or less than this value.” The p75 values are synthetically derived — “it does not imply that any user actually experienced the value indicated.”
• Slow feedback. With the 28-day window plus a ~2-day lag, a fix takes roughly ~30 days to fully show up in field data.
• Coverage is partial. From my Ahrefs Core Web Vitals data study, only ~11.9% of the 43.66M pages I looked at had any CrUX data at all, and around ~21.2% of pages passed 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.. Origin-level pass rates run higher (~33%), but origin data masks failing individual pages — and Google ranks on page-level data.
• Six access surfaces: PageSpeed Insights, Search Console’s CWV report, the CrUX API, the CrUX History API, BigQuery (origin-only, back to 2017), and CrUX Vis. Note the Looker Studio CrUX Dashboard was deprecated in November 2025 — use CrUX Vis (cruxvis.withgoogle.com) instead. → Deep dive: Chrome UX Report (CrUX).

PageSpeed Insights (PSI) — field + lab in one place

PSI “reports on the user experience of a page on both mobile and desktop devices, and provides suggestions on how that page may be improved.” It’s really two datasets wearing one coat:

• Top: CrUX field data. “Real-user experience data in PSI is powered by the Chrome User Experience Report (CrUX) dataset.” This drives the 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 — Passed or Failed at p75 across LCP, INP, and CLS: “To pass, the percentile must be categorized as ‘good’ in all three Core Web Vitals.” If the exact URL lacks data it falls back to origin-level, then to “No data.”
• Bottom: a Lighthouse lab run. “PSI uses Lighthouse to analyze the given URL in a simulated environment.” This is the 0–100 Performance score and the diagnostics.

The critical SEO point: the 0–100 score is lab data and is NOT a ranking input. Only the field CWV Assessment (the CrUX section) reflects what Google ranks on. PSI works on any public URL (so you can check competitors), but only public URLs — “It cannot be used on development sites that are not publicly accessible.” For those, run Lighthouse in DevTools. → Deep dive: PageSpeed Insights (PSI).

Choosing the right tool

The decision collapses to a few questions:

Two framing rules behind that table: field for assessment, lab for diagnosis — and site-wide goes to Search Console, individual URLs go to PSI. If a page has no CrUX data, you can’t assess its field CWV from PSI at all; you’re left with a lab score, which tells you nothing about the ranking signal.

Beyond the three: DevTools, Search Console groups, RUM, and synthetic monitoring

Lighthouse, PSI, and CrUX cover most of what an SEO needs day to day, but calling them “the three tools” undersells the rest of the toolkit:

• Chrome DevTools’ live metrics and performance trace. Open a page in DevTools’ Performance panel and LCP, CLS, and INP update as you actually interact with the page; record a trace and you can find the exact script or resource causing the delay. Because a real interaction is happening, this can capture an INP value — unlike Lighthouse’s non-interactive lab load, which can’t.
• Search Console’s Core Web Vitals report groups similar URLs, it doesn’t trace a single page. It’s a site-wide triage surface for finding which template or URL pattern is failing at scale; click into a group, then take a representative URL into PSI or DevTools to diagnose it.
• Synthetic monitoring re-runs the same automated check on a schedule, from chosen locations and device profiles, often wired into CI — so a regression gets caught before launch instead of showing up in CrUX ~30 days later. It’s repeatable and controlled, but it only ever observes the scenarios you configured, not your real traffic.
• Private RUM (Real User Monitoring) instruments your own site to record every visitor’s real experience — not just CrUX’s eligible, opted-in Chrome population — and can segment by business context (logged-in users, checkout flow, revenue) that CrUX can’t. That also means it can legitimately disagree with CrUX: different browser coverage, consent rules, sampling, and aggregation windows. You take on the setup, privacy/consent, and cost tradeoffs yourself.

None of that changes the spine: field data (CrUX or your own RUM) tells you where you stand; lab, trace, and synthetic tools tell you why. And if what you actually want is a ranked list of products rather than a map of tasks — plenty of “best web performance tools” roundups exist for that — the faster move is usually to run your own URL through a public test first, since a roundup ranks vendors, not your page.

The workflow I actually use

1. Google Search Console → Core Web Vitals report. Find failing page groups at scale across the site.
2. PageSpeed Insights. Confirm at page level — read the field-data CWV Assessment verdict for a representative URL.
3. PSI lab section / Lighthouse / Chrome DevTools. Diagnose the root cause and iterate on the fix with fast lab feedback.
4. Wait ~30 days. Field data updates on the 28-day window + lag.
5. Re-check PSI field + Search Console to confirm the real-user improvement.

Lab data is your fast feedback loop after a change; field data is the slow, authoritative confirmation.

TIP Keep field absence separate from a lab diagnosis

A field-data tool and a lab tool answer different questions. When CrUX has no stable sample, Lighthouse can debug the page but cannot provide real-user history.

Check the data-source boundary with my free Page Speed Test Free

1. Check URL- and origin-level field availability first.
2. Run the separate lab audit only for reproducible diagnostic clues.
3. Save and compare results by source, device, and scope; never blend lab numbers into a field trend.

Tap to enlarge

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

How CWV rankings actually work (briefly)

Google documents Core Web Vitals as something its ranking systems use, and CrUX as the dataset behind the public CWV reporting you see in PSI, Search Console, and the CrUX API — that part is well-established, not lab scores. What isn’t publicly documented is a 1:1 mapping between the exact number a public CrUX surface shows you and the literal internal value Google’s ranking systems read for that page — treat the public figure as the best available proxy for the signal, not a verified readout of it. Either way, it’s a real but modest signal. John Mueller has called it “more than a tie-breaker, but it also doesn’t replace relevance,” and, around the 2024 docs update, “it’s not going to make your site’s rankings jump up.” Google’s own page-experience docs now say “trying to get a perfect score just for SEO reasons may not be the best use of your time.” For the full treatment — thresholds, the three metrics, and how much weight to give it — see the Core Web Vitals hub.

A note on Bing

Bing hasn’t published documentation positioning these performance tools as ranking factors the way Google has; Core Web Vitals is primarily a Google construct. Bing Webmaster Tools does surface a Core Web Vitals overview, and underlying UX/speed improvements benefit you across all search engines — but the toolchain on this page is Google’s.

Where to go next

This hub is the map; each tool has its own deep dive nested under it:

• Google Lighthouse — the lab audit engine: the four categories, how the weighted 0–100 Performance score is built, why it throttles and varies, and why it’s a diagnostic rather than a ranking input.
• PageSpeed Insights (PSI) — the two-datasets-in-one-UI tool: the CrUX field section vs. the Lighthouse lab section, the Passed/Failed CWV Assessment, the data fallback, and the PSI API for bulk testing.
• Chrome UX Report (CrUX) — the real-user field dataset: opt-in Chrome coverage, the 28-day p75 window, origin vs. URL data, why pages show “No data,” and the six ways to access it (including CrUX Vis after the Dashboard’s deprecation).

For the metrics these tools measure — Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift, plus Total Blocking Time and Speed Index — and the thresholds Google uses, start at the Core Web Vitals hub.

AI summary

A condensed take on the Advanced version:

• Three tools, two kinds of 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. = lab; 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; 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. = both in one UI. The first question for any number: lab or field?
• Google ranks on field dataPerformance metrics captured from real users, not lab tests. (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.), not lab scores. Field data is what you prioritize on; lab data is for debugging.
• 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 a simulated audit (Slow 4G, 4× CPU) scoring 0–100 — Performance (Lighthouse 10 weights, versioned and checkable, not permanent) = TBTTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital. 30%, 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. 25%, 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. 25%, 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. 10%, Speed IndexSpeed Index measures how quickly content is visually displayed during page load — the average time at which visible parts of the page appear, scored in seconds (lower is better). It's a lab-only Lighthouse metric, not a Core Web Vital and not a ranking factor. 10%. Bands: 0–49 red / 50–89 orange / 90–100 green. It can’t measure INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. (uses TBTTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital. as a proxy), varies run-to-run, and is not a ranking signal. As of Lighthouse 13.3 (May 2026) there’s an experimental fifth category, Agentic Browsing — pass/fail checks for AI-agent readiness, separate from the 0–100 score.
• CrUX = opted-in Chrome users (no iOS Chrome, no Edge/Safari/Firefox) at p75 over a 28-day rolling window; the dataset Google Search ranks on. A fix takes ~30 days to show. In my January 2022 Ahrefs sample, only ~11.9% of 43.66M unique Site Audit pages had a CrUX metric; ~21.2% of measured pages passed CWV. The Looker Studio CrUX Dashboard was deprecated Nov 2025 → use CrUX Vis.
• 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. shows CrUX field data on top (the Passed/Failed CWV Assessment that matters for SEO) and a Lighthouse lab run below (the 0–100 score, which is NOT a ranking factor). Public URLs only; works on competitors.
• Decision rules: field for assessment, lab for diagnosis; site-wide → Search Console, individual URLs → PSI; login-gated pages → Lighthouse in DevTools.
• Beyond the three: DevTools’ live metrics/trace can capture a real INP as you interact; Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. groups similar URLs rather than tracing one page; synthetic monitoring re-runs checks on a schedule/CI; private RUM covers your own full visitor population (and can legitimately disagree with CrUX). A ranked “best tools” roundup answers a different question than this hub — run your own URL through a public test first.
• Ranking caveat: Google documents CWV as a ranking-systems input and CrUX as the dataset behind public CWV reporting — that’s confirmed. There’s no public proof the exact number a public CrUX surface shows is the literal internal per-page value Google’s ranking systems read; treat it as the best public proxy, not a verified readout.
• Workflow: GSC (find failing groups) → PSI (confirm at page level) → Lighthouse/DevTools (diagnose + fix) → wait ~30 days → re-check field.

Official documentation

Primary-source documentation from Google (and a note on Bing).

Google — the tools

• Lighthouse overview — what 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, what it audits, and where to run it.
• Lighthouse performance scoring — the metric weights, score bands, and why the score varies.
• Lighthouse agentic browsing scoring — the experimental 5th category (shipped in 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. 13.3, May 2026): pass/fail agent-readiness checks, separate from the 0–100 score.
• Chrome DevTools Performance panel reference — live metrics and recorded traces for local, interaction-driven measurement (including INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good.).
• PageSpeed Insights — About — PSIPageSpeed 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. combines Lighthouse lab data with 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.; score bands.
• Using CrUX in PageSpeed Insights — how the field section works and the Passed/Failed assessment.
• Chrome UX Report (CrUX) overview — the dataset, its role in 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., and the access surfaces.
• CrUX methodology — who’s eligible and which platforms are included.
• CrUX API — the 28-day rolling average and the p75 definition.
• CrUX Vis — the visual trend tool that replaced the deprecated Dashboard.

Google — lab vs field & ranking

• Lab and field data differences — Philip Walton on what each is and which to prioritize.
• Core Web Vitals tools (web.dev) — Google’s own overview of the tooling.
• Understanding Core Web Vitals and Google Search results — how CWV aligns with ranking systems.
• Understanding page experience in Google Search — the “perfect score… may not be the best use of your time” framing.

Bing / Microsoft

• Bing hasn’t published guidance positioning these performance tools as ranking factors; Bing Webmaster ToolsMicrosoft's free portal for monitoring and improving how a site appears in Bing search — the peer to Google Search Console, plus IndexNow instant indexing, richer backlink data, and keyword volumes. Because Bing's index also feeds Microsoft Copilot, it doubles as a window into AI-search visibility. surfaces a 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. overview, but CWV remains primarily a Google construct. See Bing Webmaster Tools help for its general guidance.

Quotes from the source

On-the-record statements from Google. Each link is a deep link that jumps to the quoted passage on the source page.

Google — what each tool is

• “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 an open-source, automated tool to help you improve the quality of web pages.” — Chrome for Developers docs. Jump to quote
• “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) reports on the user experience of a page on both mobile and desktop devices, and provides suggestions on how that page may be improved.” Jump to quote
• “The Chrome User Experience 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.… is a dataset that reflects how real-world Chrome users experience popular destinations on the web.” Jump to quote

Google — lab vs field, and which Google ranks on

• “Real-user experience data in PSI is powered by the Chrome User Experience 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.) dataset.” Jump to quote
• “CrUX data is used by Google Search to inform 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 factor.” Jump to quote
• “If you have both field dataPerformance metrics captured from real users, not lab tests. and lab data for a given page, field data is what you should use to prioritize your efforts.” — Philip Walton, web.dev. Jump to quote
• “The data in the Chrome UX Report is a 28-day rolling average of aggregated metrics.” Jump to quote
• “trying to get a perfect score just for SEO reasons may not be the best use of your time.” — Google Search Central, page-experience docs. Jump to quote

John Mueller, Google (via secondary coverage)

• “It is a ranking factor, and it’s more than a tie-breaker, but it also doesn’t replace relevance.” On 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. as a ranking signal. Read the coverage
• “it’s not going to make your site’s rankings jump up.” Around the March 2024 page-experience docs update. Read the coverage

Web performance tools — cheat sheet

The three tools at a glance

Fast facts

• Google ranks on field dataPerformance metrics captured from real users, not lab tests. (CrUX), not the lab score. The PSI 0–100 number is not a ranking input.
• Lighthouse Performance weights (Lighthouse 10, versioned — check before citing): TBTTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital. 30%, 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. 25%, 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. 25%, 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. 10%, Speed IndexSpeed Index measures how quickly content is visually displayed during page load — the average time at which visible parts of the page appear, scored in seconds (lower is better). It's a lab-only Lighthouse metric, not a Core Web Vital and not a ranking factor. 10%. Bands: 0–49 red / 50–89 orange / 90–100 green. Lighthouse 13.3+ (May 2026) adds an experimental 5th category, Agentic Browsing (pass/fail, not part of the 0–100 score).
• Lighthouse can’t measure INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. — it uses TBTTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital. as a proxy. DevTools’ live metrics screen can observe a real INP, since you’re generating the interaction.
• CrUX is Chrome-only, opt-in (no iOS Chrome, no Edge/Safari/Firefox), p75, 28-day window, ~2-day lag → a fix takes ~30 days to show.
• Only ~11.9% of 43.66M unique Site Audit pages in my January 2022 sample had a CrUX metric; ~21.2% of measured pages passed CWV (my Ahrefs CWV data study).
• CrUX Dashboard deprecated Nov 2025 → use CrUX Vis (cruxvis.withgoogle.com).
• Field for assessment, lab for diagnosis. Site-wide → Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance.; individual URLs → PSI; login-gated → Lighthouse in DevTools.

Web-performance measurement mistakes

Reporting a Lighthouse score as Google’s ranking input

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 a lab diagnostic. Google uses 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. for 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, so label the score for what it is.

Using field data to diagnose a line of code

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. tells you that real users have a problem, but not the exact implementation cause. Reproduce the affected journey in DevTools or 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. after finding the weak field segment.

Comparing unlike test conditions

A warm desktop run and a cold throttled mobile run answer different questions. Keep tool, location, device profile, cache state, and journey consistent for before/after comparisons.

Optimizing the aggregate while ignoring page groups

An origin-level pass can hide a slow template, and an origin-level failure can hide healthy pages. Start broad, then segment by URL pattern and experience.

Resolve common tool disagreements

PageSpeed Insights shows field data for the origin, not the URL

Likely cause: the URL lacks enough eligible 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. data. Fix: read the scope label and use origin data only as context, then add RUM or 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. groups for page-level decisions. Confirm: the report clearly identifies which scope each value represents.

Lighthouse changes every time it runs

Likely cause: lab results vary with network, CPU, cache, server response, and third-party activity. Fix: standardize conditions and compare several runs rather than one score. Confirm: the same opportunity persists across the run set.

Search Console is poor while a local test is good

Likely cause: the local lab does not represent real devices, locations, or longer journeys. Fix: use the field report to identify the affected group, then reproduce that scenario in a diagnostic tool. Confirm: the lab trace explains the field segment’s bottleneck.

A fix is visible in Lighthouse but not CrUX

Likely cause: 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 immediate while 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. uses a rolling field window. Fix: validate with controlled lab runs and your own RUM first, then allow the public field window to update. Confirm: RUM improves before the CrUX trend follows.

Test yourself: web performance tools

Five quick questions on the three tools and lab vs field dataPerformance metrics captured from real users, not lab tests.. Pick an answer for each, then check.

Changelog