Google Lighthouse

TL;DR — 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 free Google tool that grades a web page from 0 to 100 on things like speed and accessibilityWeb accessibility means designing sites so people with disabilities can use them, per the W3C's WCAG guidelines. It overlaps with SEO in specific, checkable ways — alt text, heading structure, descriptive link text, captions, and page speed all serve both audiences — but Google has said accessibility itself is not a ranking factor, and most WCAG success criteria (keyboard focus order, ARIA live regions, form labels) have no SEO effect at all.. It runs the page in a slowed-down “lab” — a pretend slow phone on a slow network — so the score is often lower than your site feels. It’s a great to-do list for improvements, but a high score doesn’t move you up in Google’s rankings.

What Lighthouse is

Google Lighthouse is a free, open-source tool from the team behind Chrome. You point it at a URL, it runs a series of checks on the page, and it hands you a report card with scores in four areas: Performance (how fast the page loads), Accessibility (can people with disabilities use it), Best Practices (general web hygiene), and SEO (basic search-friendliness checks).

Each score runs from 0 to 100, with color bands so you know at a glance how you did:

• 0–49 is red — poor
• 50–89 is orange — needs improvement
• 90–100 is green — good

The one thing to understand first

Lighthouse tests your page under fake, slowed-down conditions — roughly a mid-tier phone on a slow 4G connection. It does this on purpose, so it can catch problems that real users on slower devices would feel.

That’s why you can run Lighthouse on a site that loads instantly on your fast laptop and still see a Performance score of 55. You’re not seeing what you experience — you’re seeing what a budget phone on a mediocre network would experience. Useful information, but not the same thing.

Lighthouse is not PageSpeed Insights (exactly)

You’ve probably seen Lighthouse without knowing it. When you run a page through 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. (the web tool at pagespeed.web.dev), the “lab” scores it shows you are Lighthouse. 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. just wraps Lighthouse and adds a second set of numbers from real users (called field dataPerformance metrics captured from real users, not lab tests., or the Chrome UX Report). More on that distinction in the Advanced version.

The big myth to drop

A perfect Lighthouse score does not mean top rankings. Lighthouse is a helpful tool for finding things to fix, but the score itself isn’t what Google uses to rank you. The performance numbers Google actually cares about for ranking come from real users, not from Lighthouse’s lab. Chasing a 100 is great for your visitors — just don’t expect it to be a rankings cheat code.

Want the metric weights, why scores jump around between runs, and exactly how Lighthouse relates to 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.? Switch to the Advanced tab.

TL;DR — 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 that audits a page in lab conditions (simulated Slow 4G + 4× CPU throttle) and scores Performance, AccessibilityWeb accessibility means designing sites so people with disabilities can use them, per the W3C's WCAG guidelines. It overlaps with SEO in specific, checkable ways — alt text, heading structure, descriptive link text, captions, and page speed all serve both audiences — but Google has said accessibility itself is not a ranking factor, and most WCAG success criteria (keyboard focus order, ARIA live regions, form labels) have no SEO effect at all., Best Practices, and SEO — PWA was dropped in Lighthouse 12. The Performance score is a weighted average of five lab metrics: 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’s lab data, so it is not 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. ranking signal, 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. the way the field does (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), and it varies run-to-run. It powers the lab half of 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 adds 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. A 100 doesn’t buy rankings.

What Lighthouse actually is

Google’s own one-liner is the cleanest definition: “Lighthouse is an open-source, automated tool to help you improve the quality of web pages.” The mechanics are just as simple — “give Lighthouse a URL to audit, it runs a series of audits against the page, and then it generates a report on how well the page performed.”

It scores four categories today: Performance, Accessibility, Best Practices, and SEO. If you’ve read older guides that say five, they’re out of date — the PWA category was removed in Lighthouse 12 (around 2024), following Chrome’s updated installability criteria. So if a blog post is still citing a PWA score, that’s your tell it predates the current version.

The crucial framing is one word: lab. Lighthouse loads your page in a controlled, simulated environment, not from your real visitors. That single fact explains almost every piece of confusion people have about it.

How Lighthouse Works — the lab conditions

By default Lighthouse uses simulated throttling, and it throttles aggressively. The defaults emulate roughly a mid-tier mobile device on a Slow 4G connection:

• Network: the mobile Slow 4G preset — about 150 ms latency and 1.6 Mbps down / 750 Kbps up. Google describes this as emulating “the ~85th percentile mobile connection speed even when run on much faster fiber connections.”
• CPU: a constant 4× CPU multiplier, simulating a mid-tier phone’s processor on your faster desktop hardware.

This is by design. Lighthouse isn’t trying to tell you “this is how fast your site is for everyone.” It’s stress-testing the page against a slower-than-average cohort so problems surface that your fast laptop hides. It’s why a site that feels instant to you can score 60 — you’re a high-performance MacBook on fiber; the test is a budget Android on a so-so network.

One nuance worth keeping straight: simulated throttling (the default) isn’t the same as DevTools / applied throttling. Simulated throttling models how the page would have loaded under those conditions based on an initial unthrottled observation — Google notes this approach is “both very fast and deterministic.” DevTools-style throttling actually slows down the requests, which Google says is “not a sufficient model of a slow connection.” For repeatable measurement, the default simulated mode is preferred.

The Performance score — how it’s calculated

The Performance score is “a weighted average of the metric scores.” These weights were set in Lighthouse 10 and remain the current published table. Lighthouse 13 (rolled out 2026) says so explicitly: it consolidated a set of non-scoring performance audits into shared “Insights” also used by the DevTools Performance panel, but states there are “no changes to the performance scoring” in that release — the scoring is based on the metrics below, not the audit names, and those didn’t move. Five metrics make up the score:

A few things to internalize here:

• TBT carries the most weight (30%). It’s the lab proxy for responsiveness. First Input Delay (FID) is gone, and so are older metrics like Time to Interactive and First Meaningful Paint — they’ve been retired.
• Speed Index is a Lighthouse metric, not a Core Web Vital. It still counts for 10% of the Lighthouse Performance score even though it isn’t one of Google’s ranking-relevant CWV.
• Each metric is scored against a curve, not a fixed cutoff. Lighthouse takes the raw value (usually in milliseconds) and maps it onto a log-normal distribution built from real-world HTTP Archive data. Google’s control points: the 25th percentile of that data lands at a score of 50, and the 8th percentile lands at 90. So a 90+ means you’re roughly in the top ~8% of pages on that metric — which is why the last few points are so hard to win.
• Only the metric scores move the number. The Opportunities and Diagnostics sections of the report are guidance — they tell you what to fix — but they don’t directly change the Performance score. Fixing them improves the metrics, and the metrics move the score.

Why your score changes between runs

This is the complaint I hear most: “I ran it twice and got 84 then 91 — is it broken?” No. Google is explicit: “A lot of the variability in your overall Performance score and metric values is not due to Lighthouse.” When the number jumps, it’s usually the underlying conditions shifting:

• A/B tests or different ads being served on each load
• Internet routing changes — both your local network and the longer cross-region path a request takes
• The web server itself responding at inconsistent speeds
• Testing on different hardware (a fast desktop vs. a tired laptop) — CPU throttling is relative to the host machine, so a “4×” multiplier means something different on a fast machine than a slow one
• Browser extensions that inject JavaScript or extra network requests
• Antivirus software or other background processes competing for resources

For example: run the same URL twice and one pass happens to load a heavier ad creative or catches a slower server response — that run’s audits reflect that one load, not a defect you introduced. Treat it as a single sample, not a verdict.

The right mental model, straight from the docs, is to treat performance as a distribution of scores, rather than a single number. Run it a few times — ideally in an incognito window with extensions off, on matched hardware and network conditions — and look at the range or median, not one result. When you need to compare runs later, note the Lighthouse version, run mode, and throttling method alongside the score; a score from a different version or configuration isn’t a like-for-like comparison, even if the number looks similar.

Lighthouse vs. PageSpeed Insights — the distinction that matters

These get conflated constantly, so be precise:

• Lighthouse is the engine. It produces lab data — the Performance, Accessibility, Best Practices, and SEO scores.
• PageSpeed Insights is a web UI that runs Lighthouse and adds Chrome UX Report (CrUX) field data — real 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. from anonymized real users, shown when there’s enough data for the URL or origin.

So in PSI you’re looking at two different datasets side by side. The “field data” section at the top (real users, from CrUX) is separate from the Lighthouse “lab data” section below it — and they frequently disagree. When someone says “my PageSpeed Insights score,” they almost always mean the Lighthouse Performance score, not the field data.

Lighthouse and Core Web Vitals — how they relate

Lighthouse measures some 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. in the lab: it reports LCP and CLS as lab metrics. But there’s a hard limit:

Lighthouse can’t measure INP the way the field does. Interaction to Next Paint needs real user interactions to measure — there’s no real user clicking around in a lab run. So Lighthouse uses Total Blocking Time as a lab proxy for responsiveness. TBT correlates with INP, but a passing TBT does not guarantee a passing INP for real users. They’re related, not the same.

This is the heart of the lab-vs-field gap. Field data — from CrUX, surfaced in Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. and the top of PageSpeed Insights — is what reflects real users and what feeds Google’s page experience signals. Lighthouse lab data is for debugging and catching regressions before you ship. Google’s own guidance is to “prioritize field data for understanding real-world user experiences” and use “lab data for debugging, testing features before deployment.”

Where to run it

Same engine, different surfaces:

• Chrome DevTools — built into the browser (the Lighthouse panel). Best for pages behind a login, since you can audit authenticated pages.
• PageSpeed Insights — the no-install web UI at pagespeed.web.dev; runs Lighthouse and adds CrUX field data.
• CLI — npm install -g lighthouse, then lighthouse <url>; scriptable.
• Node module — import it programmatically into your own tooling and CI.
• Lighthouse CI — the official setup for catching performance regressions on every deploy. The workflow is collect → assert → upload: collect runs Lighthouse multiple times against a URL (three runs by default) and takes the median report rather than trusting one pass; assert checks that report against thresholds you configure — set to warn or error per category or metric; upload stores the report so you can track trend lines over builds. Treat the thresholds as your team’s regression policy, not a field-data verdict or a ranking guarantee — they’re catching “this got worse,” not certifying “this is fast for users.”
• Chrome extension — exists, but DevTools is the recommended in-browser path.

The CLI and Node workflows need a local install of Chrome to drive.

TIP Use a lab audit when field data is absent—without calling it field evidence

Lighthouse can generate a controlled diagnostic run. It cannot replace the missing real-user CrUX sample or turn no data into a pass.

Keep the lab-versus-field boundary visible with my free Page Speed Test Free

1. Check whether URL- or origin-level CrUX data exists before interpreting a field verdict.
2. Run a fresh Lighthouse audit to debug under controlled conditions when field data is unavailable.
3. Save the lab baseline separately and compare like with like; wait for real traffic before claiming a field improvement.

Tap to enlarge

The result says Chrome does not have enough field data for the page, no stable CrUX sample exists for the URL or origin, and mobile and desktop are not evaluated. A separate button offers a fresh lab audit and explains that its numbers are simulated and vary between runs.

The myths worth busting

• “A 100 Lighthouse score = top rankings.” No. The Performance score is lab data; it isn’t a ranking signal. Google’s page experience signals use Core Web Vitals field data (CrUX), and even that is one lightweight signal among many — relevance and content quality dominate. Aim for a strong score because it’s good for users, not because it’s a rankings lever.
• “Lighthouse = field data / what real users experience.” No. It’s throttled lab conditions worse than most real users see. Real users have warm caches, bfcache, and varying devices. Lighthouse is a worst-case-ish stress test, not an average-user readout.
• “PageSpeed Insights is Lighthouse.” Partly. PSI runs Lighthouse for the lab section and adds CrUX for the field section. The field numbers — the ones tied to page experience — are CrUX, not Lighthouse.
• “The PWA category still counts.” It doesn’t. PWA was removed as a scored category in Lighthouse 12.

Bottom line

Lighthouse is one of the most useful free tools in technical SEOTechnical SEO is the practice of making a site easy for search engines to crawl, render, index, and (now) be eligible for AI answers. It's the foundation that lets your content and links rank — not a ranking trick of its own. and web performance — a fast, repeatable way to find what’s slowing a page down and to guard against regressions in CI. Just hold it at the right altitude: it’s a lab diagnostic, not a verdict on real-user experience and not a ranking score. Use it to find and fix; use field data (CrUX, Core Web Vitals in Search Console) to judge whether real users are actually having a good time.

AI summary

A condensed take on the Advanced version:

• 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. = open-source, automated lab auditing tool from the Chrome team. Give it a URL; it audits the page and scores Performance, AccessibilityWeb accessibility means designing sites so people with disabilities can use them, per the W3C's WCAG guidelines. It overlaps with SEO in specific, checkable ways — alt text, heading structure, descriptive link text, captions, and page speed all serve both audiences — but Google has said accessibility itself is not a ranking factor, and most WCAG success criteria (keyboard focus order, ARIA live regions, form labels) have no SEO effect at all., Best Practices, SEO. PWA was removed in Lighthouse 12 (~2024).
• Lab, not field. It loads the page under simulated throttling — roughly Slow 4G + 4× CPU — by design, to surface what slower devices/networks experience. That’s why a “fast” site can score low.
• Performance score = weighted average of five lab metrics: 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%. 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. and First Meaningful Paint are gone.
• Bands: 0–49 red (poor), 50–89 orange (needs improvement), 90–100 green (good). Metric scores are mapped onto a log-normal HTTP Archive curve, so the top points are hardest. Opportunities/Diagnostics guide fixes but don’t directly change the score.
• Scores vary run-to-run — ads, A/B tests, extensions, network/server conditions, and machine load (CPU throttling is relative to the host). Treat it as a distribution, not one number; run in incognito with extensions off, and record the Lighthouse version and settings you used.
• Lighthouse CI automates this: it collects multiple runs (three by default), takes the median, and asserts your team’s thresholds — a regression-catching policy, not a field-data verdict.
• Lighthouse ≠ 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 runs Lighthouse (lab) and adds 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. (real users). They often disagree.
• Lighthouse measures 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./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. in the lab but 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. the way the field does — 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. Field data (CrUX) is what reflects real users and feeds page experience signals.
• Not a ranking signal. A 100 doesn’t mean top rankings, and a low lab score doesn’t mean a bad real-user experience. Use Lighthouse to debug; use field data to judge.

Official documentation

Primary-source documentation from the Google Chrome team.

• 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, the audit categories, and every way to run it (DevTools, CLI, Node, 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., extension, Lighthouse CI).
• Lighthouse performance scoring — the metric weights, the 0–49 / 50–89 / 90–100 color bands, and the log-normal scoring curve.
• Lighthouse PWA audits — carries the deprecation notice for the removed PWA category.
• Lighthouse throttling (GitHub) — simulated vs. applied throttling, the Slow 4G preset, and the 4× CPU multiplier.
• Lighthouse changelog (GitHub) — the v12 changes: PWA removal, First Meaningful Paint removal, INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. elevated.
• Lighthouse scoring calculator — plug in metric values and see the resulting Performance score; handy for setting targets.

Lab vs. field (web.dev)

• User-centric performance metrics — why lab testing “isn’t necessarily reflective of how actual users experience your site.”

Quotes from the source

On-the-record statements from Google’s 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. documentation. Each link is a deep link that jumps to the quoted passage on the source page.

What Lighthouse is, and how it runs

• “Lighthouse is an open-source, automated tool to help you improve the quality of web pages.” — developer.chrome.com, Lighthouse overview. Jump to quote
• “Give Lighthouse a URL to audit, it runs a series of audits against the page, and then it generates a report on how well the page performed.” — developer.chrome.com, Lighthouse overview. Jump to quote

How the Performance score works

• “The Performance score is a weighted average of the metric scores.” — developer.chrome.com, Lighthouse performance scoring. Jump to quote
• “Once Lighthouse has gathered the performance metrics (mostly reported in milliseconds), it converts each raw metric value into a metric score from 0 to 100 by looking where the metric value falls on its Lighthouse scoring distribution.” — developer.chrome.com, Lighthouse performance scoring. Jump to quote
• On score bands: “0 to 49 (red): Poor” — with 50–89 orange (needs improvement) and 90–100 green (good). Jump to quote

Why scores vary

• “A lot of the variability in your overall Performance score and metric values is not due to Lighthouse. When your Performance score fluctuates it’s usually because of changes in underlying conditions.” — developer.chrome.com, Lighthouse performance scoring. Jump to quote

Lab vs. field

• “While testing in the lab is a reasonable proxy for performance, it isn’t necessarily reflective of how actual users experience your site.” — web.dev, User-centric performance metrics. Jump to quote

Getting a trustworthy Lighthouse read — checklist

Before you act on 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. score, make sure the number means something:

• Run it in an incognito window with extensions disabled (extensions inject JS and skew the score).
• Run it multiple times and look at the range — treat it as a distribution, not a single number.
• Confirm you’re comparing the same form factor each time (mobile vs. desktop — the throttling differs).
• Know which dataset you’re reading: lab (Lighthouse) vs. 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.) in 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.. Don’t mix them.
• For ranking/page-experience questions, look at field dataPerformance metrics captured from real users, not lab tests. (Core Web Vitals in 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. / 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 the Lighthouse lab score.
• Remember 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. the way the field does — 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. is a proxy, not a guarantee.
• Fix from the Opportunities/Diagnostics lists, but verify the change by watching the metric move (only metrics change the score).
• For repeatable measurement in automation, use Lighthouse CI with budgets rather than eyeballing one-off runs.
• Control what the page shows on load: cookie/consent banners, login state, and cache (cold vs. warm) all change the audits that fire — pick one state and be consistent about it.
• Watch for non-deterministic content — A/B tests, rotating ads, and other third-party scripts can serve a different payload on every run and swing the score independent of anything you changed.
• Let the page actually finish loading before triggering the audit (or use a mode that waits for it) — cutting a run off early misreads the page.
• Record the Lighthouse version and the run settings (mode, throttling method, device) alongside the score — a “same” score from a different version or config isn’t actually comparable.
• Ignore any guide still scoring a PWA category — that’s removed in Lighthouse 12.

Lighthouse Performance score — cheat sheet

The five metrics and their weights (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. 10 weighting)

Retired / removed: 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., Time to Interactive, First Meaningful Paint.

Score color bands

Mapped onto a log-normal HTTP Archive curve: ~25th percentile → 50, ~8th percentile → 90. The last few points are the hardest to win.

Default lab conditions

• Network: mobile Slow 4G (~150 ms latency, ~1.6 Mbps down / 750 Kbps up)
• CPU: constant 4× multiplier (mid-tier mobile on desktop hardware)
• Throttling: simulated by default (fast, deterministic), not DevTools/applied

Lighthouse vs. 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.

Fast facts

• Categories today: Performance, Accessibility, Best Practices, SEO (PWA removed in Lighthouse 12).
• It’s not a ranking signal. A 100 ≠ top rankings.
• 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. like the field does — uses TBT as a proxy.
• Scores vary run-to-run — that’s expected.

Ways to run Lighthouse (and related tools)

• Chrome DevTools — 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. panel — built into Chrome; best for auditing pages behind a login.
• 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) — no install; runs Lighthouse and adds 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. alongside it.
• Lighthouse CLI — npm install -g lighthouse, then lighthouse <url>; scriptable, needs a local Chrome.
• Lighthouse Node module — drop it into your own tooling programmatically.
• Lighthouse CI (@lhci/cli) — run Lighthouse on every deploy, set budgets, and fail the build on regressions. The right tool for keeping a score from silently sliding.
• Lighthouse scoring calculator (scorecalc) — plug in metric values to see the resulting Performance score and set realistic targets.
• Chrome extension — available, but DevTools is the recommended in-browser route.

For real-user (field) data to pair with these lab tools, look at the Core Web Vitals report in 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. and the 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 section in PageSpeed Insights.

Lighthouse habits that create false confidence

• Chasing 100 as the business goal. A perfect lab score is not a ranking boost and can distract from 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. and real user outcomes. Use the report to find bottlenecks, then verify that users benefited.
• Treating one run as a verdict. 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 test and naturally varies. Run it several times under the same conditions and look for a consistent pattern rather than reacting to one score.
• Calling lab 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. the same thing as field INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good.. 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. is a useful lab proxy for main-thread blocking; INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. measures real interactions in the field. A good TBT is evidence, not proof, that INP is good.
• Fixing every audit in listed order. Opportunity estimates overlap, and some audits have little impact on the page’s actual bottleneck. Start with the trace, the largest weighted metrics, and the resources responsible for them.
• Comparing mobile and desktop scores directly. Their emulation profiles and scoring distributions differ. Compare like with like.

Lighthouse score changes between runs

Symptom: The same page moves between color bands without a deployment.

Likely cause: Variable server response, third-party scripts, shared machine load, or different test settings changed the synthetic run.

Fix and confirmation: Match the URL, device profile, throttling, cache state, and test location; run several tests; then compare the median trace and metric timings.

Field Core Web Vitals pass but Lighthouse is red

Symptom: 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. field dataPerformance metrics captured from real users, not lab tests. passes while 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. Performance score is poor.

Likely cause: The two sections measure different populations: 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. summarizes real users over time, while Lighthouse runs one simulated page load.

Fix and confirmation: Treat the field assessment as the user outcome and use the lab trace to reproduce and diagnose a slow-device scenario. Confirm any fix in both repeated lab runs and the next field-data reporting window.

Lighthouse cannot measure INP

Symptom: The report shows 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. but no lab INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. value.

Likely cause: INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. requires real interactions across a page visit; a navigation-only Lighthouse run has no representative interaction history.

Fix and confirmation: Use 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. and the trace to find long tasksAny main-thread task over 50 ms — the primary cause of INP regressions. in the lab, then measure INP with field data or an interaction-focused recording.

An audit persists after the obvious fix

Symptom: Lighthouse still flags an asset after it was optimized or removed.

Likely cause: A cached response, another template, a third-party copy, or a different request in the chain still triggers the audit.

Fix and confirmation: Test the exact deployed URL with a cold cache, open the audit’s affected-resource list, and map each listed request back to its owner.

Test yourself: Google Lighthouse

Five quick questions on 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. data and scoring. Pick an answer for each, then check.

Resources worth your time

Official

• Lighthouse overview — the definitive what/how/where-to-run.
• Lighthouse performance scoring — weights, bands, and the scoring curve.
• Lighthouse throttling docs (GitHub) — the lab conditions in detail.
• Lighthouse scoring calculator — reverse-engineer the metric targets for a score.
• User-centric performance metrics — the lab-vs-real-users argument, from Google.

Where 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. fits

• Pair the lab score with field dataPerformance metrics captured from real users, not lab tests.: the 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. in 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. and the 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. section of 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.. Lab finds the problems; field tells you whether real users feel them.

From around the industry

• Differences between field data and lab data (web.dev) — Google’s own breakdown of when to trust lab vs. field numbers and why they diverge.
• Core Web Vitals (web.dev) — the canonical reference on which 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. metrics Lighthouse can and can’t measure, including the INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. gap.
• Largest Contentful Paint (web.dev) — deep dive on 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. thresholds and why lab and field readings frequently disagree.
• Lighthouse CI on GitHub — official repo and setup guide for integrating Lighthouse into automated CI/CD pipelines.
• HTTP Archive Web Almanac — Performance chapter — annual data on real-world Lighthouse scores and 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. pass rates across millions of pages; useful for benchmarking your scores against the web at large.
• web.dev — Measure page performance — Google’s recommended starting point for pairing Lighthouse results with field data tools.

Numbers worth citing

• Performance score weights (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. 10): 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%. Source
• Score bands: 0–49 red (poor), 50–89 orange (needs improvement), 90–100 green (good). A 90 corresponds to roughly the 8th percentile of HTTP Archive data; a 50 to the 25th percentile. Source
• Default throttling: mobile Slow 4G (~150 ms latency, ~1.6 Mbps down) plus a 4× CPU multiplier — emulating roughly the ~85th percentile mobile connection. Source
• Categories: four today (Performance, AccessibilityWeb accessibility means designing sites so people with disabilities can use them, per the W3C's WCAG guidelines. It overlaps with SEO in specific, checkable ways — alt text, heading structure, descriptive link text, captions, and page speed all serve both audiences — but Google has said accessibility itself is not a ranking factor, and most WCAG success criteria (keyboard focus order, ARIA live regions, form labels) have no SEO effect at all., Best Practices, SEO) — PWA removed in Lighthouse 12 (~2024). Source

Lighthouse

Lighthouse 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.

Related: PageSpeed Insights, Core Web Vitals, TBT

Lighthouse

Lighthouse is an open-source, automated auditing tool built by the Google Chrome team. You give it a URL, it runs a battery of audits against the page under controlled, throttled conditions, and it generates a report with scores in four categories: Performance, AccessibilityWeb accessibility means designing sites so people with disabilities can use them, per the W3C's WCAG guidelines. It overlaps with SEO in specific, checkable ways — alt text, heading structure, descriptive link text, captions, and page speed all serve both audiences — but Google has said accessibility itself is not a ranking factor, and most WCAG success criteria (keyboard focus order, ARIA live regions, form labels) have no SEO effect at all., Best Practices, and SEO. (A fifth category, PWA, was removed in Lighthouse 12 around 2024.) Scores fall on a 0–100 scale with three color bands: 0–49 red (poor), 50–89 orange (needs improvement), and 90–100 green (good).

The Performance score is a weighted average of five lab metrics — in Lighthouse 10’s weighting that’s Total Blocking TimeTotal 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%), 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. (25%), 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. (25%), First Contentful PaintFirst 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%), and 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%).

The most important thing to understand: Lighthouse collects lab data. It loads the page in a simulated environment (roughly Slow 4G plus a 4× CPU throttle), not from real users. That makes it great for debugging and catching regressions, but the Performance score is not 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. ranking signal — that comes from real-user field dataPerformance metrics captured from real users, not lab tests. in the Chrome UX Report. Lighthouse is the lab engine inside 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., which layers 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 data on top of it. Because local conditions vary, Lighthouse scores move run-to-run; treat them as a range, not a single number.

Related: PageSpeed Insights, Core Web Vitals, TBT

Changelog