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