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
- Define the performance goal and user/business impact.
- Collect baseline measurements under realistic conditions.
- Identify the bottleneck: network, server, database, rendering, bundle, CPU, memory, lock contention, or third party.
- Choose the smallest intervention likely to move the bottleneck.
- Verify improvement with the same measurement method.
- Add a budget, alert, or regression test for the fixed surface.
- 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. The checklist below is the authoring gate for performance decisions; the eval file is the grader surface.
Verification
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. |
1---2name: performance-engineering-23description: "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."4license: MIT5---6# Performance Engineering78## Concept of the skill910Measuring, diagnosing, budgeting, and improving performance — latency, throughput, Core Web Vitals, database queries, caching, bundle size, concurrency, resource use, and regression prevention.1112## Coverage1314Measure 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.1516## Philosophy of the skill17Measure 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.1819Performance is also a contract. If speed matters, define budgets and regression checks before the system silently decays.2021## Method22231. Define the performance goal and user/business impact.242. Collect baseline measurements under realistic conditions.253. Identify the bottleneck: network, server, database, rendering, bundle, CPU, memory, lock contention, or third party.264. Choose the smallest intervention likely to move the bottleneck.275. Verify improvement with the same measurement method.286. Add a budget, alert, or regression test for the fixed surface.297. Record tradeoffs such as freshness, complexity, cost, or cache invalidation risk.3031## Evals3233This 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.3435## Verification3637- [ ] Baseline and post-change measurements use the same method38- [ ] The optimized target is the measured bottleneck39- [ ] User-visible or business impact is stated40- [ ] Cache changes include invalidation and staleness rules41- [ ] Database fixes include query-plan or index evidence when relevant42- [ ] Frontend fixes include bundle or Web Vitals evidence when relevant43- [ ] A regression guard exists for important performance surfaces4445## Do NOT Use When4647| Use instead | When |48|---|---|49| `observability-modeling` | You need to design telemetry schema and diagnostic signals. |50| `error-tracking` | You need error capture, redaction, source maps, or issue triage. |51| `testing-strategy` | You need general correctness test planning. |52| `refactor` | You are restructuring code without a measured performance goal. |
jacob-balslev