Web Vitals Regression Alerts: An Issue When Pages Get Slower for Real Users

Last verified on Nov 10, 2026.

What it catches

A page can get worse without anything failing. No exception, no failed request, no failed health check. A script is added, an image grows, a render path blocks. The page loads, but a visitor on a mid-range phone waits longer, taps and nothing happens, or watches the layout move under their thumb.

Web vitals regression asks whether the page-load and interaction timings your visitors record have moved against what is usual for that page. Think of the headline measurements: how long the main content takes to appear, how long the page takes to respond to a tap, how much the layout shifts. The signal works on whatever timing events your app logs.

Where it points:

• A new third-party tag blocks the main thread on one route.
• A hero image or font change slows the first paint.
• A framework upgrade makes a handler slow on touch devices.
• A feature flag turns on a heavy widget for a share of users.
• A data change makes a list render with many more rows.

Example: interaction latency doubles on one page

This is an example, not output from a real project. Your web app sends a timing event after each interaction on the pricing page. On a normal day the p75 is about the same across releases:

2026-11-08T11:15:03Z INFO web interaction_timing route=/pricing target=plan-toggle duration_ms=96 device=mobile release=2026.11.07
2026-11-08T12:22:41Z INFO web interaction_timing route=/pricing target=plan-toggle duration_ms=410 device=mobile release=2026.11.08
2026-11-08T12:24:10Z INFO web interaction_timing route=/pricing target=plan-toggle duration_ms=388 device=mobile release=2026.11.08

After a release the plan toggle is several times slower for mobile visitors. Sazabi opens an issue. An example of the contents:

• Name: Plan toggle interactions slower on /pricing after release 2026.11.08
• Description: Interaction timings on /pricing are well above their usual level, on mobile only. The change starts with the first events from release 2026.11.08.
• Severity: medium

The release field in the events is what turns "the page feels slow" into a version to look at.

How Sazabi sets it up

The Sazabi agent sets up sensors for your project and maintains them over time. For this signal it reads your logs, finds the page-load and interaction timing events, and writes a question such as: "Tell me when the 75th percentile interaction time on a route goes well above its usual level."

Each route is judged on its own, so a regression on one page stands out from the others. You set nothing up: the agent writes, backtests and maintains the sensors, and keeps them current as your pages change.

A firing records a signal and starts an investigation, and an issue opens when the slowdown is real.

What you see and how you get told

The issue names the route, the timing that moved and what changed alongside it, such as a release or a device type. Follow up in the thread, or run sazabi issues agent-prompt to give the work to a coding agent. Issue triggered lands in the in-app feed, and a delivery rule can send it to a shared Slack or Microsoft Teams channel for the frontend team. sazabi signals list --type sensor lists the underlying firings.

What you need

Timing events from your frontend. Sazabi's browser and app telemetry covers errors and sessions, and it does not collect page timings by itself, so your code has to log them. Send them with the route, a device class and your release, then connect them through OpenTelemetry or another source. For the glossary background, see latency percentiles.

What it does not cover

• Timings your app never sends.
• Lab and scripted tests of a page.
• Page crashes and script errors. Those are client errors and appear under frontend breakage.
• Search ranking effects of slower pages.

If you want the measurement side done by hand, the guide to web vitals monitoring walks through it. Issues are metered; see pricing.