How to Test Your Website Speed (Tools and Metrics)

You cannot improve what you do not measure, and with web performance the wrong measurement is worse than none — it sends you optimising the wrong thing. Testing your website speed properly means knowing which tools to use, the crucial difference between lab and field data, and the handful of metrics that actually matter. In short: check your real-user Core Web Vitals first (Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift, at the 75th percentile), use PageSpeed Insights as your starting point because it shows both field and lab data, reach for WebPageTest and Chrome DevTools to diagnose, and monitor the whole site over time in Search Console. This guide explains lab versus field data, walks through each tool and what it gives you, names the metrics and their thresholds, and shows how to read a report and prioritise what to fix.

It is the measurement companion to how to make your website load faster, where the fixes live.

The most important distinction: lab data vs field data

Before any tool, understand this split, because it explains why two speed tests of the same page can disagree and which one to believe.

Lab data (also called synthetic monitoring) is collected in a controlled environment: a single test, on a fixed device profile, over a defined network speed, run on demand. A Lighthouse run is the classic example. Its great strengths are that it is reproducible and immediate — you can run it, make a change, and run it again to see the effect, with the variables held constant. That makes lab data ideal for diagnosis and iteration. Its weakness is that one simulated load on one device is not how your real audience experiences the site; a test on a fast connection can look great while real users struggle.

Field data (also called Real User Monitoring, or RUM) is collected from actual visitors over time, capturing the real spread of devices, networks, locations and behaviours. Google's Chrome UX Report (CrUX) is the public field dataset, gathered from real Chrome users, and it is what Google actually uses for ranking. Its strength is realism — it tells you what your users genuinely experience. Its limitation is that it is an aggregate over the past 28 days, so it reacts slowly and needs enough traffic to report at all.

The workflow that falls out of this is the one every performance team should follow: diagnose and iterate with lab data because it is fast and controllable, but judge success by field data because that is what counts for users and for Google. A change that improves your lab score but not your field Core Web Vitals has not really succeeded.

The metrics that matter: Core Web Vitals

"Speed" needs a precise definition, and Google provides one with the Core Web Vitals — three metrics that map to real experience and feed Google's page-experience signals. They are assessed at the 75th percentile of real page loads, meaning three-quarters of your visits (including slower devices and networks) must hit the threshold, not just your fastest.

Metric	Measures	Good	Needs improvement	Poor
LCP (Largest Contentful Paint)	Loading — when the main content renders	≤ 2.5s	2.5s - 4.0s	> 4.0s
INP (Interaction to Next Paint)	Responsiveness — lag after interactions	≤ 200ms	200ms - 500ms	> 500ms
CLS (Cumulative Layout Shift)	Visual stability — unexpected movement	≤ 0.1	0.1 - 0.25	> 0.25

These three are the headline numbers to track. Supporting lab-only metrics help with diagnosis but are not ranking signals themselves: First Contentful Paint (FCP), the first moment any content appears; Time to First Byte (TTFB), how long the server takes to respond; Total Blocking Time (TBT), a lab proxy for responsiveness that correlates with INP; and Speed Index, how quickly the page visually fills in. When a Core Web Vital is failing, these supporting metrics usually tell you why. For a full treatment of each metric and how to improve it, see Core Web Vitals explained, and for the loading metric specifically, what is Largest Contentful Paint.

The tools, and what each one gives you

No single tool does everything; each has a job. Here is how they divide up.

Tool	Data type	What it gives you	Best for
PageSpeed Insights	Field + lab	CrUX field data and a Lighthouse lab test with ranked fixes, per URL	The starting point for any page
Lighthouse (DevTools)	Lab	The same audit run locally, fast to re-run	Iterating on fixes while developing
Chrome DevTools	Lab	Network waterfall, Performance trace, Coverage	Deep, hands-on diagnosis
WebPageTest	Lab	Detailed waterfall, filmstrip, multi-location/device tests	Advanced diagnosis and geography
GTmetrix	Lab	A clear, friendly performance report	Quick readable summaries, monitoring
Search Console (CWV report)	Field	Whole-site Core Web Vitals status over time	Monitoring all pages, not just one

PageSpeed Insights: start here

PageSpeed Insights (PSI) is the best first stop because it combines both data types in one free report for any public URL. At the top it shows field data from CrUX — your real-user Core Web Vitals, marked pass or fail — when there is enough traffic. Below that it runs a Lighthouse lab test and produces a 0-to-100 performance score plus a list of opportunities and diagnostics, each with an estimated saving. The combination is exactly what you want: the field section tells you whether you have a real problem, and the lab section helps you find its cause. Start every investigation here.

Lighthouse in Chrome DevTools: iterate fast

Lighthouse is the audit engine behind PSI's lab section, and you can run it directly in Chrome DevTools (the Lighthouse tab) against any page, including local and staging sites PSI cannot reach. Because it runs on demand and locally, it is ideal for iterating: run it, apply a fix, run it again. Set it to mobile with throttling for a realistic baseline. Treat the score as a relative guide to whether your changes are helping, not as the end goal — the field data is the goal.

Chrome DevTools: deep diagnosis

When you need to know exactly why a page is slow, the DevTools panels are where you dig in:

• Network panel — a waterfall of every request with timing, size and what blocks what. Sort by size to find the heaviest assets; check Content-Encoding to confirm compression is on.
• Performance panel — record a load or an interaction and see main-thread activity, long tasks, and the LCP and layout-shift markers on a timeline. This is the tool for responsiveness and rendering problems.
• Coverage tab — shows what percentage of each script and stylesheet went unused, pointing straight at trimming opportunities, as covered in how to optimize CSS for faster pages.

Use CPU and network throttling in DevTools (a 4x-6x CPU slowdown approximates a mid-range phone) so your local numbers resemble what slower real users experience, which is the usual reason a site tests fast but feels slow in the field.

WebPageTest: the advanced waterfall

WebPageTest is the power tool for detailed lab analysis. It produces an exhaustive request waterfall, a filmstrip and video showing visually when content appears, and — crucially — lets you test from different geographic locations, devices, browsers and connection speeds. That makes it the right tool when your audience is spread globally (does a visitor in another region see the same speed?) or when you need to understand the precise sequence of what loads when. It has a steeper learning curve than PSI but reveals more.

GTmetrix: a friendly report

GTmetrix packages performance data (it incorporates Lighthouse metrics) into a clean, readable report with grades and a clear breakdown, plus simple monitoring and alerting. It is a good choice when you want an approachable summary to share with non-specialists or a lightweight way to watch a few key pages over time.

Search Console: monitor the whole site

PSI and the others test one URL at a time. The Core Web Vitals report in Google Search Console does the opposite: it shows the field-data status of your entire site, grouping URLs into "good", "needs improvement" and "poor" for mobile and desktop, based on CrUX. This is how you monitor performance at scale and catch regressions across templates rather than spot-checking single pages. Because it is field data straight from the source Google ranks on, it is the dashboard to watch over time.

How to read a report and prioritise

A report full of numbers is only useful if you know what to do with it. Follow this order:

1. Check the field Core Web Vitals first. At the top of PSI (or in Search Console), look at the real-user LCP, INP and CLS. Are they passing at the 75th percentile? This tells you whether you have a genuine problem and which metric is failing. If field data is unavailable (low traffic), fall back to the lab data with that caveat in mind.
2. Identify the failing metric, then find its cause in the lab section. A poor LCP points you at the server, render-blocking resources or a heavy hero image; a poor INP points at JavaScript and long tasks; a poor CLS points at unsized media, ads or fonts. Match the failing field metric to the relevant lab diagnostics.
3. Prioritise by estimated savings. Lighthouse lists opportunities with an estimated time saving — work the largest first. Performance has steep diminishing returns, so the top two or three items usually deliver most of the gain. Do not scatter effort across every minor suggestion.
4. Fix, then re-test in the lab to confirm direction, and finally watch the field data to confirm the real-world result. Field data updates over roughly 28 days, so be patient: the lab confirms the change worked mechanically, the field confirms it helped real users.

The single most common mistake is chasing the lab score — polishing a 100/100 Lighthouse result — while the field Core Web Vitals still fail. Always anchor on the field data; the lab is the means, not the end.

A worked example

Suppose you run your homepage through PageSpeed Insights. The field-data section shows LCP failing at 3.9 seconds (red), INP and CLS passing. That immediately tells you the problem is loading, specifically the main content rendering too slowly. You scroll to the lab diagnostics: "Largest Contentful Paint element" names your hero image, "Properly size images" and "Eliminate render-blocking resources" carry the largest estimated savings. Now you have a focused plan rather than a vague "make it faster". You compress and resize the hero image, preload it, and defer a render-blocking script — the fixes from how to make your website load faster. You re-run Lighthouse locally to confirm the lab LCP dropped, then watch Search Console over the following weeks to confirm field LCP moves into the green. This is the whole loop: field data finds the problem, lab data finds the cause and confirms the fix, field data confirms the result.

How often to test

Testing is not a one-off. Performance decays as a site grows — every new image, script, font and third-party tag is a chance to slip backwards. Build a simple cadence: re-test important pages whenever you ship something significant, watch the Search Console Core Web Vitals report continuously for site-wide regressions, and consider a performance budget (a ceiling on page weight or a target metric) that your team agrees not to exceed. Catching a regression in days through monitoring is far cheaper than discovering it months later as a ranking dip or a conversion drop.

Common mistakes

• Judging by the lab score while ignoring failing field Core Web Vitals.
• Testing once on a fast laptop and connection, instead of throttling to mimic real users.
• Testing only the homepage, when deep templates carry most traffic and may be worse.
• Reacting to every minor suggestion instead of prioritising the largest savings first.
• Treating one test as the truth — field data is an aggregate that updates slowly, so watch the trend.

Go deeper

• The metrics in full, and how to improve them: Core Web Vitals explained.
• The fixes, in priority order: how to make your website load faster.
• The loading metric you will test most: what is Largest Contentful Paint.
• A common fix the tools flag: what are Gzip and Brotli compression.

Want your speed tested alongside SEO, security and AI-readiness in one report? Analyse any URL with StackOptic — free, no sign-up.