# Performance Engineering

> Use when measuring, diagnosing, budgeting, or improving performance: latency, throughput, Core Web Vitals, database queries, caching, bundle size, concurrency, resource use, and regression prevention. Do NOT use for telemetry schema design alone (use `observability-modeling`), error capture setup (use `error-tracking`), or premature micro-optimization without a measured bottleneck.

- Skill: `jacob-balslev/performance-engineering-2` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add jacob-balslev/performance-engineering-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jacob-balslev/performance-engineering-2/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: jacob-balslev (https://skillmd.com/u/jacob-balslev)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/jacob-balslev/performance-engineering-2

---

# Performance Engineering

## Concept of the skill

Measuring, diagnosing, budgeting, and improving performance — latency, throughput, Core Web Vitals, database queries, caching, bundle size, concurrency, resource use, and regression prevention.

## Coverage

Measure and improve performance across frontend, backend, database, jobs, APIs, and tooling. Covers bottleneck analysis, performance budgets, Core Web Vitals, query plans, N+1 detection, caching, batching, concurrency, bundle size, resource use, regression checks, and tradeoffs.

## Philosophy of the skill
Measure first. Performance work without measurement is guessing, and guessing usually optimizes the easiest code rather than the bottleneck. The correct target is the user-visible or business-critical bottleneck with evidence.

Performance is also a contract. If speed matters, define budgets and regression checks before the system silently decays.

## Method

1. Define the performance goal and user/business impact.
2. Collect baseline measurements under realistic conditions.
3. Identify the bottleneck: network, server, database, rendering, bundle, CPU, memory, lock contention, or third party.
4. Choose the smallest intervention likely to move the bottleneck.
5. Verify improvement with the same measurement method.
6. Add a budget, alert, or regression test for the fixed surface.
7. Record tradeoffs such as freshness, complexity, cost, or cache invalidation risk.

## Evals

This skill ships a comprehension-eval artifact at [`examples/evals/performance-engineering.json`](https://github.com/jacob-balslev/skill-graph/blob/main/examples/evals/performance-engineering.json). The checklist below is the authoring gate for performance decisions; the eval file is the grader surface.

## Verification

- [ ] Baseline and post-change measurements use the same method
- [ ] The optimized target is the measured bottleneck
- [ ] User-visible or business impact is stated
- [ ] Cache changes include invalidation and staleness rules
- [ ] Database fixes include query-plan or index evidence when relevant
- [ ] Frontend fixes include bundle or Web Vitals evidence when relevant
- [ ] A regression guard exists for important performance surfaces

## Do NOT Use When

| Use instead | When |
|---|---|
| `observability-modeling` | You need to design telemetry schema and diagnostic signals. |
| `error-tracking` | You need error capture, redaction, source maps, or issue triage. |
| `testing-strategy` | You need general correctness test planning. |
| `refactor` | You are restructuring code without a measured performance goal. |