performance-optimization

Performance Optimization

Make the interface feel instant and measure honestly: find where users wait, decide per wait whether to eliminate it (optimistic UI, preloading, batching) or mask it (skeletons, progressive loading), and implement the fix. The prime directive: perceived latency outranks actual latency — a 3-second operation that responds instantly to the click beats a 1-second one that freezes — but never fake what you can't deliver (no invented progress numbers, no optimistic UI where rollback would burn the user). Deliver an audit ranked by user impact plus working code.

When to use / when not to

Use for: sluggish-feeling interactions, optimistic UI, Core Web Vitals remediation, preloading/anticipatory loading, request batching/dedup, layout-shift fixes, perceived-performance strategy.

Hand off instead when the real need is:

• Choosing/designing the loading indicators themselves → skills/frontend-design/loading-states
• Animation jank from non-compositor properties → skills/frontend-design/interaction-physics (motion spec) or skills/frontend-design/design-engineer-mindset (rendering pipeline, layout thrashing)
• The failure/rollback messaging your optimistic UI needs → skills/frontend-design/error-handling-recovery
• Backend/query latency itself — flag it, but that's outside this skill's frontend scope

Step 0 — Inspect the codebase, then ask only what's left

1. Find the data layer: raw fetch/axios vs a data library (TanStack Query, SWR, Apollo, RTK Query). This decides implementation strategy — libraries get optimistic updates and dedup through their APIs; hand-rolled fetching may need those primitives added.
2. Find waiting patterns: mutations that disable the UI until the server responds, serial await chains that could parallelize, duplicate fetches of the same resource, effects re-fetching on every render.
3. Find layout-shift sources: images without dimensions/aspect-ratio, content injected above existing content, fonts swapping without fallback metrics, ad/embed slots without reserved space.
4. Look for existing measurement: web-vitals package, Lighthouse CI, RUM/analytics. If the project runs in this environment, get real numbers (Lighthouse or a profile) before and after — never quote scores you didn't measure.
5. Check bundle signals when load speed is the complaint: build output sizes, missing route-level code splitting, heavyweight dependencies imported globally.