Free Tools to Measure Your Website Speed (and Read the Results)

You cannot improve what you cannot measure, but speed tests can be confusing. Different tools report different numbers for the same page, and a single score hides the details that tell you what to fix. This guide covers the free tools worth knowing, what each one is good for, and how to avoid common misreadings.

Lab data versus field data, again

Every tool falls into one of two groups. Lab tools load your page in a controlled, simulated environment, which makes results repeatable and great for debugging. Field tools report what real visitors experienced, gathered over time from real devices and networks. Lab data tells you why a page is slow; field data tells you whether visitors are actually affected. Use both.

PageSpeed Insights

PageSpeed Insights is Google's free web tool. Enter a URL and it shows two things: field data from the Chrome User Experience Report, if your page or site has enough traffic, and a Lighthouse lab test run on a simulated mobile or desktop device. The top section tells you whether the page passes the Core Web Vitals assessment. Below it, the diagnostics list specific opportunities such as oversized images, unused JavaScript or slow server response. Start here for a quick check.

Lighthouse in Chrome DevTools

Lighthouse is the engine behind the lab portion of PageSpeed Insights and also lives inside Chrome. Open DevTools, find the Lighthouse tab and run an audit. Because it runs on your own machine, results depend on your computer and extensions, so use a private window with extensions off for cleaner results. It reports performance, accessibility, best practices and SEO. Its main value is repeatable testing while you work on changes, especially for pages that are not public yet.

Chrome DevTools: Network and Performance panels

• Network: shows every request with size, timing, protocol and headers. Use it to find the heaviest files, check caching headers and see the waterfall of what loads when.
• Performance: records a trace of main thread activity, ideal for investigating long tasks and slow interactions.
• Throttling: simulates slower connections and processors, so you see what a mid-range phone on mobile data experiences.

WebPageTest

WebPageTest runs tests from locations around the world on real browsers and gives a detailed waterfall, filmstrip view and repeat-view results, which show how well caching works for returning visitors. It is the best free choice for questions such as "how does my site load for someone in another country?" and for comparing before and after.

Google Search Console

If you have verified your site, Search Console includes a Core Web Vitals report that groups URLs by status across your site, based on field data. It is the best way to see which page types are failing and whether fixes worked over time. It will not explain why a page is slow, so combine it with a lab tool.

Other helpful checks

• curl for a quick time-to-first-byte check from a terminal.
• Browser Performance APIs for developers who want to log real user timings from their own pages.
• Uptime monitors with free tiers, which record response time over days and show patterns such as slowdowns every evening.

Which tool for which question

Question	Tool
Does my page pass Core Web Vitals?	PageSpeed Insights field data, Search Console
What is making this page slow?	Lighthouse, DevTools Network and Performance
How does it load abroad or on slow networks?	WebPageTest
Is my server response slow?	curl, DevTools timing, PageSpeed server response audit
Which page types are failing across the site?	Search Console

How to avoid misreading results

1. Do not chase the score. A performance score is a weighted summary that changes between tool versions. Look at the individual metrics and diagnostics.
2. Test more than once. Results vary from run to run. Take three runs and compare typical values.
3. Test the right pages. Home, a key landing page, and a typical content or product page, on mobile.
4. Change one thing at a time so you know what made a difference.
5. Test logged out, as visitors see your site, unless you are specifically checking logged-in pages.
6. Remember caching. A first test may hit a cold cache. Run again to see warm performance, and know that real visitors will experience a mixture.
7. Ignore small differences. A change of a few points between runs is noise.

A simple monthly routine

Pick the same three or four URLs, test them on mobile in PageSpeed Insights, and record LCP, INP, CLS and time to first byte in a spreadsheet. Check the Search Console report once a month. Whenever you install a plugin or change themes, run the tests again. Over a few months you will spot regressions early, before visitors do.

Reading a waterfall

The waterfall chart in DevTools and WebPageTest is the most useful picture of a page load. Each row is a file, and its bar shows when it was requested, how long it waited, and how long it took to download. Read it from the top:

• A long first bar means a slow server response or a redirect chain.
• Files that start late, after a long gap, were discovered late. Check whether they are referenced from CSS or injected by a script.
• Very wide download bars mark large files, which are candidates for compression or removal.
• Many third-party domains in the list are worth questioning one by one. If you cannot say what a request is for, find out, and ask the team or plugin vendor.

If you get stuck interpreting a result, the support team can look at your hosting side of the picture and tell you what the server is doing.

Start from a fast base

Measurements are only useful if you act on them, and sometimes the findings point at the server. If your time to first byte stays high on lightweight pages, review your plan on the hosting overview.