audit-performance

Performance Audit Skill

Degree of freedom: MIXED — what to optimize [HIGH freedom]; measure-first Sentry/vitals and EXPLAIN [LOW freedom — run exactly].

Audit-and-fix exception. Measure, then optimize. JS payload → audit-bundle-size. Instant navigations → enhance-web-instant-nav. Breaking point → test-load. Timeouts/retries → audit-resilience. When fixing: change only the measured bottleneck and re-measure it; log other slow paths you notice as follow-ups, not fixes. Edit the existing file in place rather than rewriting it. Add a perf test only where the repo already keeps them or the task asks; scratch measurements stay out of the repo.

How to reason

1. Observe — quote LCP/INP/CLS, p95, or EXPLAIN / N+1 loop (file:line)
2. Interpret — is the user waiting on bytes, a query, or main-thread work?
3. Classify — vital-miss / N+1 / missing-index / bundle / image / re-render
4. Severity — poor LCP/INP or p95 >> target on a live path = Critical

Worked example

Observe: Sentry p95 /users = 2.3s; handler findAll then per-user Order.findByUserId (app/api/users/route.ts:31). Interpret: N+1; TTFB/LCP suffer on that page. Classify: N+1. Severity: Critical (p95 far over 200ms). Finding: /users | N+1 | eager-load orders | then re-measure

Step 0: Gather Performance Data [LOW freedom — run exactly]

Before optimizing, measure. Collect data from multiple sources.

Production Data (Sentry)

If Sentry performance monitoring is enabled, fetch real production metrics:

sentry:search_events
{
 "organizationSlug": "<ORG_SLUG>",
 "projectSlug": "<PROJECT_SLUG>",
 "regionUrl": "<REGION_URL>",
 "query": "slowest transactions by p95 duration in last 7 days",
 "limit": 20
}

sentry:search_events
{
 "organizationSlug": "<ORG_SLUG>",
 "projectSlug": "<PROJECT_SLUG>",
 "regionUrl": "<REGION_URL>",
 "query": "web vitals LCP INP CLS performance scores in last 7 days",
 "limit": 20
}