# Website speed monitoring: what to watch, and how often

> Why Google's own speed data reports a slowdown a week or more late, which free tools to check, and a simple routine that catches problems early.

Published 2026-10-08 by Site Speed Labs.
Canonical: https://www.sitespeedlabs.com/blog/website-speed-monitoring

Most websites do not get slow on the day they launch. They get slow later, one change at a time: a plugin update, a chat widget, a new tracking tag from the marketing team, a homepage photo uploaded straight off a phone. Each change is small, nobody tests the speed afterwards, and six months on the site takes twice as long to load.

Monitoring is how you notice while it is still one change and not twenty. This post covers what to watch, the free tools that show it, why Google's own data reports problems late, and a routine you can keep up with.

## Two kinds of speed data, and why it matters for monitoring

Every speed tool gives you one of two kinds of numbers, and they behave very differently over time.

**Lab data** comes from a single test: a program loads your page once, on a simulated phone and network, and reports what happened. Google's [PageSpeed Insights](https://pagespeed.web.dev/) runs a lab test called Lighthouse every time you press the button. Google describes lab data as [collected in a controlled environment and useful for debugging](https://developers.google.com/speed/docs/insights/v5/about).

**Field data** is collected from real visitors. Google gathers it from Chrome users who have opted in to sharing usage statistics and publishes it as the [Chrome User Experience Report](https://developer.chrome.com/docs/crux/methodology) (CrUX). This is the data behind the Core Web Vitals, the three measurements Google uses in search: how fast the main content appears, how quickly the page reacts to a tap, and how much it jumps around while loading. We explain all three in [what Google actually measures](/blog/what-google-actually-measures).

For monitoring, the difference that matters is time. A lab test tells you about this minute. Field data is a rolling summary of the [previous 28 days](https://developers.google.com/speed/docs/insights/v5/about), and the CrUX data feed runs [about two days behind](https://developer.chrome.com/docs/crux/api).

## Why Google's data tells you late

Google judges each Core Web Vital at the [75th percentile](https://web.dev/articles/vitals): a page passes if three out of four visits are good. Combine that with a 28-day window and you get a delay that surprises most owners.

Suppose a plugin update on the 1st makes every visit to your homepage slow. On the 2nd, one day out of 28 in the window is slow, so the 75th percentile barely moves. The number only flips once slow visits make up more than a quarter of the window. With steady traffic that is about a week, plus the two-day reporting lag. Here is how the window fills up:

| Days since the slowdown | Share of the 28-day window that is slow | What field data shows |
| :-- | --: | :-- |
| 1 | about 4% | Still good |
| 4 | about 14% | Still good |
| 7 | 25% | On the edge |
| 10 | about 36% | Now failing |
| 28 | 100% | Fully failing |

That is the simple case, where every visit got slower. Real problems are often partial. A script that only slows phones, or only the booking page, or only visitors in one country, may take much longer to show up, or never cross the line at all while still costing you enquiries.

Fixes are delayed the same way. Search Console's Core Web Vitals report, which also uses CrUX data, runs a [28-day monitoring session](https://support.google.com/webmasters/answer/9205520) when you tell it you have fixed an issue. A problem that started on the 1st, was noticed on the 10th and fixed on the 12th can stay visible in Google's reports well into the following month.

None of this makes field data less important. It is what Google uses, and it reflects your real visitors. It is just the wrong tool for noticing a problem early.

## Why one lab test is not enough either

Lab tests are fast, but a single run is noisy. Lighthouse's own documentation lists [seven sources of variability](https://github.com/GoogleChrome/lighthouse/blob/main/docs/variability.md), from network conditions to the test machine's hardware to the page itself changing between loads (an advert, a rotating banner). The same page can score a few points differently twice in a row with nothing changed.

The same document's advice is to stop trusting single results: "The median Lighthouse score of 5 runs is twice as stable as 1 run." For an owner, that means two things. Never react to one bad test. And when you compare before and after a change, run each side several times and compare the middle values.

## What to watch

You do not need to watch every page or every metric. Four things cover most of what goes wrong on small-business sites.

**The pages that earn money.** Usually the homepage, your main service or product page, and whatever page holds the form, booking widget or checkout. Five pages is plenty to start. Field data may not exist for quieter pages, because CrUX only includes pages and sites that are ["sufficiently popular"](https://developer.chrome.com/docs/crux/methodology), and Google does not disclose the threshold. Lab tests work on any page.

**The three Core Web Vitals, on phones.** Google's guidance is to measure the [75th percentile, separately for mobile and desktop](https://web.dev/articles/vitals). Phones are where problems show first, so if you only look at one, look at mobile.

**Page weight and the number of outside scripts.** These are not ranking signals, but they are early warnings. A page that went from 2 MB to 5 MB, or from four third-party scripts to eleven, has changed even if the score has not moved yet. PageSpeed Insights lists the largest files and third-party code in its diagnostics.

**Whether your words are in the page.** If a theme or page-builder update starts loading your text with JavaScript, people may never notice, but search engines and AI assistants that read raw HTML can lose your content. Our [free check](/audit) shows how much of a page is readable without JavaScript, so you can compare it before and after a big update.

## Free tools that cover most of this

| Tool | Kind of data | Good for |
| :-- | :-- | :-- |
| [PageSpeed Insights](https://pagespeed.web.dev/) | Lab, plus field if available | Checking one page after a change |
| [Search Console, Core Web Vitals report](https://support.google.com/webmasters/answer/9205520) | Field (CrUX), grouped by similar pages | Seeing which groups of pages Google considers poor |
| [CrUX Vis](https://developer.chrome.com/docs/crux/vis) | Field (CrUX), weekly history | Seeing a trend over many weeks, by phone or desktop |
| Your hosting or analytics provider | Field, from your own visitors | Faster feedback, if your platform offers it |

CrUX Vis deserves a mention because few owners know it exists. PageSpeed Insights only shows the latest 28-day figure. CrUX Vis charts up to [40 weekly data points](https://developer.chrome.com/docs/crux/vis), so you can see the week a metric started to slide and match it against what changed on the site that week. The underlying [history data updates every Monday](https://developer.chrome.com/docs/crux/history-api).

The last row covers what developers call real-user monitoring: a small script on your own site that measures every visit and reports it to you, without waiting for Google. Some hosting platforms include it, and Google publishes a free library called [web-vitals](https://github.com/GoogleChrome/web-vitals) that a developer can add. It gives the fastest field signal, but it is something to set up, not something to check.

## Set a budget, so you know what "worse" means

A monitor is only useful if you have decided in advance what counts as a problem. web.dev calls this a [performance budget](https://web.dev/articles/performance-budgets-101): "a set of limits imposed on metrics that affect site performance." It describes three kinds: limits on size (for example, how much JavaScript a page may load), limits on timings (how many seconds until the main content appears), and limits on a tool's score.

For a small business, we suggest timing budgets on your money pages, starting from Google's "good" thresholds: main content in 2.5 seconds or less, a response to taps in 200 milliseconds or less, and layout shift of 0.1 or less. If a page is already well inside those, set the budget closer to where it is today, so a slow creep shows up before it reaches the line.

Score budgets are the easiest to understand and the noisiest to act on, for the reasons above. If you use one, give it room: "the homepage stays above 80 on mobile, judged on the middle of several runs" works better than "the homepage scores 95".

## A routine you can keep up with

Here is a routine that takes a few minutes and catches most regressions.

**After every change you know about.** New plugin, theme update, new marketing tag, redesigned page: run PageSpeed Insights on the affected page three times and note the middle score and the main content time. Do the same before the change if you can. This is the single most useful habit, because it ties a slowdown to its cause on the day it happens.

**Weekly, on Monday.** Look at CrUX Vis for your site on phones. You are looking for a line that has started to bend, not a single bad week.

**Monthly.** Open the Core Web Vitals report in Search Console and check whether any group of pages has moved from good to needs improvement or poor.

**Watch for changes you did not make.** On WordPress, plugins and themes can be set to [update automatically, and by default those updates run twice a day](https://wordpress.org/documentation/article/plugins-themes-auto-updates/). WordPress emails the site owner after each automatic update. Treat that email as a reminder to run a quick test, because an update you did not see is still a change.

## When it is worth paying someone to watch

If your site changes rarely and you are comfortable running the checks above, the free tools are enough. Paid monitoring starts to make sense when several people can change the site (an agency, a marketing team, automatic updates), when the site directly takes bookings or sales, or when nobody will reliably do the Monday check.

That is the job our [Speed Care](/monitoring-app) app will do. It reads Google's real-visitor figures for your money pages every day, warns you when a page is heading for Google's line, and works back to the week a slowdown began, so you know which change to look at. It is monitoring only; fixing is a separate job.

## Start with a baseline

You cannot spot a slowdown without knowing where you started. Run our [free check](/audit) on your three most important pages today and keep the results. It shows the main speed measurements, the top fixes in plain language, and how much of each page AI assistants can read. Next time something changes on the site, run it again and compare.

---

Want to know where your own site stands? Free plain-language check: https://www.sitespeedlabs.com/audit