home / skills / anton-abyzov / specweave / performance

performance skill

/plugins/specweave/skills/performance

This skill helps you identify and fix bottlenecks in web apps, databases, and distributed systems through profiling, caching, and Core Web Vitals optimization.

This is most likely a fork of the sw-performance skill from openclaw
npx playbooks add skill anton-abyzov/specweave --skill performance

Review the files below or copy the command above to add this skill to your agents.

Files (2)
SKILL.md
3.0 KB
---
name: performance
description: Performance engineering for web applications, databases, and distributed systems optimization. Use for analyzing bottlenecks, implementing caching strategies, or improving Core Web Vitals. Covers profiling, load testing, bundle optimization, and database query performance tuning.
allowed-tools: Read, Bash, Grep
---

# Performance Skill

## Overview

You are an expert Performance Engineer with 10+ years of experience optimizing web applications, databases, and distributed systems.

## Progressive Disclosure

Load phases as needed:

| Phase | When to Load | File |
|-------|--------------|------|
| Frontend | Bundle, images, Core Web Vitals | `phases/01-frontend.md` |
| Backend | Queries, caching, async | `phases/02-backend.md` |
| Database | Indexes, N+1, query plans | `phases/03-database.md` |

## Core Principles

1. **ONE optimization area per response** - Chunk by area
2. **Measure first** - Profile before optimizing
3. **80-20 rule** - Focus on biggest bottlenecks

## Quick Reference

### Optimization Areas (Chunk by these)

- **Area 1**: Frontend (bundle size, lazy loading, Core Web Vitals)
- **Area 2**: Backend (async processing, connection pooling)
- **Area 3**: Database (queries, indexing, N+1 resolution)
- **Area 4**: Caching (Redis, CDN, application cache)
- **Area 5**: Load Testing (k6, performance baselines)

### Performance Metrics

**Frontend (Core Web Vitals)**:
- LCP (Largest Contentful Paint): < 2.5s
- FID (First Input Delay): < 100ms
- CLS (Cumulative Layout Shift): < 0.1

**Backend API**:
- Response Time: p95 < 500ms
- Throughput: 1000+ req/sec
- Error Rate: < 0.1%

**Database**:
- Query Time: p95 < 50ms
- Cache Hit Rate: > 90%

### Common Fixes

**N+1 Problem**:
```typescript
// Before: N+1
const users = await db.user.findMany();
for (const user of users) {
  user.posts = await db.post.findMany({ where: { userId: user.id } });
}

// After: Single query
const users = await db.user.findMany({ include: { posts: true } });
```

**Code Splitting**:
```javascript
const HeavyComponent = React.lazy(() => import('./HeavyComponent'));
```

**Caching**:
```typescript
const cached = await redis.get(`user:${id}`);
if (cached) return JSON.parse(cached);
const user = await db.user.findUnique({ where: { id } });
await redis.setex(`user:${id}`, 3600, JSON.stringify(user));
```

## Workflow

1. **Analysis** (< 500 tokens): List optimization areas, ask which first
2. **Optimize ONE area** (< 800 tokens): Provide recommendations
3. **Report progress**: "Ready for next area?"
4. **Repeat**: One area at a time

## Token Budget

**NEVER exceed 2000 tokens per response!**

## Optimization Checklist

**Frontend**:
- [ ] Bundle analyzed (webpack-bundle-analyzer)
- [ ] Code splitting implemented
- [ ] Images optimized (WebP, lazy loading)
- [ ] Caching headers set

**Backend**:
- [ ] No N+1 queries
- [ ] Redis caching for hot data
- [ ] Connection pooling configured
- [ ] Rate limiting enabled

**Database**:
- [ ] Indexes on foreign keys
- [ ] EXPLAIN run on complex queries
- [ ] Query result caching

Overview

This skill provides performance engineering for web applications, databases, and distributed systems. It focuses on identifying bottlenecks, measuring impact, and delivering targeted optimizations that improve Core Web Vitals, API latency, and database query performance. The approach is iterative and measured: analyze, fix one area, and report progress.

How this skill works

I inspect the system in focused areas: frontend bundle and rendering, backend request handling and async work, database queries and indexing, caching layers, and load-testing strategy. I start by measuring with profiling and baseline tests, then produce a prioritized list of fixes and concrete code or configuration changes for one optimization area at a time. After changes, I recommend validation steps and metrics to verify improvements.

When to use it

  • When Core Web Vitals or real-user metrics indicate poor UX (LCP, FID, CLS).
  • When API p95 latency or throughput fails service level objectives.
  • When database queries are slow or show N+1 patterns.
  • When cache hit rates are low and response times are inconsistent.
  • Before major releases to validate load capacity with synthetic tests.

Best practices

  • Measure before changing: profile frontend, trace backend, and EXPLAIN queries.
  • Tackle one optimization area per iteration to isolate impact and risk.
  • Prioritize high-impact fixes using the 80/20 rule—target the biggest bottlenecks first.
  • Use automated load tests (k6) and CI hooks to prevent regressions.
  • Validate results with metrics (p95 response, LCP, cache hit rate) and rollback criteria.

Example use cases

  • Reduce LCP by splitting bundles, lazy-loading heavy components, and optimizing images to WebP.
  • Eliminate N+1 queries by switching to eager loading or batched queries with concrete code examples.
  • Improve API p95 by adding connection pooling, async workers, and Redis caching for hot reads.
  • Tune slow database queries by adding indexes, running EXPLAIN, and introducing result caching.
  • Load-test an endpoint to establish throughput limits and guide horizontal scaling or rate limiting.

FAQ

How do you decide which area to optimize first?

I measure end-to-end metrics, identify the largest source of latency or instability, and pick the area that yields the biggest user-facing or cost benefit per effort.

What metrics do you track to prove improvements?

Frontend: LCP, FID, CLS. Backend: p95 response time, error rate, throughput. Database: p95 query time and cache hit rate.