Perf Analyzer

Performance Analyzer Skill

Purpose

Analyzes frontend application performance and suggests optimizations for bundle size, rendering, and images.

When to Use

• Performance analysis requests
• "Slow", "long loading" mentions
• Bundle size, rendering, Core Web Vitals questions
• Pre-production performance review

Workflow

Step 1: Select Analysis Areas

AskUserQuestion:

"Which areas to analyze?"
Options:
- Full performance analysis (recommended)
- Bundle size analysis
- Rendering performance (re-renders)
- Image/asset optimization
- Code splitting opportunities
multiSelect: true

Analysis Areas

Bundle Size

Large Dependencies:

// WARNING: Large libraries
import _ from 'lodash'         // 71KB
import moment from 'moment'    // 280KB

// BETTER: Lightweight alternatives
import debounce from 'lodash/debounce'  // 2KB
import { format } from 'date-fns'        // Only needed functions

Tree-shaking Issues:

// BAD: Full import (no tree-shaking)
import * as utils from './utils'

// GOOD: Named import
import { specificFunction } from './utils'

Rendering Performance

Unnecessary Re-renders:

// WARNING: New object/array every render
function Component() {
  return <Child style={{ color: 'red' }} />  // New object each time
}

// BETTER: External definition
const style = { color: 'red' }
function Component() {
  return <Child style={style} />
}

Expensive Computations:

// WARNING: Computed every render
function Component({ data }) {
  const processed = data.map(item => expensiveOp(item))
  return <List items={processed} />
}

// BETTER: useMemo caching
const processed = useMemo(
  () => data.map(item => expensiveOp(item)),
  [data]
)

Callback Optimization:

// WARNING: New function every render
<Child => handleClick()} />

// BETTER: useCallback
const handleClick = useCallback(() => { /* ... */ }, [])
<Child />

Image Optimization

// BAD: No optimization
<img src="/hero.jpg" alt="Hero" />

// GOOD: next/image
<Image
  src="/hero.jpg"
  alt="Hero"
  width={1200}
  height={600}
  priority  // LCP image
  placeholder="blur"
/>

Code Splitting

// WARNING: Unnecessary initial load
import HeavyComponent from './HeavyComponent'

// BETTER: Load on demand
const HeavyComponent = dynamic(() => import('./HeavyComponent'), {
  loading: () => <Skeleton />
})

Core Web Vitals

LCP (Largest Contentful Paint)

FID (First Input Delay)

CLS (Cumulative Layout Shift)

Response Template

## Performance Analysis Results

**Project**: [name]

### Bundle Size
| Item | Size | Status |
|------|------|--------|
| Total bundle | 650KB | WARNING |
| Initial JS | 180KB | OK |

**Large Dependencies:**
| Package | Size | Alternative |
|---------|------|-------------|
| moment | 280KB | date-fns (7KB) |
| lodash | 71KB | lodash-es + individual imports |

### Rendering Performance
| Component | Issue | Recommendation |
|-----------|-------|----------------|
| ProductList | Unnecessary re-renders | Add useMemo |

### Image Optimization
| Image | Size | Recommendation |
|-------|------|----------------|
| hero.jpg | 450KB | Convert to WebP, use next/image |

### Code Splitting Opportunities
| Component | Size | Recommendation |
|-----------|------|----------------|
| Dashboard | 85KB | dynamic import |

### Priority Actions
1. [ ] moment → date-fns migration (-273KB)
2. [ ] Add useMemo to ProductList
3. [ ] Convert hero.jpg to WebP
4. [ ] Dynamic import Dashboard

### Expected Improvements
- Initial bundle: 650KB → ~350KB (-46%)
- LCP: Expected improvement
- TTI: Expected improvement

Best Practices

1. Measure First: Always measure before optimizing
2. Incremental: Apply one change at a time
3. Trade-offs: Avoid over-optimization
4. Real Device Testing: Test on low-end devices
5. Continuous Monitoring: Prevent performance regression

Integration

• code-reviewer skill
• nextjs-reviewer skill
• /analyze-code command

Notes

• Static analysis based, runtime performance may differ
• Use with Lighthouse for actual measurements
• Analyze production builds