# Detect frontend performance regressions

> Compare page-load and interaction timing by release, browser, and route so frontend regressions are visible beside errors.

## Agent adaptation contract

- Canonical human page: https://agentry.sh/workflows/frontend-performance-regression
- Execution mode: on_demand
- Immutable automation template: none
- Applies to: b2c-saas, b2b-saas, ecommerce, marketplace, content-media, devtools-api
- Required example events: web_vital
- Required Agentry resources: none declared
- Do not use when:
  - Do not use until the example events are mapped to observed project signals, the current onboarding state is verified, and live event/property reads prove the required data is present.
- Ask before using:
  - Which observed events map to web_vital? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?
  - Which live properties provide web_vital.route, web_vital.metric, web_vital.value_ms, web_vital.release, web_vital.browser, and which stable user or account identifier joins the signals?

This is an adaptable workflow example, not an API recipe. Map event and property names to the project's saved signal map, require status: "verified" from GET /v1/projects/:project_id/onboarding, and confirm the required signals through live event/property metadata and rows. Fetch current OpenAPI or query-blueprint details before making calls. Do not infer unattended authority from this page.

## Why this matters

Some deploys do not throw errors. They just make checkout feel slower or the docs app sluggish. This workflow catches those regressions as product-impacting incidents.

## What you get

- Routes whose p75 or p95 performance regressed
- Browser and release segments
- A short list of likely product surfaces affected
- Follow-up queries for specific pages

## Walk through it

**You:**
> Did the latest frontend release slow anything down?

**Agent:**
> I'll compare `web_vital` timing by route and release.

```text
Endpoint: POST /v1/projects/:project_id/analytics/query
Exact shape: /v1/openapi.json?path=%2Fv1%2Fprojects%2F%7Bproject_id%7D%2Fanalytics%2Fquery&method=post
Custom HogQL goes in the OpenAPI-defined `query` field.
Concept fields:
  query: "SELECT properties.route AS route, properties.metric AS metric, properties.release AS release, properties.browser AS browser, quantile(0.75)(toFloat(properties.value_ms)) AS p75_ms, quantile(0.95)(toFloat(properties.value_ms)) AS p95_ms, count() AS samples FROM events WHERE event = 'web_vital' AND timestamp > now() - INTERVAL 7 DAY GROUP BY route, metric, release, browser ORDER BY p95_ms DESC LIMIT 50"
```

## The output

The agent returns the routes and browser segments that worsened, with enough sample size to be credible. It should call out low-sample rows instead of overclaiming.

## Setting it up

Post web-vital or page timing events from the browser with `AGENTRY_PUBLIC_API_KEY` auth. Include release and route template.

## Variations

- *"Only check checkout routes."*
- *"Compare Chrome mobile against desktop."*
- *"Publish this as a release readiness dashboard."*