domains / software-engineering / performance-optimization / performance

performance

Skill card

combined

The three skills share the name 'performance' but target fundamentally different systems and workflows. The first is a Unity-specific C# review checklist (GC, Update loops, pooling). The second is a web performance optimization guide focused on Core Web Vitals, resource budgets, and browser tracing. The third is a UI/UX performance skill that enforces specific Web Vitals budgets and relies on a local design system kit. Because they address different domains (game engine vs. web platform vs. UI design system) and contain non-overlapping, material steps (e.g., Unity's 'hidden costs' vs. Web's 'Early Hints' vs. UI's 'kit check'), crowning one would hide the other two valid approaches. They must be combined to preserve the distinct procedures for each context.

Repositories

Other copies

Combined skill

---
name: performance
description: Optimize performance for Unity, Web, or UI contexts. Use when asked to speed up a site, fix Unity frame drops, or improve UI responsiveness.
---

# Performance Optimization

This skill covers three distinct performance domains. Identify the target system and follow the corresponding section.

## 1. Unity Performance (Game Engine)
Use for C# Unity projects. Focus on red flags, not micro-optimizations.

**Check For:**
- Too many unrelated `Update`/`LateUpdate` loops.
- Repeated `Find`, `GetComponent`, or `Camera.main` in hot paths.
- Frequent `Instantiate`/`Destroy` suitable for pooling.
- Per-frame allocations (LINQ, string formatting, closures).
- Reflection in runtime hot paths.

**Hidden Costs:**
- **Write Permission:** Components that *can* mutate state pay serialization costs even if they don't. Split rarely-needed writers into separate components.
- **Correlated RNG:** Seeding N RNGs with `baseSeed + i` creates correlated streams. Hash the index before seeding.
- **Logging:** `Debug.Log` is not stripped in release builds. Guard log expressions with `if (Debug.isDebugBuild)`.

**Output:** Confirmed red flags, likely red flags, changes worth doing now, and expected gain category.

## 2. Web Performance (Browser/Server)
Use for web applications. Evidence-led optimization using real-user signals.

**Workflow:**
1. Establish a field-plus-lab baseline.
2. Prioritize poor Core Web Vitals.
3. Use DevTools traces to find causes.
4. Change only code connected to measured bottlenecks.
5. Re-run measurements and report before/after values.

**Budgets (Initial Guardrails):**
- Total page weight: < 1.5 MB
- JavaScript: < 300 KB
- CSS: < 100 KB
- Images (above-fold): < 500 KB

**Critical Rendering Path:**
- **TTFB:** < 800ms. Use CDN, caching, and compression (Brotli preferred).
- **Preconnect/Preload:** Preconnect to required origins. Preload only resources whose late discovery is visible in the trace.
- **JavaScript:** Defer non-essential scripts. Use code splitting for routes and heavy components.

## 3. UI/UX Performance (Design System)
Use for UI components and design systems. Treat performance as an accessibility concern.

**Prerequisites:**
- Check for the design system kit: `ls ${CLAUDE_SKILL_DIR}/../../../tokens >/dev/null 2>&1`. If missing, stop and direct user to install.

**Steps:**
1. Read `workflows/performance.md` for specific targets.
2. Diagnose against budgets: **LCP ≤ 2.5s**, **INP ≤ 200ms**, **CLS ≤ 0.1** on mid-tier mobile.
3. **Loading:** Render above-fold first (SSR). Code-split by route. Lazy-load below-fold.
4. **Layout Shift:** Size skeletons to final dimensions. Reserve media space via `aspect-ratio`. Never inject content above existing.
5. **Animation:** Only use `transform`/`opacity`. Use `will-change` sparingly. Honor `prefers-reduced-motion`.

**Verification:**
- Lighthouse/field data meets LCP, INP, and CLS budgets.
- First interaction remains responsive under slow-4G + 4× CPU throttle.
- Zero CLS on load; no non-compositor animation in loops.