Lighthouse explained. The five audit categories, what each score means, and where Lighthouse fits in the Page Experience workflow.

What Lighthouse is

Lighthouse is a free, open-source automated audit tool built by the Chrome team. It opens a URL in a headless Chromium browser, simulates a mobile or desktop load on a throttled connection, runs about 200 individual checks, and produces five category scores plus a long list of diagnostic findings. It ships inside Chrome DevTools, runs the audit engine behind PageSpeed Insights, and is available as a Node CLI and a browser extension. Same engine, different surfaces.

The five categories are Performance, Accessibility, Best Practices, SEO and Progressive Web App. Each one is scored 0 to 100. Each score is a weighted composite of the underlying audits within that category. Performance is the most-discussed score because it includes lab approximations of Core Web Vitals, but the SEO and Accessibility categories are useful in their own right and the Best Practices category catches a lot of "we left console errors and broken HTTPS in production" issues that nobody else surfaces.

The thing to get straight from the first paragraph: Lighthouse is a diagnostic tool, not a ranking signal. Google's ranking systems use CrUX field data from real Chrome users for the Core Web Vitals signal. They do not use the Lighthouse score. A page with a 100 Performance score and failing field-data Vitals is still failing. A page with a 60 Performance score and passing field-data Vitals is still passing. Treat the Lighthouse number as a finger pointing at the moon: useful for direction, not the thing itself.

How Lighthouse works under the hood

Mechanically, Lighthouse does five things on every run.

1. Spin up a clean Chromium instance. No extensions, no cookies, no service workers cached from earlier sessions. This is intentional so the audit is reproducible.
2. Apply throttling. The default mobile preset throttles network to Slow 4G (1.6 Mbps down, 150ms RTT) and CPU to a 4x slowdown. The desktop preset uses faster numbers but is still throttled relative to a modern desktop.
3. Load the URL and trace the load. Chrome's tracing system captures every paint, every JavaScript task, every network request, every layout shift. The trace becomes the raw data for the audit.
4. Run about 200 individual audits against the trace. Each audit answers a specific question: did the LCP element have fetchpriority="high", did every image have a width and height, did the page have a viewport meta tag, did the document have a meta description, did the headings nest in the right order. Each audit returns pass, fail, or a measured value.
5. Compute the category scores. Each audit has a weight inside its category. Performance weights LCP heavily, weights CLS moderately, weights Speed Index lightly. The category score is the weighted sum. Accessibility is mostly binary axe-core checks. SEO is a checklist of titles, meta descriptions, crawlable links, valid HTML.

Two facts about this matter for how you read the report.

The run is reproducible but noisy. Identical inputs do not always produce identical outputs because background CPU usage on the machine varies, network conditions vary, and some audits include a randomised CPU calibration. Variance of plus or minus 5 to 10 points on Performance is normal. Always run at least three times and use the median.

The lab simulation is not your users. The default mobile throttling is meant to approximate a mid-range Android phone on a typical mobile connection. It is not literally what your users experience. Your users are on a distribution of devices and connections that Lighthouse cannot simulate. That is exactly why page speed for ranking purposes is measured on field data from CrUX, not on lab data from Lighthouse.

Running a Lighthouse audit step by step

The 60-second workflow we run on every Perth client site we audit.

1. Pull field data first

Before opening Lighthouse, open the Google Search Console Core Web Vitals report. Look at which URL groups are failing in the real world. Pick one to audit. If the GSC report says everything passes, do not run Lighthouse to "see what you can improve". Field data is the source of truth; chasing lab improvements on already-passing pages is the single most common waste of engineering time in this whole field.

2. Open Chrome incognito with no extensions

Extensions inject scripts, modify the DOM, and tank Lighthouse scores artificially. Always audit in an incognito window with extensions disabled. Press Cmd+Option+I (Mac) or F12 (Windows) to open DevTools. Click the Lighthouse panel.

3. Configure the audit

Choose Mode: Navigation (the default; audits a fresh page load). Choose Device: Mobile (the audit Google emphasises for ranking). Choose Categories: tick all five for the first run; tick only Performance for fast follow-up runs. Click Analyse page load.

4. Wait, then read the diagnostics, not the score

The audit takes 30 to 60 seconds. When it finishes, scroll past the big circular gauges at the top. The useful information lives in three sections under Performance:

• Metrics. The lab LCP, FCP, Speed Index, CLS and TBT for this run. Compare to the Core Web Vitals thresholds (LCP under 2.5s, CLS under 0.1, TBT under 200ms).
• Opportunities. Ranked list of fixes Lighthouse thinks would improve the score, each with an estimated time saving. Read these critically: some estimates are inflated. Use them as leads to investigate, not as ground truth.
• Diagnostics. Findings that did not make the Opportunities list but might be relevant: long main-thread tasks, large layout shifts, unused JavaScript, oversized images, render-blocking resources. This is where the actual debugging information lives.

For Accessibility, SEO, Best Practices and PWA, scroll to each section and read the failed audits in red. Each failed audit explains the issue and links to documentation. Fix the failures one by one. Most are quick template-level changes.

5. Run three times, use the median

Single Lighthouse runs are noisy. Run the audit three times, in three separate incognito windows if needed, and take the median Performance score. If the runs vary by more than 10 points, run two more and look at the distribution. High variance usually means something on the page is non-deterministic (a randomised A/B test, a third-party script with variable behaviour, an animation that affects layout timing).

6. Fix at the template level, not the page level

If Lighthouse flags the same hero image as the LCP bottleneck on three different product pages, fix the image-loading pattern in the product template, not on three pages individually. This is the highest-impact move in performance optimisation: one template fix improves dozens or hundreds of URLs at once. The GSC Core Web Vitals report groups URLs by template-style similarity for exactly this reason. See LCP optimisation for the image-template patterns and JavaScript SEO for the JS-template patterns.

7. Wait 28 days, then re-check field data

After you ship the fix, Lighthouse will show the improvement immediately. The GSC field-data report will show it gradually as the rolling 28-day window catches up. Resist the urge to declare victory off the lab score. The number Google uses takes a month to reflect reality.

The five audit categories

Performance

The most-discussed score. A weighted composite of five lab metrics: First Contentful Paint (10 percent), Speed Index (10 percent), Largest Contentful Paint (25 percent), Total Blocking Time (30 percent), Cumulative Layout Shift (25 percent). Note what is here and what is not. Lab LCP and lab CLS appear. INP does not, because INP measures the worst interaction across a session and cannot be calculated from a single page-load trace. Lighthouse uses Total Blocking Time (TBT) as a proxy for INP: TBT measures the sum of long main-thread tasks during load and correlates reasonably well with INP for most sites. The INP chapter covers why TBT is not a perfect substitute.

The Performance score is most useful as a diagnostic. The actual targets are the underlying metrics: LCP under 2.5s in field data, INP under 200ms in field data, CLS under 0.1 in field data. Hitting those in lab is necessary but not sufficient.

Accessibility

Built on axe-core, the open-source accessibility testing engine maintained by Deque. The audits cover automated checks only: alt text on images, sufficient colour contrast, ARIA roles used correctly, labels on form inputs, headings in the right order. The score is mostly binary (each audit passes or fails) and a high score does not mean the site is fully accessible. Automated tests can only catch about 30 percent of accessibility issues. Manual testing with a screen reader is still needed for the rest. But the Lighthouse Accessibility score is a useful floor: if you cannot pass the automated checks, the manual ones will definitely fail. See image SEO for the alt-text and alt text patterns Lighthouse expects.

Best Practices

A grab-bag of "did you remember to do this" checks: HTTPS configured properly, no console errors in production, no deprecated APIs in use, no document.write, charset declared, doctype declared, geolocation and notification permissions requested with reason. Most issues here are easy to fix and are signs of general code hygiene rather than catastrophic problems. A score below 90 usually means there are sloppy production deploys.

SEO

The smallest and most-misunderstood category. It checks about 14 things: page has a title, page has a meta description, page has a viewport meta tag, links are crawlable, robots.txt is valid, hreflang is valid, structured data is valid, document has lang attribute, anchors have descriptive text. These are technical pre-flight checks. The Lighthouse SEO score does not tell you whether your content ranks. It tells you whether the basic on-page hygiene is in place. Use it as a sanity check before launch. See the On-Page SEO pillar for the actual on-page work and title tags and meta descriptions for the high-impact parts.

Progressive Web App (PWA)

Checks whether the site qualifies as a Progressive Web App: manifest.json present, service worker registered, installable, works offline, themed correctly. Largely irrelevant for content sites and most service businesses. Useful for e-commerce and SaaS apps that genuinely want to be installable. Skip unless you are actually building a PWA. Google has been quietly de-emphasising PWA scoring in recent Lighthouse releases.

Lab data versus field data, again

This is the most important distinction in this entire chapter, so it gets repeated. Lab data is what Lighthouse produces. A simulated page load on a throttled connection, run on demand, reproducible-ish, useful for diagnosing what to fix. Field data is what CrUX produces. Aggregated measurements from real Chrome users on real connections over a rolling 28-day window, used by Google for ranking, available in GSC and the top half of PageSpeed Insights.

Lighthouse and field data can disagree dramatically.

• A site with a 95 Lighthouse Performance score and failing CrUX Core Web Vitals exists. Usually because the lab simulation does not match the actual user distribution: maybe most real users are on slower devices than the lab simulates, maybe there is a long-tail of users hitting uncached CDN edges from regional WA, maybe the page is fast on first paint but the LCP element loads via JS after a delay that the lab missed.
• A site with a 55 Lighthouse Performance score and passing CrUX Core Web Vitals exists. Usually because most real users hit cached CDN edges on fast WiFi from the metro area, so their experience is faster than the throttled lab simulation.

When the two disagree, field data wins for ranking purposes. Use Lighthouse to diagnose; use field data to decide whether you actually have a problem.

Common mistakes when using Lighthouse

The 100-score chase deserves its own paragraph. The marginal effort to move a Performance score from 90 to 100 is usually large: shaving the last 300ms off LCP, removing a 20kb third-party script that does something useful, redesigning the page to eliminate a 0.05 CLS that nobody notices. The marginal SEO benefit is zero because field data is already passing and Google does not use Lighthouse anyway. The marginal user-experience benefit is small because users already perceive the page as fast. Spend that engineering time on content, links or conversion-rate work instead.

Tools and alternatives

Where Lighthouse fits in the wider tooling picture.

• Chrome DevTools Lighthouse panel. Free. The fastest way to run an audit on any URL you have open. Good for quick checks during development.
• PageSpeed Insights (pagespeed.web.dev). Free. Runs Lighthouse on Google infrastructure and adds CrUX field data for the same URL. Less noisy than local DevTools runs. The single most useful free tool for combining lab and field data in one view.
• Lighthouse CLI (Node). Free. Scriptable. Useful for running audits on a list of URLs as part of CI/CD, archiving JSON results, comparing over time. Worth setting up if you are running a serious performance practice. See JavaScript SEO for build-time integration patterns.
• web-vitals JavaScript library. Free. The official library for measuring real-user Vitals (LCP, INP, CLS) and shipping them to GA4 or another analytics endpoint. This is how you build your own field-data dashboard. See GA4 for SEO for the integration.
• WebPageTest, DebugBear, Calibre. Paid. More-sophisticated lab tooling: waterfall traces, geographic test locations, historical monitoring, side-by-side filmstrip comparisons. Useful for large sites with serious performance requirements. Overkill for most Perth SMBs.
• Chrome DevTools Performance panel. Free. Not Lighthouse, but the next step after Lighthouse identifies an issue. Captures full timeline traces showing every paint, every JS task, every layout shift. The deep-dive tool when Lighthouse Diagnostics are not specific enough.

Perth and WA context

Three Lighthouse patterns we see across Perth and WA client work.

Marketing-team Lighthouse audits without field-data context. A common situation: a marketing team gets handed a Lighthouse Performance score of 47 by a developer or competitor analysis tool, panics, and commissions a six-week speed optimisation project. We pull the GSC Core Web Vitals report and find the site already passes field data on every URL group. The 47 number was a single noisy run on the wrong device profile. The right move was to pull field data first; the wrong move was to greenlight the project on lab data alone. We see this across legal, healthcare and real estate sites particularly often.

Sub-$400 Android phones as the actual median. The default mobile Lighthouse simulation is a mid-range device. The actual median Australian mobile visitor in 2026, particularly in regional WA and across trades and mining audiences, is often on a slower-than-simulated phone with a patchy connection. Lab passes do not always translate to field passes for these audiences. Real-device testing on a sub-$400 Pixel A or Samsung A-series device is more honest than trusting the simulator.

The agency-100 trap. An incoming Perth client shows us the "Lighthouse 100 across the board" report their previous agency produced. We pull GSC: poor field-data Vitals on the URL group that drives 70 percent of organic traffic. The previous agency had optimised the homepage to 100 because that was the URL the client and stakeholders kept refreshing. Nobody had optimised the templates that actually mattered. Fix at the template level. Field data first. Lighthouse second.

For where this fits in the wider Hub: the Core Web Vitals pillar sets the framing, Core Web Vitals explained covers the metrics themselves, LCP optimisation and INP explained cover the two highest-impact Vitals to chase, CLS fixes covers the layout-shift work, mobile usability covers the related mobile-first checks, intrusive interstitials covers the popup demotion, and HTTPS as a ranking factor covers the baseline security signal Lighthouse also checks. Cross-pillar: technical SEO, JavaScript SEO, image SEO, Google Search Console and GA4 for SEO.

For services, the speed optimisation service is the most-aligned engagement. The website audits service includes a Lighthouse pass across key templates. The SEO service uses Lighthouse as one input among many. New sites should start with the free SEO audit for a baseline. For geography see Perth services, Fremantle and Local SEO Perth.