Core Web Vitals monitoring that you will actually keep using
3 URLs free, 25 for $19 a month.
Running a speed test once tells you where you stand. Monitoring tells you when that changes. Most teams that care about Core Web Vitals end up checking the same pages over and over, by hand, after every release. This guide covers how to set up monitoring that runs without you and only speaks up when something matters.
Step 1: Pick the right URLs
You do not need to monitor every page. Monitor templates and money pages.
- Homepage. Often the most visited and the most changed.
- One URL per template. Product, category, article, landing page, pricing. A regression in a template affects every page that uses it.
- Top landing pages from search. Check your analytics for the pages that bring in the most organic visitors.
- Conversion pages. Cart, checkout entry and sign-up, as long as they are public.
For a small business, 10 to 25 URLs covers most of this. For a large store or publisher, 50 to 100 is common.
Step 2: Use lab and field data together
Lab data from Lighthouse reacts on the same day. If a deploy adds 500 KB of JavaScript, the lab test shows it tomorrow morning. That makes it the early warning system.
Field data from the Chrome UX Report reflects real users over 28 days. It is the data used in Google's page experience assessment, but it moves slowly. A regression may take a week or two to show clearly.
Watch lab data for fast detection, and field data for confirmation and for the metric lab tests cannot measure: Interaction to Next Paint.
Step 3: Set thresholds that mean something
Two kinds of alert work well together:
Threshold alerts. Fire when a metric crosses Google's "good" boundary: LCP over 2.5 s, INP over 200 ms, CLS over 0.1. These tell you when you have moved from passing to failing.
Regression alerts. Fire when a metric worsens by more than a set percentage against its recent median, even if it is still in the good range. These catch a page going from 1.2 s to 2.0 s LCP, which matters long before it fails.
Step 4: Fight noise
Lab tests are noisy. Server response times vary, third-party scripts load differently, and test machines have their own variance. If you alert on every single run, people learn to ignore alerts.
Ways to reduce noise:
- Run several tests per check and use the median. Vitals Clock runs three.
- Compare against a rolling baseline, such as the seven-day median, rather than yesterday alone.
- Require the change to exceed a minimum percentage.
- Send routine changes to a weekly summary and only urgent ones as instant alerts.
Step 5: Route alerts to someone who can act
An alert in an inbox nobody reads helps no one. Send performance alerts to the channel where developers discuss releases, often a Slack or Teams channel. Include the before and after values, the date it changed and any change in page weight or request count, so the person reading can connect it to a release.
Step 6: Review trends monthly
Once a month, look at field data trends for each URL. Are you passing on mobile? Has INP drifted up as features were added? Compare with competitors if you track them. These reviews turn monitoring data into a list of improvement work.
What monitoring will not do
It will not fix anything on its own, and it cannot test pages behind logins with public APIs. It also cannot tell you which line of code caused a regression, though page weight, request counts and the date of the change usually narrow it down fast.
How Vitals Clock fits
Vitals Clock runs Lighthouse lab tests through the PageSpeed Insights API one to four times a day depending on plan, collects Chrome UX Report field data for each URL and origin, applies both threshold and regression rules, and posts alerts by email, into Slack or Teams, or through a webhook.
Questions
How often should Core Web Vitals be checked?
Daily is enough for most sites. Sites that deploy many times a day benefit from several checks a day.
Should I monitor mobile or desktop?
Both, but prioritize mobile. It is usually slower and is what Google uses for mobile search.