Page Speed Test: Best Tools and How to Read the Results

Most speed tools show a score, a list of "opportunities" and a lot of color. The score is the least useful part. What matters is whether real users pass the three Core Web Vitals, which element or script is responsible when they do not, and whether your fix shows up in the field data a few weeks later. This guide is about testing and the tools; the fixes themselves have their own guide.

How to run a page speed test, step by step

This is the fastest way to answer "is this page fast, and if not, what is wrong?" without installing anything. It takes about five minutes per URL.

Step 1: run the test. Open pagespeed.web.dev, paste the full URL (including https:// and the exact path you want tested) and click Analyze. The report opens on the Mobile tab, which is the one to read first, because mobile is usually the one failing.

Step 2: read the field section. At the top, "Discover what your real users are experiencing" shows the Core Web Vitals assessment: Passed or Failed, with LCP, INP and CLS at the 75th percentile. Check the toggle between This URL and Origin; if the URL has too little traffic for its own data, you only get the origin view or nothing. Write down which metric fails.

Step 3: find the culprit in the lab section. Scroll to "Diagnose performance issues". Use the Show audits relevant to filter and pick the failing metric (LCP, TBT or CLS). For LCP, open the LCP element or LCP breakdown audit (the label depends on the Lighthouse version): it names the element and splits the time into phases such as time to first byte, load delay, load duration and render delay. For CLS, the layout shift audit lists the elements that moved.

Step 4: check desktop and the template. Switch to the Desktop tab. Then run one other URL that uses the same template (another product page, another article). If both fail the same way, the fix belongs in the template, not the page.

Step 5: confirm in a second tool. For anything that looks odd, load the page in WebPageTest or Lighthouse in DevTools. A filmstrip or waterfall usually shows the cause in a way a single score cannot.

Step 6: record a baseline. Note the URL, the date, the field values, the lab LCP element and the top two audits. That line is how you prove later that a fix worked.

Repeat for one URL per template (home, category, product, article, landing page). Five templates at five minutes each covers most of a typical site.

Page speed testing tools compared

No single page speed testing tool answers every question. Some show what real visitors experience, some simulate a load so you can debug it, and some keep running on a schedule. Here is what each one is good for.

Tool	Data	Best for	Cost	Honest limits
PageSpeed Insights	Field (CrUX) + lab (Lighthouse)	Quick test of one public URL; pass/fail for stakeholders	Free, with a free API	One URL at a time; no field data for low-traffic pages; no history
Lighthouse in Chrome DevTools	Lab	Staging, localhost and logged-in pages; before/after checks	Free	Runs on your machine, so results depend on your hardware and extensions
WebPageTest	Lab	Filmstrip, waterfall, test locations and connection speeds	Free tier and paid plans	More settings to learn; no real-user data
GTmetrix	Lab (Lighthouse-based)	Readable reports, saved history, scheduled tests	Free basic tests and paid plans	Its grade is its own, so it will not match PageSpeed Insights
Search Console Core Web Vitals report	Field (CrUX)	Whole-site status grouped by similar URLs; validating fixes	Free	Only pages with enough Chrome traffic; updates slowly
Chrome UX Report (CrUX Vis, API, BigQuery)	Field (CrUX)	Trends over months, competitor origins, large analysis	Free (BigQuery usage may be billed)	Chrome users only; no diagnosis of causes
DevTools Performance panel	Lab, plus live local metrics	Long tasks, INP debugging, layout shift sources	Free	Needs some comfort reading a main-thread trace
DebugBear and similar monitors	Scheduled lab tests, CrUX, and RUM depending on plan	Ongoing monitoring with alerts and history	Free one-off test; monitoring is paid	Costs money for continuous tracking

PageSpeed Insights (pagespeed.web.dev). Field data from the Chrome UX Report plus a Lighthouse lab run, for one URL at a time. The mobile lab run emulates a mid-range phone on a throttled connection, so scores vary a few points between runs; do not chase single-point changes. Its API is free and suits bulk checks.

Lighthouse in Chrome DevTools. Open DevTools (F12), choose the Lighthouse panel, select Navigation mode, Mobile, the Performance category, and click Analyze page load. Run it in an Incognito window so extensions do not skew the result. Use it for pages PageSpeed Insights cannot reach: staging sites, localhost, pages behind a login. Timespan mode records a period while you interact with the page, which helps with interaction problems that a page-load test misses.

WebPageTest (webpagetest.org). Lab tests from chosen locations, browsers and connection speeds, with very detailed output. The filmstrip shows what the user sees at each fraction of a second, which makes "the hero image appears last" obvious to non-engineers. The waterfall shows every request in order: look for the LCP image starting late, render-blocking CSS and JavaScript, redirect chains, and third-party scripts that load before your content. Run three or more tests and use the median.

GTmetrix. A Lighthouse-based lab tester with its own grade, filmstrip, waterfall and video. It is easy to share with non-technical colleagues, and paid plans add more test locations, devices and scheduled monitoring. Set the test location and device to match your users rather than accepting the defaults.

Search Console Core Web Vitals report. Under Experience → Core Web Vitals, Search Console groups your URLs into Good, Needs improvement and Poor for mobile and desktop, based on CrUX. It groups similar URLs together, so one issue usually maps to one template. Use it to see the whole site, prioritize by the number of affected URLs, and click Validate fix after shipping a change. Our Google Search Console guide covers the rest of the reports.

Chrome UX Report. CrUX is the dataset behind the field numbers in PageSpeed Insights and Search Console. CrUX Vis is Google's web tool for viewing its history for an origin or URL, which helps you spot when a regression started. The same data is available through the CrUX API and the public BigQuery dataset, and because it is public you can look up competitor origins too.

DevTools Performance panel. The tool for the "why" behind INP and long tasks. Its landing view shows live LCP, CLS and INP for your own session as you click around, and can show CrUX field values next to them. Record while you perform a slow interaction, then look in the main thread track for long tasks and expand them to see which function or third-party script ran. Turn on CPU throttling to approximate a mid-range phone.

DebugBear and similar monitors. Commercial monitoring tools such as DebugBear, SpeedCurve, Calibre and Pingdom run scheduled tests, keep history and alert you when a page gets slower. DebugBear offers a free one-off speed test, and its paid plans combine scheduled lab tests, CrUX data and real-user monitoring. Check each vendor's current plans; features and limits change.

Lab data vs field data

Every speed tool reports one of two kinds of data, and mixing them up causes most of the confusion around page speed.

Field data (also called real-user data or RUM) is collected from actual visitors. Google's public source is the Chrome UX Report, which aggregates anonymized measurements from Chrome users who have opted in. PageSpeed Insights and Search Console show CrUX data over a rolling 28-day window. Field data is what Google uses for the Core Web Vitals assessment. It cannot tell you why something is slow, and it takes weeks to reflect a fix.

Lab data comes from loading the page once in a controlled environment: a fixed device profile and a throttled connection. Lighthouse, WebPageTest and GTmetrix produce lab data. It is repeatable and full of diagnostic detail, so it is where you debug, but it is one synthetic visit and can disagree with the field in either direction.

	Field data (CrUX, RUM)	Lab data (Lighthouse, WebPageTest)
Source	Real Chrome users	One simulated load
Time frame	Rolling 28 days in CrUX	Right now
Measures INP?	Yes	No; Total Blocking Time (TBT) is the lab proxy
Use it to	Decide whether there is a problem	Find the cause and test the fix
Available for	Pages and origins with enough Chrome traffic	Any URL you can load

Rule of thumb: field data decides whether to work on speed, lab data decides what to change. If a page has no field data, it does not have enough Chrome traffic for CrUX; use the origin-level field data and the lab results instead.

What the page speed score means, and why tools disagree

The number in the colored circle in PageSpeed Insights and Lighthouse is the Lighthouse Performance score, from 0 to 100. It is a weighted blend of lab metrics (First Contentful Paint, Speed Index, Largest Contentful Paint, Total Blocking Time and Cumulative Layout Shift), with LCP, TBT and CLS carrying most of the weight. Lighthouse colors 90 and above green, 50 to 89 orange and below 50 red.

Three things follow from that:

The score is lab-only. It says nothing about real users. A page can score 95 and fail field INP, or score 60 and pass all three Core Web Vitals. The Core Web Vitals assessment above the score is the result Google actually uses.

Scores move between runs. Server response time, network conditions, ads and third-party scripts vary from one load to the next. A few points of difference is normal. Run the test three times and compare medians.

Different tools give different scores for the same page. Each tool tests from a different location, on a different device profile and connection, sometimes with a different Lighthouse version, and some add their own grade on top. GTmetrix's grade is not the PageSpeed Insights score, and Lighthouse on your laptop runs on your hardware. Compare a page against itself in the same tool with the same settings, not across tools.

Core Web Vitals thresholds

Google's Core Web Vitals are three metrics. Interaction to Next Paint (INP) replaced First Input Delay as the responsiveness metric in March 2024.

Metric	What it measures	Good	Needs improvement	Poor
LCP, Largest Contentful Paint	When the largest image or text block in the viewport renders	≤ 2.5 s	2.5–4.0 s	> 4.0 s
INP, Interaction to Next Paint	Delay between a click, tap or key press and the next visual update, across the visit	≤ 200 ms	200–500 ms	> 500 ms
CLS, Cumulative Layout Shift	How much visible content moves unexpectedly	≤ 0.1	0.1–0.25	> 0.25

Each metric is assessed at the 75th percentile of page loads, separately for mobile and desktop. A page passes when at least 75% of visits are "good" on all three. That is why an average that looks fine can still fail: the slowest quarter of visits decides the result.

Two supporting metrics are worth watching even though they are not Core Web Vitals. Time to First Byte (TTFB) is the server and network part of LCP; web.dev treats 0.8 s or less as good. First Contentful Paint (FCP) shows when anything appears; 1.8 s or less is good.

Google describes Core Web Vitals as part of the page experience signals its ranking systems use, while stressing that relevance and content quality come first.

Landing page speed testing

Landing pages need their own test because they break the usual assumptions. They are often new, so they have no field data yet. They are often built in a page builder with its own scripts. And paid traffic arrives with tracking pixels, consent banners and A/B testing tools that a quick test of the clean URL may not reflect.

Test the exact URL the ad or email points to. Redirects from tracking links add time before the page even starts loading. Load the full click path once in WebPageTest and look at the top of the waterfall.

Test on mobile with throttling. Most paid social traffic is mobile. Use the PageSpeed Insights mobile tab or Lighthouse mobile, not a desktop run on office Wi-Fi.

Test from where the visitors are. If the campaign targets another country, pick a nearby WebPageTest location; a page that is fast from your city can be slow across an ocean if it has no CDN.

Watch the hero and the form. On a landing page, the LCP element is usually the hero image or headline, and the most important interaction is the form or the call-to-action button. Check the LCP element in the lab report, and click through the form in the DevTools Performance panel to look for long tasks.

Plan for missing field data. Until the page has enough Chrome traffic, rely on lab tests and your own real-user monitoring.

Ongoing page speed monitoring

A one-off test tells you where you are today. Speed regresses quietly: a new tag in the tag manager, a heavier hero image, a plugin update. Monitoring catches that before it shows up as a failing Core Web Vitals report a month later. Pick the lightest option that covers your key templates.

Search Console, monthly. Free, already grouped by template, and based on the same field data Google uses. Its weakness is speed: it reflects a 28-day window, so it is a lagging indicator.

The PageSpeed Insights API on a schedule. For a weekly check of key URLs, call the API from a spreadsheet. Our guide to Google Apps Script for SEO includes a ready-made script that writes the lab score and field LCP, INP and CLS for a list of URLs into a sheet and can run on a schedule.

A monitoring tool. DebugBear, SpeedCurve, Calibre, GTmetrix paid plans and Pingdom run scheduled tests, keep charts of every run and send alerts when a page slows down. Worth it when several people ship changes to the site and nobody checks speed by hand.

Your own real-user monitoring. Google's open-source web-vitals JavaScript library reports LCP, INP and CLS from your own visitors to any endpoint you choose, including those CrUX does not cover (other browsers, and low-traffic pages with no CrUX data at all):

<script type="module">
  import { onLCP, onINP, onCLS } from 'https://unpkg.com/web-vitals@4?module';

  function send(metric) {
    navigator.sendBeacon('/rum', JSON.stringify({
      name: metric.name, value: metric.value, rating: metric.rating,
      page: location.pathname,
    }));
  }
  onLCP(send); onINP(send); onCLS(send);
</script>

In production, bundle the library instead of loading it from a CDN. Keep the default options so each metric is reported once per page view; reportAllChanges: true is for debugging.

Quick optimization test checklist

Use this as a quick optimization test before and after any release that touches templates, scripts or images.

Check	Where	Pass looks like
Core Web Vitals assessment, mobile	PageSpeed Insights, field section	"Passed" for the URL or origin
LCP element is the one you expect	PSI lab audits, filtered to LCP	Hero image or headline, not a cookie banner or late script
LCP image is not lazy-loaded	Page source or Elements panel	No loading="lazy" on the hero image
Server response	PSI or WebPageTest waterfall	TTFB is a small share of LCP; no redirect chain
Main thread on interaction	DevTools Performance panel, CPU throttled	No long tasks after clicking menus, filters or forms
Layout shifts	PSI layout shift audit	Images and ad slots have reserved space
Third-party scripts	PSI third-party audit or waterfall	Each one has an owner and a reason to be there
Desktop and a second URL on the same template	PSI desktop tab	Same result, or a clear reason why not

What to fix first

Let the test tell you the order. Start with the metric that fails in field data on mobile, on the template with the most organic traffic, and fix the cause the lab audits name for that metric.

LCP failing: look at the LCP breakdown. A long TTFB points to the server and caching; a long load delay usually means the hero image is discovered late or lazy-loaded; a long render delay points to render-blocking CSS or JavaScript.

INP failing: find the slow interaction in the Performance panel and the long task behind it, often a third-party script or a heavy event handler.

CLS failing: the layout shift audit names the elements that moved; most need reserved space through width and height attributes or a minimum height.

The detailed fixes for each of these, with code, are in our guide to web speed optimization. After you ship, rerun the same lab test to confirm the change, then check the field data three to four weeks later.

Page speed and AI crawlers

AI assistants such as ChatGPT, Perplexity and Google's AI Overviews and AI Mode build answers from pages they can retrieve. The fetchers behind them generally request raw HTML within time limits, and many do not execute JavaScript. A slow server response, or main content that only appears after client-side rendering, raises the chance that a fetch returns little usable text, so the page is less likely to be quoted or cited.

The speed work that matters most here is server-side: fast TTFB and the main content present in the initial, server-rendered HTML. A Lighthouse score will not tell you this, so check it directly: view the page source, or fetch the URL without JavaScript, and confirm the text is there. Our guide to AI search technical optimization covers crawler access in depth, and the AEO scanner checks how a page looks to those crawlers.

Mistakes to avoid

Chasing a 100 lab score. The Lighthouse score is a weighted lab summary. Report field results.
Comparing scores across tools. PageSpeed Insights, GTmetrix and a local Lighthouse run use different settings. Compare a page against itself in one tool.
Testing only the home page. Product, category, article and landing page templates carry most traffic and are usually slower. Test one URL per template.
Expecting field data to move the next day. CrUX is a 28-day rolling window. Use lab data to confirm the fix immediately, then check the field data three to four weeks later.
Reading desktop results for a mobile problem. Mobile and desktop are assessed separately, and mobile is usually the one failing.
Testing once and never again. Speed regresses with every new script. Set up at least a monthly check.