Lighthouse Test

About this tool

Lighthouse Lite Audit asks the Google PageSpeed Insights API to run Lighthouse on a public webpage. Enter a URL, choose the Mobile or Desktop strategy, and click Run Audit. The URL is sent from the UtilityKit backend to Google, which loads the page on its own servers. Results show four score circles colored green (90 and up), orange (50-89) or red (under 50), but only Performance is filled in: the request does not ask PageSpeed for the SEO, Accessibility or Best Practices categories, so those three circles currently read 0. Below the scores, up to 10 audits scoring under 90 are listed with a score badge, the audit title and the first sentence of Google's description. The JSON Report button saves those scores and issues, not the full Lighthouse report. Known limitation: the page stops waiting after 10 seconds, so audits that take PageSpeed longer than that end with "Request timed out".

Why use it

• A Lighthouse performance score without opening Chrome DevTools or installing a CI plugin.

• Mobile and desktop strategies show how the page performs under each of Lighthouse's test setups.

• Color-coded score circles make a slow page visible at a glance.

• Top issues list sorts failing audits from lowest score up so you know where to focus first.

• Powered by the official Google PageSpeed Insights API, which runs Lighthouse on Google's servers.

How to use

1. Enter the full URL of the page you want to audit — it must be publicly accessible from Google's network.
2. Choose Mobile or Desktop strategy — Mobile is selected by default.
3. Click Run Audit and wait; if PageSpeed takes longer than 10 seconds the page shows "Request timed out" and you can try again.
4. Read the Performance score circle; the SEO, Accessibility and Best Practices circles currently show 0 because those categories are not requested.
5. Scroll down to the Top Issues list of up to 10 audits scoring under 90, each with its score and a one-sentence description.
6. Click JSON Report to save the scores and issues list as audit-report.json.

When it helps

• Checking a client's website before and after an optimization sprint to demonstrate measurable improvement
• Auditing Core Web Vitals before a major deploy.
• Identifying accessibility issues before a public launch.
• Comparing mobile vs desktop performance gaps on a responsive site.
• Quick sanity-check after adding third-party scripts that may slow load time.

Examples

URL: https://example.com
Strategy: Mobile

Performance circle shows the PageSpeed score (for example 72, orange); SEO, Accessibility and Best Practices show 0. Top Issues lists up to 10 audits scoring under 90, each with a score badge and one-sentence description.

URL: https://news.example.com/article-slug
Strategy: Mobile

Request timed out

Click JSON Report after an audit

{
  "scores": {
    "performance": 72,
    "seo": 0,
    "accessibility": 0,
    "bestPractices": 0
  },
  "issues": [ … ],
  "url": "https://example.com",
  "strategy": "mobile"
}

Tips

• Mobile strategy uses simulated 4G throttling (1.6 Mbps down, 750 Kbps up) and 4× CPU slowdown — desktop is unthrottled.
• Lab scores like these differ from field data (CrUX) — Google ranks on field data, which this tool does not show.
• Score 90+ is 'Good', 50-89 'Needs Improvement', <50 'Poor' per Google's official thresholds.
• Re-running back-to-back can produce slightly different scores due to network and CPU variance — average 3-5 runs for reliable numbers.
• Pages behind A/B tests may score differently each run if variants have different bundle sizes or render strategies.
• Improving Performance often improves SEO indirectly: faster pages get crawled more deeply and ranked better.

Frequently Asked Questions

Glossary

Lighthouse

Google's open-source automated tool for auditing web page quality across performance, SEO, accessibility, and best practices, available in Chrome DevTools and as a Node.js CLI.

Core Web Vitals

Google's set of three user-experience metrics — LCP, INP (formerly FID), and CLS — that affect search ranking since 2021.

LCP (Largest Contentful Paint)

The time from navigation start until the largest text or image element in the viewport is rendered. Good: ≤2.5s. Poor: >4.0s.

FID (First Input Delay)

The delay between a user's first interaction (tap, click, key) and the browser's response. Replaced by INP in 2024 but still in older reports. Good: ≤100ms.

INP (Interaction to Next Paint)

The 75th-percentile latency of all user interactions on the page during its lifetime. Replaces FID. Good: ≤200ms.

CLS (Cumulative Layout Shift)

A unitless score measuring how much visible content shifts unexpectedly during page load. Good: ≤0.1. Poor: >0.25.

FCP (First Contentful Paint)

The time from navigation start until the first text, image, or non-white pixel is painted. Good: ≤1.8s.

TBT (Total Blocking Time)

The total time the main thread was blocked (>50ms tasks) between FCP and TTI, in milliseconds. A lab proxy for INP.

TTI (Time to Interactive)

The point at which the page is fully interactive — main thread is idle for ≥5 seconds and most resources have loaded.

Headless Chromium

The Chrome rendering engine running without a UI — Lighthouse uses it to load the page, simulate device conditions, and collect metrics.

PageSpeed Insights (PSI)

Google's web service that runs Lighthouse against any public URL and returns scores plus field data from CrUX.

CrUX (Chrome User Experience Report)

A public dataset of real-user performance data from opted-in Chrome users, used by Google for Core Web Vitals ranking signals.