How to test website speed?

To test website speed, run your page through a tool such as Google PageSpeed Insights, Lighthouse, WebPageTest, or GTmetrix, then read two things: the performance score and the Core Web Vitals. PageSpeed Insights scores a page from 0 to 100, where higher is better, and it works for both desktop and mobile. But the score is only a lab estimate. What truly reflects user experience, and what Google ranks on, is the field data behind metrics like Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. The reliable approach is to test with the right tool, read the metrics that matter, and re-test across real devices and networks after each fix.

What Website Speed Actually Measures

"Website speed" is not a single number. It is a set of timing and stability metrics that describe how quickly a page loads, how fast it responds to interaction, and how steady it stays while rendering. Modern speed testing centers on Core Web Vitals, the three user-centric metrics Google uses, supported by a few classic loading metrics. The table below summarizes what each one measures and the threshold for a "good" result.

Two more numbers tie everything together: page weight (the total bytes a page transfers) and request count (the number of HTTP requests it makes). Heavier pages and longer request chains almost always translate into slower metrics, so most speed tools surface both prominently.

One important update to keep straight: INP replaced First Input Delay (FID) as a Core Web Vital on 12 March 2024. If a guide or tool still lists FID as a ranking metric, it is out of date. INP measures the latency of all interactions across a visit, not just the first one, so it is a far more complete measure of responsiveness.

Lab Data vs Field Data

Every speed test produces one of two kinds of data, and understanding the difference is the single most common gap in interpreting results.

• Lab data (synthetic): collected in a controlled environment by tools such as Lighthouse, the PageSpeed Insights lab section, and WebPageTest, using a fixed device profile and throttled network. It is reproducible and ideal for debugging, but it is a simulation, not a real visit. Lab tools cannot measure INP because it depends on actual user interaction.
• Field data (real user monitoring): collected from real Chrome users through the Chrome User Experience Report (CrUX) over a rolling 28-day window, then assessed at the 75th percentile. This is the data Google uses for ranking. It is the source of truth for how your site actually performs, including INP.

The practical takeaway: use lab data to find and fix problems quickly, and use field data to confirm those fixes actually improved the experience for real visitors.

Tools to Test Website Speed

No single tool does everything well. Here are the five you will use most, and what each is best at.

• Google PageSpeed Insights: the quickest starting point. Enter a URL and it returns both lab data (from Lighthouse) and field data (from CrUX) with a 0-100 score, Core Web Vitals, and prioritized recommendations for desktop and mobile.
• Lighthouse / Lighthouse CI: the engine inside Chrome DevTools (Lighthouse panel). It audits performance, accessibility, SEO, and best practices. Lighthouse CI runs the same audit in your build pipeline so a performance regression fails the build before release.
• WebPageTest: the most powerful diagnostic tool. It offers 40+ global test locations, real-device testing, scripted multi-step flows, and the deepest request waterfall (DNS, connect, SSL, TTFB, content download), plus a filmstrip view of the load.
• GTmetrix: produces the cleanest, most shareable report. It combines Lighthouse metrics with CrUX field data, a readable waterfall, and history tracking, with options to set the test location, browser, and connection throttling.
• Chrome DevTools (Performance and Network panels): the most granular hands-on tool. The Network panel shows every request, its size, and its timing; the Performance panel records a flame chart of main-thread activity so you can pinpoint long tasks that hurt INP and TBT.

How to Run a Website Speed Test, Step by Step

The workflow is the same regardless of which tool you pick:

• Choose your tool and open it. PageSpeed Insights is a good default for a first read.
• Enter the full page URL, not just the domain. Test the actual page that matters, such as a product or landing page, not only the homepage.
• Select the device profile (mobile and desktop are scored separately) and, where supported, the test location and network throttling.
• Run the test and wait for both the lab and field sections to populate.
• Read the Core Web Vitals first (LCP, INP, CLS), then the supporting metrics (TTFB, FCP, Speed Index, TBT), and finally the waterfall to see which requests are slow.
• Note the top opportunities the tool flags, such as render-blocking resources, oversized images, or unused JavaScript.
• Apply one fix at a time, then re-test so you can attribute each change to a specific improvement.

Test Across Devices, Locations, and Networks

A single test from your own laptop on fast office Wi-Fi is misleading. Real users arrive on a wide range of devices, from different countries, on connections that range from fiber to congested mobile data. Speed varies dramatically across all three, so your testing should too.

• Devices: test mobile and desktop separately. A mid-tier phone has far less CPU and memory than a desktop, which is why JavaScript-heavy pages often pass on desktop but fail INP and TBT on mobile.
• Locations: latency grows with distance from your server. A page that loads in under two seconds locally can take much longer for a visitor on another continent if you are not using a CDN.
• Network throttling: tools like Lighthouse, WebPageTest, and GTmetrix let you simulate 4G, 3G, or slow connections so you can see how the page behaves when bandwidth and latency are constrained.

To validate speed the way real users experience it, you can run performance checks across thousands of browser and OS combinations and on real handsets using TestMu AI'sReal Device Cloud, with built-in network throttling and geolocation so you can reproduce slow-network and far-from-server conditions without owning every device yourself.

How to Improve Your Website Speed

Once a test shows where you are losing time, these are the highest-impact fixes, roughly in the order most sites benefit from them.

• Compress and optimize images: images are the single largest contributor to page weight. Serve next-gen formats (WebP or AVIF), apply lossy or lossless compression, and size images to their displayed dimensions. This usually improves LCP the most.
• Enable caching: browser caching lets returning visitors reuse static assets instead of re-downloading them, and server-side caching avoids regenerating pages on every request. Both cut TTFB and overall load time.
• Use a CDN: a content delivery network serves static assets from servers physically close to each user, which reduces latency and is the most effective single fix for a geographically spread audience.
• Minify and combine code: minifying CSS, JavaScript, and HTML strips whitespace and comments, while combining files reduces the number of HTTP requests. Both shrink page weight and speed up parsing.
• Lazy-load offscreen media: add loading="lazy" to images and iframes below the fold so the browser defers them until they are needed, improving the initial load.
• Reduce and defer JavaScript: eliminate render-blocking scripts, defer non-critical JavaScript, and remove unused third-party tags. Heavy JavaScript is the most common cause of poor INP and TBT.

After each change, re-run your speed test and confirm the metric you targeted actually moved. Real improvement shows up in field data over the following weeks, so treat speed testing as an ongoing loop rather than a one-time audit.

Frequently Asked Questions

What is a good website speed test score?

A Lighthouse or PageSpeed Insights performance score of 90 or above (out of 100) is considered good, but the score is only a lab estimate. The signal that matters for users and for Google is the Core Web Vitals field assessment: LCP at or under 2.5 seconds, INP at or under 200 milliseconds, and CLS at or under 0.1, measured at the 75th percentile of real visits.

What is the difference between lab data and field data?

Lab data is collected in a controlled environment by tools like Lighthouse and WebPageTest using a fixed device and network profile, so it is reproducible and good for debugging. Field data is collected from real users through the Chrome User Experience Report (CrUX) over a rolling 28-day window and reflects the experience Google ranks on. INP can only be measured in the field because it depends on real interactions.

Did INP replace FID as a Core Web Vital?

Yes. Interaction to Next Paint (INP) officially replaced First Input Delay (FID) as a Core Web Vital on 12 March 2024. INP measures the full latency of all interactions across a page visit, where FID only measured the delay of the first input, so INP is a more complete measure of responsiveness.

Which is the best tool to test website speed?

There is no single best tool. PageSpeed Insights is the quickest starting point because it shows both lab and field data with Core Web Vitals. Lighthouse in Chrome DevTools is best for debugging during development, WebPageTest is best for deep waterfall and multi-location analysis, and GTmetrix gives the cleanest report for sharing with stakeholders. Most teams use two or three together.

Why is my website fast for me but slow in a speed test?

Your own visits are usually cached, run on a fast device, and come from a connection close to your server. A speed test often simulates a mid-tier mobile device on a throttled network from a different geographic location, which is closer to what many real users experience. Testing across multiple devices, locations, and network speeds reveals the gap.

How often should I test my website speed?

Run a speed test before and after any significant change, and monitor continuously in production. Adding Lighthouse CI to your build pipeline catches performance regressions before release, while field monitoring through CrUX or Search Console tracks how real users experience the site over time.

• Types of Tests in Automated Performance Testing
• What Is Performance Testing?
• How to Find Bugs on the Website?
• How to Test Your Website and Remove Bugs?
• How Can Real Device Testing Help Identify Performance Issues in Low Bandwidth Environments?