Website Speed Test: How to Measure Page Speed and What the Numbers Mean

The Tools and What Each Is Best At

PageSpeed Insights is the default starting point because it shows two kinds of truth at once. The top section reports field data: real Chrome user measurements of your page over the trailing 28 days, the same Core Web Vitals data Google uses as a ranking signal. Below it, a Lighthouse lab run shows a performance score and diagnostics from a standardized throttled test. When the two disagree, believe the field data about experience and use the lab data to diagnose, more on that split below.

WebPageTest is the specialist's tool. It loads your page from a real browser in a location you choose, on a connection profile you choose, and records everything: a filmstrip of the page rendering frame by frame, a waterfall of every request with DNS, connect, TLS, and download phases separated, and repeat-view results showing how well your caching works. When you need to know exactly why a page is slow, in what order things loaded and what blocked what, WebPageTest answers at a level nothing else free matches.

GTmetrix wraps Lighthouse with history tracking: free accounts can schedule recurring tests, keep score history, and alert on regressions, useful as lightweight ongoing monitoring. Chrome DevTools is the developer's loop: the Network tab with throttling enabled shows the waterfall live, the Performance panel records where main thread time goes, and no deploy is needed, you can profile local changes before shipping them. Full audit workflow for the Lighthouse side is in our Lighthouse guide.

How to Test So the Numbers Mean Something

Test mobile first. Most sites see the majority of traffic from phones, Google evaluates mobile experience for rankings, and mobile hardware plus cellular networks make every problem bigger: a page that scores 92 on desktop routinely scores 55 on mobile. The mobile number is your real number, and the desktop number is the flattering one.

Run tests several times and take the median. Any single run carries noise from network variance, server state, and third-party scripts, and differences of a few points between runs mean nothing. WebPageTest runs multiple passes natively; with PageSpeed Insights, run it three times and read the middle result. Judge changes by shifts in the median across runs, not by one before and one after screenshot.

Test more than the homepage. Homepages are usually the most optimized page on a site, while the product pages, articles, or search results where visitors actually land carry the heavy templates, the extra scripts, and the slow queries. Test your top landing pages by traffic, plus your money pages, checkout, signup, contact, because a fast homepage in front of a slow checkout is a fast billboard for a broken store.

Finally, test logged-in and interactive states when they matter to your business. Public tools only see what an anonymous visitor sees; measuring authenticated pages requires scripting a browser yourself, which is exactly the technique in our Playwright performance testing guide.

Reading the Numbers: A Field Guide

Time to first byte (TTFB) is how long before the server sends the first byte of the response, covering DNS, connection setup, and the server's own processing. Under 200 milliseconds is strong, and beyond 800 milliseconds the server itself is a primary problem no frontend optimization can hide. High TTFB points at slow application code, slow database queries, missing page caching, or hosting that is simply too small or too far from your visitors.

First Contentful Paint (FCP) marks when anything first renders, the moment the page stops being blank. It is mostly determined by TTFB plus render-blocking CSS and scripts in the head. Largest Contentful Paint (LCP) marks when the main content, usually the hero image or headline block, finishes rendering, with 2.5 seconds as the good threshold. LCP is the loading metric that counts for rankings, and its usual culprits are slow servers, oversized hero images, and late discovery of the LCP resource by the browser's preload scanner.

Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS) measure responsiveness and visual stability; both are explained fully with their fixes in our Core Web Vitals guide. Total page weight and request count are diagnostics rather than experience metrics: a 6 megabyte page with 140 requests is not automatically slow, but it has 6 megabytes of reasons it might be, and the waterfall tells you which ones execute before the content the user came for.

Lab scores versus field data deserve one clear rule. Lab tests are a controlled experiment on one simulated device; field data is the median-to-75th-percentile reality of your actual audience. A page can score 90 in the lab and still fail field vitals because your audience skews toward older phones, and the reverse happens when a heavy page is visited mostly by desktop users on fiber who never feel the weight. Field data decides whether you have a problem, lab data tells you what to fix.

The Fixes That Actually Move the Needle

Fix TTFB at the source. Add page caching so repeat requests skip application work entirely, front the site with a CDN so static assets and cached pages serve from near the visitor, and profile the slow queries behind dynamic pages, an unindexed query is milliseconds to fix and often worth a full second of TTFB. If the server is genuinely underpowered shared hosting struggling at single-digit requests per second, no amount of tuning beats moving up a tier.

Fix images next, because they are the largest bytes on most pages. Serve modern formats (WebP or AVIF), size images to their displayed dimensions instead of shipping 4000 pixel originals into 400 pixel slots, lazy-load everything below the fold, and never lazy-load the LCP image itself, that delays the one image the metric waits for. Explicit width and height attributes on every image kill most layout shift for free.

Then JavaScript. Every script must download, parse, and execute on a phone CPU, and script weight is what pushes interactivity metrics over budget. Remove dead third-party tags, load analytics and chat widgets with defer or after first interaction, and split bundles so pages ship only the code they use. The Coverage panel in Chrome DevTools shows how much of each bundle a page actually executes, and the unused percentage on most sites is humbling.

These three categories, server, images, scripts, cover the large majority of real-world slowness. Run your speed test again after each change, same tool, same settings, median of several runs, and keep the results: a simple log of date, change, and score turns performance work from guesswork into engineering. If the findings point at server work beyond your reach, freelance web developers on Fiverr handle exactly this kind of optimization work, and a full crawl-based audit like SE Ranking's website audit will surface the slow and broken pages across an entire site rather than one URL at a time.

From One-Off Tests to Continuous Measurement

A speed test is a snapshot, and sites regress between snapshots: a new marketing tag, a heavier hero image, a plugin update, and three months later the fast site is not. Continuous measurement closes the gap. Schedule recurring tests with GTmetrix or WebPageTest so history accumulates automatically, or run Lighthouse CI in your deploy pipeline with budgets that fail builds on regression, the setup covered in our performance testing overview.

Watch your field data on the same cadence. Google Search Console's Core Web Vitals report shows which page groups pass and fail for real users, and it is the scoreboard that matters for rankings; the lab tools exist to change what that report says. Monthly is often enough for a stable content site, per-release is right for an actively developed product, and either way the habit beats the heroic quarterly performance sprint. For uptime and availability monitoring alongside speed, see website monitoring.