Short answer
On a monthly or quarterly schedule, we review Core Web Vitals field data in Search Console and PageSpeed Insights, run lab tests on your key templates, and compare them with the previous check. You get a short note each time: what changed, the likely cause and what to do about it.
Why monitoring is worth having
Most speed regressions are side effects. Someone adds a chat tool, a new analytics tag, a larger hero image or a plugin with a heavy script. Each change seems small. web.dev's guidance on tags notes that they tend to accumulate and recommends regular audits with an owner for each tag [1]. Without regular checks, the first sign of trouble is often a Search Console email weeks after the change that caused it.
What we check
Field data
Search Console's Core Web Vitals report uses data from the Chrome UX Report and groups URLs with a similar experience. Each group takes the status of its worst metric, and mobile and desktop are reported separately [2]. We read this report and the field section of PageSpeed Insights, which covers the previous 28 days [3], so we can see trends as they form.
Lab tests
Field data moves slowly. Lab tests on your key templates catch problems sooner, so we run them at each check under the same settings as before and compare. Lighthouse scores vary between runs, and Chrome's documentation notes that much of that variability is not caused by Lighthouse itself [4], so we look at the underlying metrics and repeat tests rather than reacting to a single score.
Page weight and scripts
We record image weight, script size and the list of third-party requests on each template. A new request in that list is often the first clue to what changed.
What you receive
- A short written note after each check, normally one page, with the numbers and the date.
- A clear flag when a metric moves from good to needs improvement, with the likely cause.
- A suggested fix and rough effort. Small fixes can be included in the plan; larger ones are quoted first.
When a check finds a problem
We trace the change, for example a new script or a theme update, and explain it in plain terms. If the cause is a tool your team chose deliberately, we suggest ways to keep it while reducing its cost, such as loading it later or only on the pages that need it. After a fix, Search Console can validate it; the report runs a 28-day monitoring session to check for the issue [2], so we note the date and follow up.
What monitoring cannot do
Monitoring is not live alerting. It will not page anyone at night if the site goes down; uptime services do that job. It also cannot stop changes from being made. What it does is make sure regressions are spotted within weeks rather than months, with a clear explanation of what happened.
Choosing a schedule
Monthly checks suit sites that change often, such as stores adding products and apps, or sites with active marketing teams. Quarterly checks suit brochure sites that change rarely. We recommend a monthly schedule for the first quarter after a speed project, because new releases and content changes are still settling in, then reviewing whether to drop to quarterly.
An example note
Here is the kind of note a monthly check might produce, for a fictional site. "Mobile LCP for product pages has moved from 2.3 to 2.9 seconds at the 75th percentile in Search Console over the past month. Lab tests show the main product image is now lazy-loaded. This started with the theme update on the 4th. Suggested fix: remove lazy loading from the first gallery image and restore its high fetch priority. Effort: small. INP and CLS are unchanged and good." The note is short on purpose: what changed, why, and what to do.
What we track at each check
| Item | Where it comes from |
|---|---|
| LCP, INP and CLS at the 75th percentile, mobile and desktop | Search Console and PageSpeed Insights field data |
| Lab metrics for each key template | Repeated lab tests under the same settings |
| Page weight, image weight and script size | Browser developer tools |
| Third-party requests | A list compared with the previous check |
| Changes since the last check | Your notes, plugin and theme update history |
Working with your team
Monitoring works best when we know what changed. A short message when you add a plugin, launch a campaign with new tags or update the theme makes each check quicker and more accurate. In return, the notes help your team understand the cost of each new tool, so speed becomes part of normal decisions rather than a separate project every few years.
Monitoring after a redesign or migration
The riskiest moments for speed are redesigns, platform moves and large theme updates. Templates are rebuilt, images are re-uploaded, plugins and apps are reinstalled, and tracking is added again, often by different people. We recommend a check shortly before launch on the staging site, another in the first week after launch using lab tests, and a field data review about four weeks later, once the 28-day window has filled with post-launch visits [3]. Catching a regression at that point is far cheaper than discovering it months later through a drop in Search Console's report.
Questions about monitoring
Do I need monitoring if I am not changing anything?
Platforms, plugins and third-party tools change on their own through updates. A quarterly check is a sensible minimum for most sites.
Will you fix problems you find?
Small fixes can be included in the plan. Larger ones are quoted in writing first so you can decide.
What if my site has no field data?
We rely on lab tests under consistent settings and say so in each note. Field data may appear as traffic grows.
Sources
Opened and checked on November 3, 2026.
- Best practices for tags and tag managers, web.dev. Primary documentation, last updated August 24, 2022.
- Core Web Vitals report, Search Console Help. Primary documentation, checked November 3, 2026.
- About PageSpeed Insights, Google for Developers. Primary documentation, last updated October 21, 2024.
- Lighthouse performance scoring, Chrome for Developers. Primary documentation, last updated September 19, 2019.