domains / software-engineering / performance-profiling / performance-optimization

performance-optimization

Skill card

combined

The copies share the same high-level 'measure, identify, fix, verify' philosophy, but they target fundamentally different domains. The addyosmani and sickn33 copies are web-application focused (Core Web Vitals, Lighthouse, N+1 queries, HTTP/2), while the gamedev-skills copy is game-engine focused (frame budgets, draw calls, object pooling, GPU vs CPU bottlenecks). Because the specific steps, tools, and metrics are disjoint, crowning one would hide the other's domain-specific procedures.

Repositories

Other copies

Combined skill

---
name: performance-optimization
description: Optimizes application performance across web and game domains. Use when performance requirements exist, when you suspect performance regressions, or when profiling reveals bottlenecks.
---

# Performance Optimization

## Overview

Measure before optimizing. Performance work without measurement is guessing. Profile first, identify the actual bottleneck, fix it, measure again. Optimize only what measurements prove matters.

## When to Use

- Performance requirements exist in the spec (load time budgets, FPS targets, response time SLAs)
- Users or monitoring report slow behavior
- You suspect a change introduced a regression
- Building features that handle large datasets, high traffic, or complex scenes

**When NOT to use:** Don't optimize before you have evidence of a problem. Premature optimization adds complexity that costs more than the performance it gains.

## The Optimization Workflow

1. **MEASURE** → Establish baseline with real data
2. **IDENTIFY** → Find the actual bottleneck (not assumed)
3. **FIX** → Address the specific bottleneck
4. **VERIFY** → Measure again; keep or revert
5. **GUARD** → Add monitoring or tests to prevent regression

## Domain-Specific Procedures

### Web Applications

**Core Web Vitals Targets:**
| Metric | Good | Needs Improvement | Poor |
|--------|------|-------------------|------|
| **LCP** | ≤ 2.5s | ≤ 4.0s | > 4.0s |
| **INP** | ≤ 200ms | ≤ 500ms | > 500ms |
| **CLS** | ≤ 0.1 | ≤ 0.25 | > 0.25 |

**Measurement:**
- **Synthetic:** Lighthouse, DevTools Performance tab.
- **RUM:** web-vitals library, CrUX.

**Common Bottlenecks:**
- **Frontend:** Large bundles, render-blocking resources, layout shifts, heavy main-thread JS.
- **Backend:** N+1 queries, missing indexes, unbounded data fetching, memory leaks.

### Game Engines

**Frame Budget Math:**
- 60 FPS = 16.67 ms/frame. The whole frame (CPU sim + render submit + GPU) must fit the budget.
- Allocate sub-budgets (e.g., gameplay ~5ms, physics ~3ms, rendering ~4ms).

**Measurement:**
- Use engine-specific profilers (Godot Debugger, Unity Profiler, Unreal Insights).
- Identify if the bottleneck is CPU (logic/physics) or GPU (draw calls/shaders).

**Common Bottlenecks:**
- **CPU:** Per-frame allocations, GC spikes, heavy script logic.
- **GPU:** High draw calls, overdraw, complex shaders.

## Conflicts

- **gamedev-skills/awesome-gamedev-agent-skills** focuses on frame-time budgets and engine profilers.
- **addyosmani/agent-skills** focuses on Core Web Vitals and web-specific tools.

## Notes

- For web apps, prioritize Core Web Vitals and network waterfall analysis.
- For games, prioritize frame budget allocation and draw call reduction.
- Always profile a release/optimized build where possible, as debug builds can skew results.