Optimize

Optimize Skill

Overview

The optimize skill provides comprehensive on-demand performance and optimization analysis for your codebase. It identifies bottlenecks, slow builds, large bundles, inefficient code patterns, and opportunities for performance improvements across all supported technology stacks.

When to Use:

• Performance issues and slow response times
• Large bundle sizes and slow page loads
• Long build and compile times
• High memory usage
• Database query optimization
• API endpoint performance tuning
• CI/CD pipeline optimization

Technology Coverage:

• React/TypeScript/JavaScript (Vite, Webpack, Rollup)
• Go applications (build time, runtime performance)
• Rust projects (compile time, binary size)
• Python codebases (runtime optimization)
• Full-stack applications
• Database queries (SQL, ORM)

Optimization Categories

1. Build Performance

What Gets Analyzed:

• Build duration and bottlenecks
• Dependency resolution time
• TypeScript compilation speed
• Asset processing (images, fonts)
• Code splitting effectiveness
• Cache utilization

Common Issues:

• Unnecessary re-builds of unchanged code
• Large dependency trees
• Inefficient TypeScript configuration
• Missing build caching
• Redundant asset processing

Optimization Targets:

• Reduce build time by 30-50%
• Enable incremental builds
• Optimize dependency resolution
• Improve cache hit rates

2. Bundle Size

What Gets Measured:

• Total bundle size (uncompressed/gzipped)
• Individual chunk sizes
• Duplicate dependencies
• Tree-shaking effectiveness
• Unused code in bundles
• Third-party library sizes

Bundle Analysis:

Bundle Size Breakdown:
├── vendor.js: 847 KB (312 KB gzipped)
│   ├── react-dom: 142 KB
│   ├── lodash: 71 KB (should use lodash-es)
│   ├── moment: 67 KB (consider date-fns)
│   └── ...
├── main.js: 234 KB (89 KB gzipped)
└── [lazy chunks]: 156 KB total

Optimization Goals:

• Keep initial bundle under 200 KB (gzipped)
• Lazy load non-critical code
• Remove duplicate dependencies
• Use lighter alternatives

3. Runtime Performance

What Gets Profiled:

• Function execution time
• Component render performance
• Memory allocation patterns
• Garbage collection pressure
• Event loop blocking
• Async operation efficiency

Performance Metrics:

• Time to First Byte (TTFB)
• First Contentful Paint (FCP)
• Largest Contentful Paint (LCP)
• Total Blocking Time (TBT)
• Cumulative Layout Shift (CLS)

Detection Methods:

• Profiling data analysis
• Flame graph generation
• Hot path identification
• Memory leak detection

4. Memory Usage

What Gets Monitored:

• Heap allocation patterns
• Memory leaks
• Large object retention
• Closure memory overhead
• Cache memory usage
• Buffer allocation

Red Flags:

• Growing heap over time (leak)
• Excessive garbage collection
• Large retained objects
• Detached DOM nodes (React)
• Unclosed connections/subscriptions

5. API and Database Performance

What Gets Analyzed:

• Query execution time
• N+1 query problems
• Missing database indexes
• API response times
• Network round trips
• Cache effectiveness

Database Optimization:

• Slow query identification
• Index recommendations
• Query plan analysis
• Connection pooling efficiency

Analysis Patterns

Identifying Bottlenecks

Step 1: Measure Current Performance

Collect baseline metrics:

• Build time: time npm run build
• Bundle size: Analyze with webpack-bundle-analyzer
• Runtime: Browser DevTools Performance tab
• API: Response time logs

Step 2: Profile and Identify Hot Paths

Find where time is spent:

• CPU profiling for computation
• Heap snapshots for memory
• Network waterfall for I/O
• Flame graphs for call stacks

Step 3: Prioritize Optimizations

Focus on:

1. Highest impact (largest bottleneck)
2. Lowest effort (quick wins)
3. Most frequent (called often)

Step 4: Measure Impact

After optimization:

• Re-run benchmarks
• Compare before/after metrics
• Validate improvements

Tools and Commands

JavaScript/TypeScript:

# Bundle analysis
npx webpack-bundle-analyzer dist/stats.json

# Build performance
npm run build -- --profile --json > stats.json

# Runtime profiling
node --prof app.js
node --prof-process isolate-*.log > processed.txt

Go:

# Build time analysis
go build -x 2>&1 | ts '[%Y-%m-%d %H:%M:%S]'

# CPU profiling
go test -cpuprofile=cpu.prof -bench=.
go tool pprof cpu.prof

# Memory profiling
go test -memprofile=mem.prof -bench=.
go tool pprof mem.prof

Rust:

# Compile time analysis
cargo build --timings

# Binary size analysis
cargo bloat --release

# Runtime profiling
cargo flamegraph --bench benchmark_name

Optimization Report Format

Performance Report Structure

# Performance Optimization Report

**Generated**: 2026-01-28 14:32:00
**Scope**: Full application analysis
**Baseline**: Established 2026-01-21

## Executive Summary

**Overall Performance Score**: 67/100 (Needs Improvement)

**Key Findings**:
- Build time: 142s (Target: <60s) - 58% slower
- Bundle size: 1.2 MB gzipped (Target: <200 KB) - 6x over
- LCP: 3.8s (Target: <2.5s) - Poor
- API p95: 847ms (Target: <500ms) - Slow

**Estimated Impact of Recommendations**:
- Build time: -65s (46% improvement)
- Bundle size: -800 KB (67% reduction)
- LCP: -1.5s (39% improvement)
- API p95: -400ms (47% improvement)

## Critical Bottlenecks

### [PERF-001] Lodash Full Library Import
**Category**: Bundle Size
**Impact**: HIGH
**Effort**: LOW

**Issue**: Full lodash library imported, adding 71 KB to bundle.

**Current**:
```typescript
import _ from 'lodash';
const result = _.debounce(handler, 300);

Problem: Imports entire library for single function.

Recommendation: Use lodash-es with tree-shaking.

Optimized:

import { debounce } from 'lodash-es';
const result = debounce(handler, 300);

Savings: -65 KB gzipped

[PERF-002] Moment.js for Simple Date Formatting

Category: Bundle Size Impact: MEDIUM Effort: LOW

Issue: moment.js adds 67 KB for basic date formatting.

Current:

import moment from 'moment';
const formatted = moment(date).format('YYYY-MM-DD');

Recommendation: Replace with date-fns or native Intl.

Optimized:

import { format } from 'date-fns';
const formatted = format(date, 'yyyy-MM-dd');

Savings: -60 KB gzipped

[PERF-003] TypeScript Compilation Bottleneck

Category: Build Time Impact: HIGH Effort: MEDIUM

Issue: TypeScript taking 89s of 142s build time (63%).

Current Config:

{
  "compilerOptions": {
    "incremental": false,
    "skipLibCheck": false
  }
}

Problems:

• No incremental compilation
• Checking all .d.ts files
• No build cache

Optimized:

{
  "compilerOptions": {
    "incremental": true,
    "skipLibCheck": true,
    "tsBuildInfoFile": ".tsbuildinfo"
  }
}

Savings: -45s build time (first build), -70s (subsequent)

[PERF-004] N+1 Query in User Profile API

Category: API Performance Impact: CRITICAL Effort: LOW

Issue: Loading user posts in a loop, causing 100+ database queries.

Current:

const users = await db.getUsers();
for (const user of users) {
  user.posts = await db.getPostsByUserId(user.id); // N+1!
}

Problem: 1 query + N queries = 101 total for 100 users.

Optimized:

const users = await db.getUsers();
const userIds = users.map(u => u.id);
const posts = await db.getPostsByUserIds(userIds); // 1 query
const postsByUser = groupBy(posts, 'userId');
users.forEach(user => {
  user.posts = postsByUser[user.id] || [];
});

Savings: 99 database queries eliminated, 95% faster

Build Performance Analysis

Current Build Breakdown

Total Build Time: 142s

Phase Breakdown:
├── Dependencies (npm install): 23s (16%)
├── TypeScript Compilation: 89s (63%)
├── Asset Processing: 18s (13%)
├── Bundling (Webpack): 9s (6%)
└── Minification: 3s (2%)

Bottleneck: TypeScript (63% of time)

Optimization Recommendations

1. Enable Incremental TypeScript (HIGH IMPACT)

• Savings: -70s on subsequent builds
• Add incremental: true to tsconfig.json

2. Parallelize Asset Processing (MEDIUM IMPACT)

• Savings: -10s
• Use worker threads for image optimization

3. Use SWC Instead of Babel (MEDIUM IMPACT)

• Savings: -5s
• 20x faster than Babel

Total Potential Savings: -85s (60% improvement)

Target Build Time: 57s

Bundle Size Analysis

Current Bundle Breakdown

Total Bundle Size: 1.2 MB gzipped

Dependencies:
├── react + react-dom: 142 KB (12%)
├── lodash: 71 KB (6%)
├── moment: 67 KB (6%)
├── chart.js: 54 KB (5%)
├── Other vendor: 445 KB (37%)
└── Application code: 421 KB (34%)

Issues:
- Lodash not tree-shaken
- Moment.js unnecessary
- Large chart library for simple use

Optimization Recommendations

1. Replace Heavy Dependencies (HIGH IMPACT)

• lodash → lodash-es: -65 KB
• moment → date-fns: -60 KB
• chart.js → lightweight-charts: -40 KB
• Total: -165 KB (14% reduction)

2. Code Splitting (HIGH IMPACT)

• Lazy load admin panel: -200 KB from initial
• Lazy load dashboard charts: -150 KB from initial
• Total: -350 KB from initial load (29% reduction)

3. Tree Shaking Improvements (MEDIUM IMPACT)

• Fix sideEffects in package.json
• Remove unused exports
• Estimated: -100 KB (8% reduction)

Total Potential Savings: -615 KB (51% reduction)

Target Bundle Size: 585 KB gzipped