PageSpeed Insights analyzer: interpret public-page performance

How to use this tool

1. Enter the complete public URL you want to examine, including https:// or http://.
2. Select the mobile or desktop strategy. Keep the strategy unchanged when comparing repeated runs.
3. Start the analysis and wait for the response. If the tool is not enabled, use the direct PageSpeed Insights option shown in the interface.
4. Check the returned URL, fetch time and any cache notice before interpreting the values.
5. Review the lab results and any available real-user section separately, then investigate the most relevant finding.

Use public pages only. Do not submit URLs containing passwords, access tokens, private document identifiers or other information you do not want sent to an external service. The analyzer does not use your browser's authenticated session to reproduce a private account page.

About the results

When enabled, the analyzer sends the submitted URL through this site's server to Google's PageSpeed Insights API. The site briefly caches results and uses a short-lived per-IP request counter to limit abuse. This is different from the tools that calculate entirely in your browser.

Lighthouse lab results describe a simulated run and can vary with the tested environment and page behavior. Field results, when supplied, describe aggregated eligible real-user experiences over a historical collection period. Running another lab test does not create new historical field data.

Google's API documentation announces plans to stop including CrUX field data in the PageSpeed Insights API and recommends the dedicated CrUX APIs instead. Accordingly, field data availability depends on the response and the site's integration. An absent field section must not be interpreted automatically as a failed Core Web Vitals assessment or merely a low-traffic page.

Use the PageSpeed Insights guide for a fuller explanation of the report. The analyzer summarizes returned information; it does not certify that a page is fast, accessible, secure or eligible for a particular search result.

Why is real-user data missing or shown for the origin?

A page may not have enough eligible samples, or the requested data may not be present in the API response. Where an origin fallback is available, it combines experiences across that origin rather than measuring only the requested URL.

Check the scope label before applying the result to a template. Use the field versus lab guide to separate coverage limits from a genuine experience problem. Do not fill missing metrics with zeros.

Why did the score change between runs?

Page content, third-party activity, server response and test conditions can vary. Compare the underlying metric values, Lighthouse version, device strategy and important diagnostics rather than relying on one colored score.

A cached response may repeat an earlier analysis until it expires. Read the displayed cache and fetch information. When evaluating a deployment, retain comparable runs and confirm that the returned page represents the intended version.

What should I do if the request fails?

Check that the URL is public and reachable, then review the displayed error. Rate limits, timeouts, disabled configuration and an upstream service failure are different conditions. A failed test is not itself a performance score.

Avoid repeatedly resubmitting while a rate limit applies. Once a valid report is available, choose a specific next step, such as identifying the LCP element or inspecting document latency. The performance checklist can track that work without treating every recommendation as equally important.