# How to monitor site speed after every deploy

> Monitor site speed after every deploy with Lighthouse CI on key templates, scheduled scans of every page and alerts on real score drops, not noise.

Published: 2026-11-15 · Author: AiroPages

To monitor site speed after every deploy, test a few key templates with Lighthouse as part of your build, run a scheduled Lighthouse scan of every page, and alert only on real drops: changes bigger than normal run-to-run variation, or metrics crossing Core Web Vitals thresholds. Compare like with like, and look at results by template rather than single pages. This post explains why regressions happen, the main options for catching them and a simple routine a small team can keep up.

## Why speed regressions happen

Most speed regressions are side effects. Nobody sets out to make the site slower; it happens when something new lands on the page and nobody measures it. Common causes:

- **New third-party scripts.** A chat widget, analytics tag, heatmap tool or ad script added through a tag manager adds main-thread work and network requests. This often shows up as higher [Total Blocking Time](/glossary/tbt) (TBT).
- **Large images.** An editor uploads a 3 MB hero photo, or a new template skips responsive image sizes. Largest Contentful Paint (LCP) gets worse on every page that uses it.
- **CMS plugins and themes.** A plugin update loads its CSS and JavaScript on every page, even where it is not used.
- **A/B testing tools.** Some testing tools hide the page until the experiment loads, which delays everything the user sees.
- **Layout changes.** A banner, cookie notice or embed without reserved space pushes content down and raises Cumulative Layout Shift (CLS).
- **Framework and dependency upgrades.** A bigger JavaScript bundle or a new rendering path can slow every page at once.

Many of these never go through a code deploy. A marketing team can add a tag, or an editor can change an image, at any time. That is why monitoring needs more than a pipeline check.

## Your options for monitoring speed

There are four common approaches. Most teams end up combining two or three.

| Approach | What it catches | What it misses | Effort |
|---|---|---|---|
| Manual checks in DevTools or PageSpeed Insights | Problems on the page you happen to test | Every other page, and anything between checks | Low per check, hard to keep up |
| Lighthouse CI in your build pipeline | Code regressions on a fixed list of URLs, before release | Content, tag manager and third-party changes, and untested pages | Medium setup, then automatic |
| Scheduled bulk scans of every page | Regressions anywhere on the site, from any source | Problems between scans; lab only | Low once set up |
| Field data (CrUX, Search Console) | Real-user impact on Core Web Vitals | Fast feedback: it lags by weeks | Low, but slow |

### Manual checks

Running Lighthouse in Chrome DevTools or PageSpeed Insights after a deploy is better than nothing, but it relies on someone remembering, and it covers one URL per run.

### Lighthouse CI in your pipeline

Lighthouse CI runs Lighthouse against a list of URLs as part of a build, usually on a staging or preview deployment. You set assertions, and the build warns or fails when they are not met. A minimal `lighthouserc.json` might look like this:

```json
{
  "ci": {
    "collect": {
      "url": ["https://staging.example.com/", "https://staging.example.com/blog/sample-post/"],
      "numberOfRuns": 3
    },
    "assert": {
      "assertions": {
        "categories:performance": ["warn", { "minScore": 0.8 }],
        "categories:seo": ["error", { "minScore": 0.9 }],
        "cumulative-layout-shift": ["error", { "maxNumericValue": 0.1 }]
      }
    }
  }
}
```

Pick one representative URL per template, not just the homepage. Running each URL three times smooths out some variation. Keep in mind that lab numbers under mobile throttling are not the same as field Core Web Vitals, so set lab thresholds based on your own baseline.

### Scheduled bulk scans

A scheduled scan runs Lighthouse on every page at a fixed interval, whether or not anyone deployed. It catches the regressions a pipeline cannot: a new tag, a heavy image on one section, a plugin update on production. Because [Lighthouse only tests one page](/blog/lighthouse-only-tests-one-page) per run, this means running it across your full URL list.

### Field data

The [Chrome UX Report](/glossary/crux) and Search Console's Core Web Vitals report show what real Chrome users experience, measured at the 75th percentile over a rolling 28 days. That makes field data the final word on impact, but too slow to tell you which deploy caused a problem. The post on [lab data vs field data](/blog/lab-data-vs-field-data) explains how the two fit together.

## What to alert on

Alert on changes that are real and that matter. Lighthouse Performance scores move between runs because of network timing, CPU load and server response, so an alert on any drop will fire constantly and get ignored.

Good alert conditions:

1. **Sustained Performance drops across a template.** For example, blog posts falling from the mid 80s to the low 70s across most posts is a regression. One post moving from 84 to 80 is probably noise.
2. **Core Web Vitals thresholds.** LCP above 2.5 seconds (poor above 4 seconds) and CLS above 0.1 (poor above 0.25). Lighthouse cannot measure INP in the lab, so watch TBT as the proxy.
3. **Any SEO or accessibility drop.** These scores do not fluctuate much on an unchanged page, so a drop usually means something changed, such as a stray `noindex` or a new unlabeled button.
4. **New issues affecting many pages.** A new render-blocking script or uncompressed image that appears on hundreds of URLs is worth knowing about the same day.

Alerting by template is the key idea. A shared component change shows up as many pages of one type moving together, which is a much clearer signal than any single URL.

## How to compare runs fairly

A comparison is only meaningful if both runs used the same conditions. Before you call something a regression, check:

- **Same device.** Mobile and desktop use different throttling and scoring curves. Never compare a mobile run with a desktop run.
- **Same throttling settings.** Simulated throttling (the PageSpeed Insights default) and other methods give different numbers.
- **Same test region.** Distance to your server affects time to first byte and everything after it.
- **Same Lighthouse version.** New versions can change audits and scoring. If the version changed between runs, a score change may not be your site.
- **Enough runs.** Use the median of several runs, or compare groups of pages, rather than single results.

The post on [why Lighthouse scores change](/blog/why-lighthouse-scores-change) goes deeper into the sources of variation.

## How to monitor your whole site

The manual way is to schedule a script that reads your sitemap, runs the Lighthouse CLI on every URL with fixed settings, stores the JSON results, and compares each run with the previous one. You then need to group results by template, decide what counts as a real change and send the alerts yourself.

AiroPages is the hosted version of that loop. You schedule monthly scans (smart weekly on the Agency plan) or turn on re-scan on deploy, and it runs Lighthouse on every selected page on mobile and desktop with PageSpeed Insights settings, recording the Lighthouse version and test region for each run. After each run you get an email with the change in the subject line, and alerts when scores drop. On Pro and Agency, a coding agent can trigger a re-scan through the [MCP server](/docs/mcp) after a fix. See [monitoring](/features/monitoring) for the details.

## A simple routine for small teams

You do not need a performance team to keep a site fast. A routine like this takes little time once it is set up:

1. **On every deploy:** Lighthouse CI on one URL per key template (homepage, a blog post, a product or service page, a landing page), three runs each, with warnings on Performance and errors on SEO and CLS.
2. **After major releases or tag manager changes:** a quick manual re-test of the affected templates.
3. **Weekly:** a scheduled scan of every page. Review anything that dropped across a template, and the top issues by pages affected.
4. **Monthly:** check field data in Search Console and the Chrome UX Report to confirm the lab trends match what real users see.
5. **Always:** keep a short changelog of deploys, plugin updates and new third-party tags, so you can match a drop to its cause.

Speed rarely degrades in one big step. It slips a few points at a time, through changes that each looked harmless. A small pipeline check plus a scheduled scan of every page catches those slips while they are still easy to trace back to the change that caused them.