How to Measure Site Speed and Find Improvements with Lighthouse

Lighthouse is an automated auditing tool that identifies issues and possible improvements in a web page’s performance, accessibility, best practices and search engine optimization (SEO). Analyze a page load in Chrome DevTools, trace a slow metric to the requests, files or execution tasks involved, change one thing, and measure again under the same conditions. A single score does not represent every visitor’s experience or determine a page’s search ranking.

Lighthouse and PageSpeed Insights: what is the difference?

The official Lighthouse overview describes running audits through Chrome DevTools, the command line or a Node module. Beginners can start with the panel included in desktop Chrome without installing an extension. This route is also useful for a signed-in page or a local development page.

The PageSpeed Insights documentation distinguishes lab data from field data. Lab data is a Lighthouse diagnostic generated under specific conditions. Real-user experience data comes from the Chrome User Experience Report (CrUX), covering the previous 28-day collection period. If a page has too few samples, the service may show data for the origin (the same URL scheme, host and port) or no real-user data. Having a lab result does not mean real-visitor statistics are available for that particular page.

For a quick check of a public URL, enter it in PageSpeed Insights, analyze it, and select the mobile and desktop results separately. For pages visible only after signing in, or local URLs that cannot be reached externally, use local DevTools instead of the external service. Do not submit private URLs or access tokens to an external analysis service.

A report’s measurements describe its target URL and run conditions. A demonstration using a public example URL does not measure the website publishing the guide or your own website. Keep the real-user experience section separate from the Lighthouse diagnostic section when reading a report.

Choose the page and measurement conditions first

• Target: specify the URL to test, including representative articles, listings or product pages rather than only the home page. Do not combine different templates as if they were before-and-after results for the same page.
• State: record whether this is a first or repeat visit, the sign-in state and how consent banners are handled. For a public page that requires no login, a separate profile or an incognito window can help reduce extension effects.
• Environment: record the Chrome and Lighthouse versions, mobile or desktop selection, network and CPU throttling method, and measurement time. Avoid running large downloads or other heavy work at the same time.
• Storage: Clear storage removes site storage to approximate an initial visit. It can affect login and consent state, so do not enable it casually in a session containing important work. When auditing a signed-in page, choose settings that preserve the required state and use them consistently in later comparisons.

Auditing while signed in as an administrator can load different scripts, toolbars and cache policies from those used by an anonymous visitor. Measure the public page separately when the question concerns ordinary readers. If the target is a feature for signed-in users, explicitly record that state instead.

Analyze a page load in Chrome DevTools

1. Open the page in desktop Chrome. Verify that the public address is correct, for example, and that the page has not redirected to an error screen.
2. Open DevTools, for example with F12 or Ctrl+Shift+I on Windows. If the Lighthouse tab is hidden, find it through the tab overflow menu or More tools in the DevTools menu. Menu names can differ with browser language and version.
3. For an initial page-load audit, select Navigation under Mode. Choose Mobile or Desktop under Device. Mobile mode is a lab test with selected constraints, rather than a reproduction of the performance of every real phone.
4. Select Performance under Categories, adding Accessibility, Best Practices or SEO when needed. Check storage-clearing and throttling settings and keep their values the same during comparisons.
5. Select Analyze page load, or the equivalent start button in your version. The page reloads, so save unfinished forms or other unsaved work beforehand. Avoid interacting with the page during analysis and wait for the report.
6. Check the requested URL, final URL, settings and versions. Save the report as HTML or JSON, selecting the needed format if the export menu provides that choice. Reports may contain internal addresses or diagnostic information, so consider their contents before sharing.

Choose a different mode for scenarios other than a basic load audit. The Lighthouse user-flow documentation distinguishes Navigation for one navigation, Timespan for a period that can include interactions, and Snapshot for the current page state. Do not compare Timespan or Snapshot results as if they were Navigation’s complete performance score. Consider Snapshot when the question concerns a specific state, such as accessibility while a menu is open.

Read the metrics and diagnostic clues before the score

The performance-scoring explanation describes the score as a weighted average of transformed metric values. Reducing the number of diagnostic warnings does not increase the score by a matching amount. Scores of 90–100 are shown as good, 50–89 as needing improvement, and 0–49 as poor. These bands interpret one run’s score; they do not define every acceptable delay for real users.

The TBT documentation defines a long task as one exceeding 50 milliseconds, counting the excess beyond 50 milliseconds as blocking time. TBT is not the same metric as Interaction to Next Paint (INP), which concerns responsiveness to user interactions. Check the real-user Core Web Vitals metrics—LCP, INP and CLS—separately in field data.

Expand the report’s Insights and diagnostics to find the affected elements and resources. If the LCP element is an image in the initial viewport, start with its transfer size and request timing. For large layout shifts, check whether space is reserved for images and ads. Simply lazy-loading an important first-screen image or delaying every script in the same way can harm necessary display or functionality, so identify the cause and usage first.

For deeper investigation, continue with recordings and Insights in the Performance panel, as explained in Chrome’s Lighthouse and Performance panel guidance. High Accessibility or SEO scores do not certify complete accessibility compliance or high search rankings. Keyboard use and actual content quality, among other matters outside automated checks, still need review.

Change one thing and measure again under the same conditions

1. Choose one issue with substantial user impact and a specific cause. For an oversized image in the initial viewport, for example, first experiment with an image appropriate to its displayed size.
2. Keep the original files, settings and report. Make changes locally or in a test environment, and verify that caches serve the new files after deployment. Do not hide necessary functionality or serve a different page only to the audit in pursuit of a higher score.
3. Repeat measurements with the same URL, login state, device mode and throttling settings. Compare raw metrics and the range and median of repeated runs rather than one best score. If you choose five runs per condition, for example, use that count both before and after the change.
4. Check that the target metric improves and that the layout, buttons, forms and keyboard interactions still work. If the change does not help or breaks functionality, restore the saved files and settings and investigate another cause.

The measurement-variability guide explains that network, device, server and page changes can alter scores without a code change. Ad and consent-banner states are also comparison conditions. Record the date, URL, tool versions, settings, metrics and change in the report, and evaluate real-user metrics after enough collection time and samples are available.

When analysis fails or results differ substantially

If a page fails to load, access is blocked, or redirects fail, check the final URL and a normal HTTP response before interpreting a score. Do not remove authentication to expose a private page to an external test. For local measurement, check login and storage-clearing settings. If extensions may be involved, repeat the same target in an environment with less extension influence.

A difference between PageSpeed Insights and your PC’s score is not automatically a failure. First compare Lighthouse versions, server access paths, device and throttling settings, and cookie state. Do not try to make mobile and desktop scores match; compare before-and-after changes within each condition and consider the metrics of real visitors.