Performance regressions: the slow creep nobody ships on purpose

The slow-creep failure class

A crash pages someone; a 12 kB bundle increase pages no one. The defining property of performance regressions is that they arrive in increments below human perception: each sprint adds a dependency here, a client boundary there, an inline prop somewhere — every diff defensible, the cumulative sum a doubled p75. Review cannot catch this class, because no reviewer holds the running total in their head, and “this PR adds 1.8% to the bundle” is invisible without tooling that prints exactly that sentence. Typical unguarded creep rates, observed across teams: 5–15 kB minified per sprint of bundle growth, and p75 INP degrading from “good” (under 200 ms) to “poor” (over 500 ms) territory over two to three quarters with no single attributable release. The defense is not heroics; it is machinery that converts invisible increments into visible failures — budgets that fail builds, synthetics that diff releases, percentiles that diff rings.

Bundle creep and hydration growth

The lodash import is the canonical creep mechanism: CommonJS lodash is not tree-shakeable, so import { debounce } from 'lodash' ships the entire library — roughly 70 kB minified, ~25 kB gzipped — where lodash/debounce ships a few kB. The class generalizes: a charting library imported for one sparkline, a date library where Intl would do, a polyfill set for browsers you dropped. The countermeasure is a hard-fail CI byte budget per route entry (size-limit or equivalent): the build fails when a route crosses its budget, with the number in the PR check. Warn-only budgets die of alert fatigue within a quarter — every team that has run them has the same story: warnings accumulate, get normalized, get ignored; the regression ships anyway. The budget must fail the build or it is decoration.

Hydration growth is the React-specific variant. In an RSC app, marking one component 'use client' pulls it and its entire import graph into the client bundle — the cascade. The Hook’s table needed one hover tooltip; the boundary flip brought a markdown renderer and a date library, +90 kB of hydration work, all to track a boolean. The fix pattern is boundary isolation: keep the table on the server and extract a leaf HoverHint client component of twenty lines. Detection is the same byte budget, applied to the client bundle per route — the cascade shows up as a step change the build refuses.

Memo decay: the silent re-render regression

Memoization is a contract over reference identity, and refactors break it without breaking anything visible. When you add a prop to a memoized component, ask yourself: is this a new object or function created inline? If yes, every render creates a new reference and the memo comparison always fails. The decay pattern: a memoized list works for months; a refactor adds style={{ paddingLeft: depth * 8 }} or an inline onSelect at the call site; every prop comparison now fails; the subtree re-renders on every keystroke. No test fails — the output is identical. No error fires — re-rendering is legal. The only witnesses are the Profiler and, eventually, the INP percentiles. The evidence discipline is before/after Profiler data: the Hook’s table showed 4 ms commits with working memo, 41 ms with decayed memo, on every keystroke of every user for five months. Lint cannot fully catch this (it cannot know which subtrees are expensive), so the defense is layered: the React DevTools Profiler in code review for changes touching hot paths (“show me the commit profile for this refactor”), plus RUM INP attribution flagging the route afterward. Memo decay is also the strongest argument for the React Compiler: auto-memoization that survives refactors removes the human from the contract.

Three detection layers and the bisect discipline

No single layer catches everything; each has a blind spot the next covers. CI budgets see bytes pre-merge — instant, per-PR, but blind to runtime cost: a memo decay ships zero new bytes. Synthetic checks (Lighthouse CI or equivalent on a fixed device profile, per PR or hourly against production) see runtime cost on one device with fixture data — they catch a hydration step change but miss what only appears at real data scale (3,000 real rows versus the fixture’s 20) or on real low-end hardware. RUM percentiles per release ring see the truth — every device, every dataset — but lag by hours and require traffic; they are the layer that catches what both gates missed, and the layer that proves the other two are calibrated. When RUM flags a regression the gates missed, the bisect discipline is two diffs: the release diff (which commits shipped in the regressed ring — small if you deploy daily, which is itself an argument for deploy frequency) and the profile diff (synthetic trace or sampled field profile of the regressed route, before versus after, to name the component or task that got slower). With release rings and daily deploys the suspect set is usually under a dozen commits; without them it is the three-week hunt.

The budget contract: numbers and an owner

A perf budget that works is a per-route contract with three numbers and a name: JS bytes (e.g., 200 kB minified for the entry), LCP target (2.5 s at p75), INP target (200 ms at p75) — and an owning team. The owner clause is what makes it a contract instead of a dashboard: when the route breaches, the owning team gets the ticket, not a central “perf team” that owns everything and therefore nothing. Two operating rules keep it honest. Ratchet: when a route beats its budget comfortably, the budget tightens to lock in the gain — otherwise headroom gets silently spent. Exception protocol: raising a budget requires a recorded sign-off in the config, so every increase has a name, a date, and a reason attached. Teams running this report the same shape of outcome: creep stops being a quarterly archaeology project and becomes a per-PR conversation that takes five minutes while context is fresh.