Website Speed Test Guide: How to Test and Read the Results

A website speed test shows how fast your pages load and respond, but only if you test the right pages with the right tools. Start with field data from real visitors to find out whether there's a problem, then use lab tests to find out why. This guide walks through both, in the order we use them, and is part of our website design best practices guide.

You'll need Chrome and access to Google Search Console for your site. If the terms LCP, INP and CLS are new, read Core Web Vitals explained first, since every tool here reports them.

Field data and lab data answer different questions

Speed tools give you two kinds of results, and mixing them up is the most common reason people fix the wrong thing.

Field data comes from real Chrome users who have opted in to sharing usage statistics. It covers the previous 28 days and shows the 75th percentile, so it reflects the slower visits on older phones and patchy networks. It answers one question: do real visitors have a problem?

Lab data comes from a single simulated page load in a controlled setting. Lighthouse, for example, simulates a mid-tier phone on a mobile network. Because nothing changes between runs except the page itself, lab data is good for finding causes and checking fixes. It can't measure INP, because no real person is tapping or typing.

Use field data to decide what to fix. Use lab data to work out how.

Which speed test tool to use

Google's free tools cover almost every need. Each one is strongest at a different stage of the job:

Steps

1. 01
   Start with the Core Web Vitals report in Search Console.

   Open the report and look at mobile first, then desktop. URLs are grouped by similar pages, and each group takes the status of its worst metric. Note which groups are poor or need improvement, and which metric is the cause. This is your list of problems, ranked by how many URLs they affect.

2. 02
   Pick one URL for each page template.

   Pages built from the same template usually share the same problems. Choose one representative URL each for the home page, a service page, a blog post and any other template that shows up in the report. Testing ten blog posts tells you little more than testing one, so spend the time on templates instead.

3. 03
   Run PageSpeed Insights and read the field data first.

   Enter each URL. The top section shows real-user results for the page, or for the whole site if the page has too little data. Read the 75th percentile values for LCP, INP and CLS, and the distribution bars below them. If the page passes the Core Web Vitals assessment here, a low lab score is a lower priority.

4. 04
   Read the lab diagnostics, not just the score.

   Scroll to the lab section. The performance score is a weighted average of several lab metrics, and the weights change between Lighthouse versions, so treat it as a rough guide. The useful part is underneath: which element was the LCP, what blocked rendering, which elements shifted and how much JavaScript ran.

5. 05
   Run Lighthouse several times and use the median.

   Results vary from run to run because of network conditions, server load and your own computer. The Lighthouse team recommends running tests several times and comparing aggregate values such as the median. In DevTools, run Lighthouse in a private window, so browser extensions don't slow the page, and close other heavy tabs.

6. 06
   Reproduce the problem in the DevTools Performance panel.

   Open the panel and reload the page while recording. It shows your own LCP and CLS live, and records INP when you click or type. Set up the field data option to compare your results with real users. If yours are much faster, turn on network and CPU throttling until they roughly match.

7. 07
   Check server response time and redirects.

   In the Network panel, select the page's first request and look at its timing. Time to First Byte includes any redirects before the page and the server's response time. The Chrome team's guide on web.dev calls 0.8 seconds or less good. A slow first byte delays everything else, and no image or font fix will make up for it.

8. 08
   Decide what to fix first.

   Fix the metric that fails in the field, on the template with the most URLs. For a slow LCP, follow how to improve Largest Contentful Paint. For moving content, follow how to fix Cumulative Layout Shift. For slow interactions, look at long JavaScript tasks in the Performance trace. Fix the template, not just the page.

9. 09
   Retest, then watch the field data.

   After each fix, rerun the lab test to confirm the change worked. Then wait. Field data covers the previous 28 days, so it improves gradually as new visits replace old ones. Check PageSpeed Insights and Search Console again over the following weeks, and keep a short log of what changed and when.

How a site is rendered also shapes these results, especially server response time. We compare the main approaches in server-side rendering vs static site generation.

If you'd rather have testing and fixes handled for you, our in-house web team builds and maintains sites with performance planned in from the start.

Test accessibility alongside speed

PageSpeed Insights and Lighthouse also report an accessibility score, and it's tempting to treat a green result as a pass. It isn't one. The score is a weighted average of automated audits, and manual audits don't count towards it. The W3C's own guidance is direct: no tool alone can determine if a site meets accessibility standards, and knowledgeable human evaluation is required.

While you have the page open and throttled, a few manual checks take minutes and often catch problems that loading changes cause.

Tab through the page as it loads. Press Tab from the top. Check that focus is always visible and that a late cookie banner or chat widget doesn't cover the focused element. WCAG 2.2 covers this in Focus Not Obscured (Minimum).

Zoom to 200 percent, then narrow the window. WCAG's Resize Text criterion asks that text can be enlarged to 200 percent, and Reflow asks that content works at 320 CSS pixels wide without scrolling in two directions. Speed fixes that fix heights in pixels often break here.

Watch the loading states. On a slow connection, spinners and skeleton screens stay on screen longer. If content loads or a form submits without a page change, WCAG's Status Messages criterion asks that the update can be announced to screen reader users, for example with a short text message.

Troubleshooting

The performance score changes every time you test

Cause: lab results vary even when the page hasn't changed. The Lighthouse team lists the usual reasons: your local network, the server's load at that moment, your computer's hardware and other programs competing for it. Browser extensions can also inject scripts into the page. PageSpeed Insights runs in Google's data centres, which can vary too, so two runs a minute apart can differ noticeably.

Fix: don't judge a change on a single run. Run the test several times before and after the change, and compare the medians. Test in a private window with extensions off, close other heavy tabs, and use the same device, network and throttling settings each time. If the median stays the same, the change didn't make a measurable difference in the lab. Then check whether field data moves over the next few weeks.

Lab results look good but field data fails

Cause: the lab run doesn't match your real visitors. Lighthouse loads the page once, with an empty cache and no interaction, from one location. Real visitors may use slower phones, arrive with a warm or cold cache, accept a cookie banner, or tap a menu while scripts are still running. INP only exists in the field, so a slow interaction never shows up in a lab score at all.

Fix: use the Performance panel's field data comparison and its suggested settings to make your local test closer to real use. Turn on CPU throttling and test on a mid-range Android phone if you have one. Interact with the page while recording: open menus, submit forms and accept the cookie banner. Test the exact URLs visitors land on, including ad landing pages, not just the home page.

The test is slow before the page even starts loading

Cause: time is lost before the browser receives any HTML. The usual reasons are one or more redirects, such as http to https and then to a www address, a slow server response, or a page that is built from scratch on every request. Time to First Byte counts all of this, and it delays LCP on every page that shares the setup.

Fix: in the Network panel, check the first request for redirects, and link straight to the final URL in navigation, ads and emails. Check whether the server caches pages, or whether a CDN could serve them closer to visitors. If pages rarely change, serving them as prebuilt static files is often the biggest single improvement. Then compare Time to First Byte again across several runs.