---
name: frontend-performance-remediation
description: "Reproduce, diagnose, repair, and verify a concrete web or app frontend runtime performance problem and produce a Frontend Runtime Performance Remediation Record. Use when the primary job is jank, long-task latency, animation or scrolling cost, offscreen work, memory or listener growth, idle CPU/GPU use, or degradation after repeated navigation. Do not use for general interface design, backend throughput or load testing, product-wide observability design, or speculative optimization without a reproducible frontend symptom or budget."
---

# Frontend Performance Remediation

Repair a measured frontend runtime failure at its owning lifecycle, rendering,
or data-flow boundary. Produce one **Frontend Runtime Performance Remediation
Record** with comparable before-and-after evidence.

Read
[references/frontend-runtime-performance-method.md](references/frontend-runtime-performance-method.md)
before choosing instrumentation or a fix.

## Method

1. Freeze the exact candidate, runtime, device and viewport class, route and
   state, input sequence, data fixture, performance budget or user-visible
   symptom, and non-goals.
2. Reproduce before editing. Record a repeatable baseline for the failing path
   and enough control paths to distinguish local cost from application-wide or
   environmental noise.
3. Inventory every plausible producer of work on the path: rendering and
   layout, CSS animation, `requestAnimationFrame`, timers, listeners,
   observers, async work, network and decoding, workers, canvas/WebGL, retained
   objects, and third-party code.
4. Isolate the mechanism with source inspection plus runtime evidence. Test
   competing hypotheses; a profiler hotspot without ownership or a code smell
   without measured impact is not yet a diagnosis.
5. Correct the owning mechanism. Prefer eliminating unnecessary work, bounding
   lifetime and frequency, moving computation out of the critical path, and
   making visibility, cancellation, cleanup, and reduced-motion behavior
   explicit over adding throttling patches around an unknown cause.
6. Exercise repeated mount/unmount, navigation, background/foreground,
   offscreen/onscreen, idle, reduced-motion, compact/wide, and representative
   input paths where applicable. Prove resources stop and detach when their
   owner is no longer active.
7. Re-run the same scenario and controls on the exact changed candidate. Report
   distributions or repeated samples where noise matters, along with functional
   and visual regression checks.
8. Remove temporary probes that expose data or distort production behavior;
   retain only intentional, privacy-safe operating signals owned by the
   product.

## Integrity rules

- Do not optimize before reproducing the claimed problem.
- Do not call a screenshot, Lighthouse score, bundle-size change, or isolated
  synthetic microbenchmark proof of a runtime fix by itself.
- Do not invent universal thresholds. Use the product's declared budget or
  report exact measured change and unresolved user impact.
- Do not hide a leak behind a longer timer, blanket debounce, disabled
  animation, route reload, or periodic cleanup when the owner can release the
  resource correctly.
- Keep source evidence and browser/runtime observations distinct, and bind both
  to the exact candidate and scenario.
- Preserve behavior, accessibility, reduced-motion meaning, visual intent, and
  input correctness unless an approved product decision changes them.

## Output contract

Produce one **Frontend Runtime Performance Remediation Record** containing:

- exact candidate and baseline, scenario matrix, environment, budget or
  symptom, control paths, assumptions, and non-goals;
- work-producer and lifecycle inventory with ownership and cleanup semantics;
- tested hypotheses, evidence, rejected explanations, and root-cause statement;
- changed files and mechanism-level correction;
- comparable before/after runtime evidence with sampling method and uncertainty;
- repeated-route, idle, visibility, cleanup, reduced-motion, responsive,
  functional, accessibility, and visual regression results as applicable; and
- remaining limits or unavailable evidence, without relabeling them as green.

## Routing boundaries

- `interface-craft` owns baseline performance while designing, building, or
  polishing one interface. Use this Skill when performance diagnosis and
  remediation is itself the requested artifact.
- `engineering-standard` supplies binding implementation and defect-repair
  invariants and composes into code-changing work without emitting a separate
  report.
- `operational-observability-review` owns product-wide logs, metrics, traces,
  SLOs, alerts, operator workflows, and recovery evidence.
- Backend latency, capacity, database, queue, and distributed load problems
  remain with their owning engineering or reliability work.
- Formal accessibility conformance remains with its specialist; this Skill
  must still preserve baseline accessible interaction and reduced-motion
  behavior.

Complete only when the original symptom is reproducible, the causal mechanism
is supported by source and runtime evidence, the owner-level correction is
landed in the candidate, and the same scenario demonstrates the improvement
without hiding functional, visual, lifecycle, or accessibility regressions.