Website Management Tools

Page Speed Test

Submit a URL and the test calls Google PageSpeed Insights, which runs Lighthouse on the page and returns a performance score plus Core Web Vitals such as LCP and CLS.

Website Management ToolsBrowser ready/page-speed-test

Step by step

How to use the Page Speed Test

Paste the page URL into the Page URL field
Click Test page speed to run Google PageSpeed Insights
Read the Lighthouse performance score for the page
Review the Core Web Vitals and flagged loading issues

Pro tip: Test a real content URL, not the homepage, to see speed problems most visitors actually hit.

What the test runs

This tool is a front end for Google's PageSpeed Insights API, which executes a Lighthouse audit on the URL you provide. It does not estimate speed from markup — it asks Google to actually analyze the page and then reports what comes back. You can run the audit with a mobile or desktop strategy, with mobile used by default because that is how Lighthouse simulates the more constrained device profile.

The headline is the performance score out of 100. Below it the lab metrics table lists the Lighthouse measurements: First Contentful Paint, Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift, Speed Index, and Time to Interactive.

Lab metrics and field data

The lab metrics come from a single simulated Lighthouse run, so they describe one controlled load rather than your real users. When Google has enough real-world data for the page or origin, the response also includes a Field data section from the Chrome User Experience Report, showing how actual visitors experienced metrics like LCP, INP, CLS, and TTFB, each rated Fast, Average, or Slow.

When Lighthouse identifies meaningful savings, a Top opportunities list appears with the largest items first, such as reducing unused JavaScript or properly sizing images.

Quota limits and variability

Because every check spends a call against Google's PageSpeed Insights API, the tool can be rate-limited or quota-limited, especially during busy periods, and a request can return an error or time out before Lighthouse finishes. If that happens, waiting a moment and trying again usually resolves it. Scores also genuinely vary between runs: Lighthouse simulates load conditions, so two back-to-back tests of the same URL can differ by several points without anything changing on the page. The lab metrics describe one controlled load, not a guarantee of what every visitor sees.

Making sense of the metrics

Largest Contentful Paint (LCP) — when the main content finishes rendering; a core loading metric.
Cumulative Layout Shift (CLS) — how much the layout jumps as it loads; a core stability metric.
Total Blocking Time (TBT) — the lab stand-in for responsiveness, closely tied to the field metric INP.
First Contentful Paint and Speed Index — how quickly the first and bulk of content appear.
Time to Interactive — a rough point at which the page becomes reliably usable.

Where it fits in a workflow

Spot-checking a page's mobile performance before and after a speed change.
Reading the Top opportunities list to find the largest, most concrete wins first.
Comparing how the same page scores on mobile versus desktop profiles.
Checking whether real visitors fall in the Fast band using the field-data section when it appears.
Validating that a heavy hero image or third-party script is actually hurting LCP or TBT.

Getting a reliable read

Run the test a few times and look at the range, not a single number.
Compare mobile and desktop separately, since the simulated device profiles produce different scores.
Trust the field data section, when present, over lab metrics for how real visitors actually experience the page.
Fix the top opportunity first, then re-test, rather than chasing several changes at once.

Common mistakes to avoid

Reacting to a single run — a few points of swing between identical tests is normal, not a regression.
Comparing a mobile score against a desktop one; they use different simulated devices and are not interchangeable.
Treating the lab number as your real users' experience when field data is present and tells a fuller story.
Expecting field data on every URL — new or low-traffic pages often have none, which is not an error.

Privacy note

You submit a URL and an optional mobile or desktop choice. That URL is passed to Google's PageSpeed Insights API, which fetches and audits the page; the results are returned to you and are not stored here. Only publicly reachable URLs can be tested, since Google must be able to load the page anonymously.

Worked examples

Three real pages, three verdicts

A minimal page on mobile

Input: https://example.com (strategy: mobile)

Output: Performance 100/100 · LCP 960 ms · CLS 0.00 · Data: Real-user (CrUX). Lab metrics: FCP 0.8 s, LCP 0.8 s, TBT 0 ms, CLS 0, Speed Index 0.8 s, Time to Interactive 0.8 s. Top opportunities: none listed.

Measured 2026-07-17. example.com is a ~0.5 KB static page with no JavaScript, so a perfect score with an empty opportunities list is the honest result. Lighthouse simulates load, so lab figures move a few points between runs; the headline LCP here is real-user CrUX data.

Lab and field disagreeing on the same page

Input: https://developer.mozilla.org/en-US/docs/Web/HTML (strategy: mobile)

Output: Performance 84/100 · LCP 1.2 s · CLS 0.00 · Data: Real-user (CrUX). Lab metrics: FCP 2.1 s, LCP 3.9 s, TBT 0 ms, CLS 0, Speed Index 4.1 s, Time to Interactive 3.9 s. Field data (Chrome UX Report): LCP 1.2 s, INP 105 ms, CLS 0.00, TTFB 476 ms — all rated good.

Measured 2026-07-17; lab scores drift between runs and CrUX updates over a rolling 28-day window. The gap is the whole point: the simulated mobile lab run reports a 3.9 s LCP while real Chrome users see 1.2 s — which is why the field section should outrank the lab number whenever both are present.

The same URL on desktop

Input: https://developer.mozilla.org/en-US/docs/Web/HTML (strategy: desktop)

Output: Performance 100/100 · LCP 851 ms · CLS 0.05 · Data: Real-user (CrUX). Lab metrics: FCP 0.4 s, LCP 0.6 s, TBT 10 ms, CLS 0.001, Speed Index 0.5 s, Time to Interactive 0.6 s.

Measured 2026-07-17, minutes after the mobile run above on the identical URL: 84 on mobile, 100 on desktop. The two strategies simulate different devices and are not interchangeable — this pair is the reason the article says never to compare one against the other.

FAQ

Page Speed Test — what people ask

Where do these numbers come from?

Directly from Google's PageSpeed Insights API, which runs a Lighthouse audit on your URL. The tool reports Google's results; it does not compute its own performance estimate.

Why does the score change each time I run it?

Lighthouse simulates network and CPU conditions for each run, so results naturally fluctuate. Run the test a few times and consider the range rather than fixating on one score.

Why did I get a timeout or quota error?

Each run consumes a PageSpeed Insights API call, which can be rate-limited during heavy use, and Lighthouse occasionally takes longer than the request window. Waiting briefly and retrying usually clears it.

What is the difference between lab metrics and field data?

Lab metrics come from the single simulated Lighthouse run shown in the report. Field data, when available, comes from the Chrome User Experience Report and reflects how real visitors experienced the page over time.

Should I test on mobile or desktop?

Test whichever matters most to your audience, and ideally both. The strategies use different simulated devices, so a page often scores noticeably higher on desktop than on mobile.

Why is there no field data for my page?

The Chrome User Experience Report only has data for pages and origins with enough real Chrome traffic. New or low-traffic URLs often have none, so the field-data section simply does not appear — that is expected, not a failure.

What does the Top opportunities list mean?

It surfaces Lighthouse's largest estimated savings, biggest first, such as reducing unused JavaScript or properly sizing images. The items are suggestions ranked by potential impact, not a guarantee of exact time saved.

Site standards

How HighSEOTools handles data and methodology

I document how each check works, where its data comes from, and which parts are only estimates.

Editorial standards About Contact