Guide · 9 min read
A release that's slightly slower is a release that's broken. Here's how to catch it in CI — with budgets, baselines, and version-over-version gating that doesn't page you at 3 a.m. for noise.
Anvil's perf gate looks at three things: cold launch P95, first meaningful render P95, and dropped frame count during the canonical scroll spec. Those three, per device class, per OS minor. Everything else — binary size, memory high-water, battery drain — is tracked but not gated.
The reason: gating on twelve signals means ten of them fire spuriously every week and the team mutes all of them. Gating on three means failures are credible.
When you cut a new release, Anvil runs the canonical perf specs against the last three production-tagged versions on the device classes you've registered. The median P95 across those three is the baseline. Your new release is gated against baseline + 10%.
The 10% number is the empirical edge of noise we've measured across fleets of 50+ devices — below 10%, device thermal state and background OS work account for most of the variance. Above 10%, you're looking at a real regression.
When the gate fails, the CI comment links to three things: the failing run's perfetto trace (clickable timeline), the baseline run's trace for diffing, and a heuristic flamegraph diff that highlights the functions whose self-time grew.
The flamegraph diff uses symbol names resolved from the dSYM / mapping file you attached to the release — so "+38ms in processImageAsset_release" is actionable, not "+38ms in 0x1040a9c0c". Anvil stores dSYMs for the last 30 releases by default.
You will need to raise a budget occasionally. The right moments: a deliberate feature that loads more data on launch (and is worth the cost); a platform minor that changes the curve under your feet; a device class addition you didn't have last release.
The wrong moments: "tests are flaky"; "this week is busy"; "we'll fix it next sprint." Anvil's CLI prompts you to record a reason when you revise, and the reason becomes part of the release's perf record — so three releases later you can audit why budgets crept.
Perf gates run on real devices, not simulators. Simulators model the API surface correctly but the SoC not at all — a flow that's 80ms on an A17 Pro sim might be 340ms on a physical A15. The gate uses device classes you've registered (BYOD), with a fallback to the shared fleet for classes you don't own.
Once the gate is green, the CI comment posts a signed attestation — a JWT stamped by the device that ran the perf specs. Your release pipeline can treat the attestation as the proof-of-pass, rather than re-checking the numbers.
Ready to try it?
Free for 100 runs/month. No credit card.