How to measure website speed properly

To measure website speed properly, combine two kinds of data: lab tests, which load your page under controlled conditions and help you debug, and field data, which shows how fast your site actually is for real visitors. Use the same tools, pages and settings before and after every change, repeat each test several times, and judge the result by medians and real-user data rather than a single score. This guide explains which tools to use for what, and how to run a before-and-after comparison you can trust.

Lab data vs field data

Almost every confusion about website speed comes from mixing up these two.

Lab data comes from a test run on one device, one network profile and one location. Lighthouse is the best-known example. It runs behind Google's PageSpeed Insights data, which corewebvitals.page uses, and it is built into Chrome DevTools. Lab tests are repeatable and give you detailed diagnostics, so they are ideal for finding causes and checking whether a fix works. But they are a simulation: one visit, with a specific throttling profile, from wherever the test runs.

Field data, also called real-user monitoring (RUM), comes from actual visitors on their own phones, laptops and networks. Google collects it from Chrome users in the Chrome UX Report (CrUX). You see it in Search Console, and tools like corewebvitals.page show it for any URL. Field data is what Google uses for its page experience evaluation, and it reflects reality, including slow devices and far-away visitors. Its downside is speed of feedback: CrUX reports a rolling 28-day window, so a change you make today takes weeks to show fully.

Use lab data to work, and field data to decide whether the work paid off.

The right tools for each job

You don't need a large toolbox. Four tools cover nearly everything.

corewebvitals.page

corewebvitals.page shows both kinds of data for mobile and desktop, based on Google's PageSpeed Insights data: field data from CrUX covering the last 28 days, if your site has enough traffic, and a Lighthouse lab run. Read the field data first. The 0 to 100 performance score belongs to the lab part only and is not what Google uses for rankings.

Search Console

The Core Web Vitals report in Google Search Console groups your URLs by status (good, needs improvement, poor) based on field data. It is the best place to see which page templates have problems across the whole site, rather than testing URLs one by one.

Chrome DevTools

The Performance and Network panels show exactly what happens during a load: which request blocks rendering, which script takes the main thread, how long the server takes to respond. The Lighthouse panel runs the same kind of lab test locally. Use an incognito window so browser extensions don't distort results.

Command line checks

For server response time, curl gives you a clean, repeatable number without any browser overhead:

for i in 1 2 3 4 5; do
  curl -o /dev/null -s -w "%{time_starttransfer}\n" https://example.com/
done

This prints the time to first byte for five consecutive requests. It is especially useful for checking caching and server changes. The guide on reducing TTFB explains how to break that number down further.

Which metrics to look at

Focus on a few metrics that describe what visitors experience:

• Largest Contentful Paint (LCP): when the main content appears. Good is 2.5 s or less.
• Interaction to Next Paint (INP): how quickly the page reacts to clicks and taps. Good is 200 ms or less. Only measurable in field data.
• Cumulative Layout Shift (CLS): how much the layout jumps around. Good is 0.1 or less.
• Time to First Byte (TTFB): how quickly the server starts answering. web.dev recommends 0.8 s or less.

Google assesses the three Core Web Vitals at the 75th percentile of page loads, separately for mobile and desktop. That means three out of four visits should meet the threshold. The Core Web Vitals guide covers what drives each metric and how to fix it.

Total page size and "fully loaded" time are less useful than they look. A page can finish loading late because of a chat widget that nobody notices, while a slow hero image that everyone notices barely affects total load time.

Why your results jump around

If you run the same lab test three times and get three different scores, nothing is broken. Common reasons:

• Cold versus warm cache. The first request after a deploy or purge is often much slower than the next ones, on your server and on any CDN.
• Server load. A test during peak hours competes with real visitors.
• Third-party scripts. Ads, tag managers and chat widgets load different content each time.
• Test location. Lab tests based on Google's PageSpeed Insights data, including those on corewebvitals.page, run from a Google data center. If your server is on another continent, the test measures that distance.
• The testing machine. Lighthouse in DevTools depends on your own computer's CPU and whatever else is running on it.

A before-and-after comparison you can trust

When you change something, such as a caching setup, a new theme or a CDN, follow a fixed routine so the comparison is fair.

1. Pick representative pages. Choose one of each important template: home page, category or listing page, product or article page. Include your most visited landing page.
2. Write down the conditions. Same tool, same device profile (mobile and desktop separately), same test location, same time of day if you can.
3. Warm up, then measure. Load each page once and discard that result, unless you specifically want to measure first-visit performance. Then run at least five tests per page.
4. Use the median. Take the middle value of your runs, not the best one. Record LCP, CLS, TTFB and Total Blocking Time for lab runs.
5. Change one thing at a time. If you switch hosting and theme at once, you won't know which one helped.
6. Repeat the exact routine after the change. Compare medians per page.
7. Confirm with field data. Check the field data on corewebvitals.page and in Search Console over the following weeks. Lab gains that don't show up for real users are not real gains.

If you use a CDN or edge cache, check that the tested page was actually served from cache during the "after" runs. Otherwise you are measuring your origin, not the change.

How fast.site helps

fast.site sits in front of your existing hosting as an edge network with caching, image optimization and security. You keep your host and point your domain's nameservers to fast.site; after verification, requests are served through the edge.

For measuring, two things matter. First, every response carries headers that tell you what happened: fs-cache shows HIT, MISS or BYPASS, and fs-cache-age and fs-cache-hits show how long and how often the cached copy has been used. That makes it easy to confirm your "after" test really came from the cache. The check cache article shows how.

Second, the dashboard analytics report requests, cache hit ratio, bandwidth from edge versus origin, TTFB and error rates for your own traffic. Combined with the field data on corewebvitals.page, that gives you a before-and-after view based on your real visitors rather than a single test run.

The best way to judge the effect is to measure it on your own site with the routine above, for example during a free 7-day trial. Plans and included traffic are listed on the pricing page.

FAQ

Why is my PageSpeed score different every time?

The performance score comes from a single lab run, which is affected by server load, cache state, third-party scripts and network variation. Small differences between runs are normal. Run several tests and use the median, and rely on the field data section for the real picture.

Is a PageSpeed score of 100 necessary?

No. The score is a lab summary and is not used as a ranking signal. What matters is whether real visitors get good Core Web Vitals, which you can see in the field data. Chasing the last few points often costs a lot of effort for no noticeable difference.

Why is there no field data for my site?

CrUX only reports data when a URL or origin has enough visits from Chrome users in the last 28 days. Smaller sites or new pages often don't reach that threshold. In that case, rely on lab tests plus your own monitoring until enough data exists.

How long until improvements show in Search Console?

Field data is collected over a rolling 28-day window, so a fix appears gradually and fully only after about four weeks. Search Console may take additional time to revalidate grouped URLs. Lab tests show the effect immediately, which is why you use them to verify a fix first.

Should I test mobile or desktop?

Both, separately. Google evaluates them separately, and mobile results are usually worse because of slower CPUs and networks. If you only have time for one, start with mobile.