home / skills / velcrafting / codex-skills / performance-pass-ui
This skill helps identify and reduce UI performance regressions by applying targeted optimizations with minimal, verifiable code changes.
npx playbooks add skill velcrafting/codex-skills --skill performance-pass-uiReview the files below or copy the command above to add this skill to your agents.
---
name: performance-pass-ui
description: Identify and reduce avoidable UI performance regressions (render churn, heavy computations, oversized bundles) without behavior change.
metadata:
short-description: UI perf pass
layer: frontend
mode: write
idempotent: true
---
# Skill: frontend/performance-pass-ui
## Purpose
Improve UI performance by removing obvious regressions and hotspots:
- unnecessary rerenders
- expensive derived computations on render
- unbounded lists or heavy DOM
- avoidable bundle bloat and lazy-load misses
This is a focused pass. It should not change user-facing behavior.
---
## Inputs
- Target UI surface (route/component)
- Reported symptom (slow render, jank, laggy typing, long TTI) if known
- Repo profile (preferred): `<repo>/REPO_PROFILE.json` (framework/tooling/commands)
- Existing instrumentation (React DevTools Profiler, performance marks, logs) if present
---
## Outputs
- Minimal code changes improving performance
- Notes in code comments where tradeoffs exist (why memoization, why virtualization, etc.)
- Optional: small measurement note in PR summary (before/after) if measurement is available
---
## Non-goals
- Visual redesign
- Refactoring purely for style
- Introducing new dependencies unless repo standard
- Premature micro-optimizations without evidence
---
## Workflow
1) Establish baseline:
- reproduce issue or identify likely hot path
- prefer measurable evidence (profiler, devtools, timing marks)
2) Identify top offenders:
- rerender cascades (props identity churn)
- heavy computations in render
- large lists without virtualization
- excessive re-fetch or revalidation loops
3) Apply smallest effective fix:
- memoize derived values (`useMemo`) only when computation is non-trivial
- stabilize callbacks (`useCallback`) only when it prevents churn
- split components to reduce rerender surface
- add list virtualization if large lists
- add lazy loading for heavy routes/components if repo uses it
4) Verify behavior unchanged:
- same UI output and interaction
5) Run validations from profile.
---
## Checks
- No user-visible behavior change (same UI states and interactions)
- Typecheck/lint pass if configured
- Performance improvement is plausible and localized:
- fewer renders in hot path OR
- reduced work per render OR
- reduced payload/deferral of heavy components
- No new infinite loops (effects, memo deps, query invalidations)
---
## Failure modes
- No evidence of perf issue → add minimal measurement first or decline changes.
- Memoization causes stale UI → fix dependencies or remove optimization.
- Optimization increases complexity too much → revert and propose a safer alternative.
- Large list performance issues → recommend virtualization; if not allowed, limit rendered rows.
---
## Telemetry
Log:
- skill: `frontend/performance-pass-ui`
- target: `<route/component>`
- techniques: `memo | split | virtualization | lazy-load | effect-fix | other`
- files_touched
- outcome: `success | partial | blocked`
This skill identifies and reduces avoidable UI performance regressions without changing user-visible behavior. It focuses on render churn, expensive computations during render, oversized bundles, and unbounded DOM work. Changes are minimal and evidence-driven, with notes in code for any tradeoffs.
Provide a target route or component and any reported symptom or existing profiler output. I reproduce or measure the hotspot, identify top offenders (props identity churn, heavy computations, large lists, lazy-load misses), and apply the smallest effective fixes such as memoization, component splitting, virtualization, or lazy loading. I verify no behavioral change, run project validations, and record telemetry about techniques and outcome.
Will this change the UI or user experience?
No. The intent is to preserve identical UI states and interactions while reducing unnecessary work under the hood.
Do you add new dependencies to the project?
Only if the repository standard already uses them; otherwise I prefer built-in techniques like memoization, splitting, or native lazy loading.
What if there is no profiling data?
I add minimal measurement first to establish a baseline and avoid blind micro-optimizations; if profiling is impossible, I point out safe, low-risk improvements or decline.