Finding a page speed regression before your visitors do
Free for 3 URLs.
A page speed regression is any change that makes a page measurably slower than it was. Most regressions are not dramatic. They creep in with a new script here and a bigger image there. Catching them early, while the cause is still fresh in someone's memory, is far cheaper than a speed project six months later.
Where regressions come from
From what performance teams report, the usual sources are:
- New third-party scripts. Analytics, heatmaps, chat, personalization, consent tools and ad tags. Marketing teams often add these through a tag manager without a code deploy.
- Large media. A hero image uploaded at full camera resolution, or an autoplay video added to a landing page.
- Dependency updates. A framework or library upgrade that ships more JavaScript.
- Feature work. A new carousel, a product configurator or a reviews widget.
- Infrastructure changes. A new hosting setup, cache rules that stopped working, or a CDN configuration change.
- Theme or plugin updates on platforms like WordPress and Shopify.
Detecting a regression reliably
The hard part is telling a real regression from normal test variation. A single Lighthouse run can swing by several points with no change to the page.
A reliable method:
- Test on a schedule, at the same times each day.
- Run multiple tests per check and take the median. Three runs remove most outliers.
- Compare with a rolling baseline, such as the median of the past seven days.
- Use a percentage threshold that fits each metric. A 15 to 20 percent rise in LCP is usually real. A one-point drop in performance score is usually noise.
- Confirm with field data over the following weeks for the metrics users actually feel.
This is how Vitals Clock works by default, with adjustable thresholds per URL.
Tracing the cause
When an alert fires, you have a date and a before and after. Then:
- Check what shipped that day or the day before: deploys, CMS changes, tag manager publishes, plugin updates.
- Compare page weight and request count. A jump in bytes points to media or JavaScript. A jump in requests points to new third parties.
- Look at the Lighthouse diagnostics for the new run. New long tasks, new render-blocking resources and new large images show up there.
- Check the LCP element. If it changed, a design or content edit may be behind it.
- Revert or fix, then watch the next few checks return to baseline.
Prevent the next one
- Set a performance budget. For example, no more than a set amount of JavaScript on product pages. Check it in code review.
- Gate third-party scripts. Ask for a reason and an owner for each new tag.
- Compress images on upload in your CMS.
- Test in CI for code changes, and monitor production for everything that bypasses CI, which is most third-party and content changes.
Why production monitoring still matters with CI tests
CI tests catch code regressions before deploy. They do not see tag manager changes, CMS uploads, A/B tests or third-party scripts that change on their own. Those happen in production, so production needs its own daily check.
Questions
How quickly will I hear about a regression?
After the next scheduled check: within a day on Free, sooner on plans with more daily checks.
Can I mute alerts during a planned redesign?
Remove the URL from monitoring for the redesign, then add it back once the new version is live so it builds a fresh baseline.