/workers-optimize

name: cloudflare-workers:optimize
description: Analyze and optimize Cloudflare Workers performance. Checks bundle size, caching, memory usage, and provides actionable recommendations.
allowed-tools:
  - Read
  - Grep
  - Bash
  - Glob
argument-hint: "--target <bundle|memory|cache> (optional: focus analysis)"

Workers Optimize Command

Comprehensive performance analysis and optimization for Cloudflare Workers.

Execution Workflow

Phase 1: Analysis Scope Determination

**If --target argument provided**:

• Focus analysis on specified area (bundle, memory, or cache)
• Skip other analyses for faster results

**If no --target argument**:

• Run complete performance audit
• Analyze all optimization areas

Phase 2: Bundle Size Analysis

Analyze Worker bundle size and identify bloat:

1. **Build Worker and check output size**:

bunx wrangler deploy --dry-run --outdir=.wrangler-output
du -h .wrangler-output/

2. **Parse bundle size**:

• Extract total bundle size in KB
• Compare against limits:
• Free tier: 1MB limit
• Paid tier: 10MB limit
• Flag if >50% of limit used

3. **Identify large dependencies**:

# Analyze package.json dependencies
grep -A 100 '"dependencies"' package.json

Common bloat sources:

• `moment.js` (large, use `date-fns` instead)
• `lodash` (use `lodash-es` for tree-shaking)
• `axios` (use native `fetch`)
• Large UI libraries in backend code

4. **Check for unnecessary imports**:

• Grep for wildcard imports: `import * as`
• Check for unused imports in main worker file
• Look for dev dependencies in production bundle

**Findings**:

### Bundle Size Analysis

**Current Size**: X KB / Y MB limit (Z% used)

**Large Dependencies**:
1. [package-name]: X KB
2. [package-name]: X KB

**Recommendations**:
- Remove [package] (unused in production)
- Replace [package] with [lighter alternative]
- Use dynamic imports for [feature]

Phase 3: Caching Analysis

Analyze Cache API usage and opportunities:

1. **Check for Cache API usage**:

grep -r "caches.open" src/
grep -r "cache.match" src/
grep -r "cache.put" src/

2. **Identify cacheable endpoints**:

• Look for GET routes
• Check for static responses
• Find repeated external API calls

3. **Check cache headers**:

grep -r "Cache-Control" src/
grep -r "max-age" src/

**Findings**:

### Caching Analysis

**Cache API Usage**: [Found/Not Found]

**Cacheable Opportunities**:
1. Route: /api/data - No caching detected
2. Route: /static/* - Could cache for 24h
3. External API: api.example.com - Called 100x/min, no caching

**Recommendations**:
- Implement Cache API for /api/data (TTL: 5min)
- Add Cache-Control headers for static assets
- Cache external API responses (TTL: 1h)

Phase 4: Memory Usage Analysis

Analyze memory patterns and identify leaks:

1. **Check for large in-memory objects**:

grep -r "new Map(" src/
grep -r "new Set(" src/
grep -r "const data = " src/

2. **Identify potential memory leaks**:

• Global variables that accumulate data
• Event listeners not cleaned up
• Large arrays/objects not released

3. **Check for streaming opportunities**:

• Look for large response bodies
• Check if reading entire request body at once
• Identify file upload/download endpoints

**Findings**:

### Memory Usage Analysis

**Potential Issues**:
1. Global Map at line X - grows unbounded
2. Large array created at line Y - not cleaned up
3. File uploads read entire body - use streaming

**Recommendations**:
- Use WeakMap for caching with automatic cleanup
- Implement streaming for files >1MB
- Clear arrays after processing

Phase 5: Cold Start Analysis

Analyze factors affecting cold start performance:

1. **Check for top-level await**:

grep -n "await" src/index.ts | grep -v "async"

• Top-level await blocks cold start
• Move to request handler or lazy load

2. **Check import patterns**:

• Count total imports
• Identify heavy initialization code
• Look for synchronous I/O at module level

3. **Check for large constants/data**:

• JSON files imported at top level
• Large configuration objects
• Embedded data that could be external

**Findings**:

### Cold Start Analysis

**Blocking Factors**:
1. Top-level await at line X
2. Heavy computation in module scope
3. 50KB JSON imported at module level

**Recommendations**:
- Move await into request handler
- Lazy load heavy dependencies
- Store large data in KV, load on demand

Phase 6: CPU Time Analysis

Check for CPU-intensive operations:

1. **Identify expensive operations**:

grep -r "for (" src/
grep -r "while (" src/
grep -r "map(" src/
grep -r "filter(" src/
grep -r "reduce(" src/

2. **Check for blocking operations**:

• Synchronous crypto operations
• Large JSON parsing
• Complex regex patterns
• Heavy string manipulation

**Findings**:

### CPU Time Analysis

**Expensive Operations**:
1. Nested loop at line X - O(n²) complexity
2. Large JSON.parse() without streaming
3. Complex regex: /(?:...){1000,}/ - catastrophic backtracking

**Recommendations**:
- Optimize algorithm to O(n)
- Stream large JSON payloads
- Simplify regex or use string methods

Phase 7: External Dependencies Analysis

Analyze external API calls and database queries:

1. **Count external fetch calls**:

grep -r "fetch(" src/ | wc -l

2. **Check for parallel requests**:

grep -r "Promise.all" src/
grep -r "await.*await" src/

• Sequential awaits slow down responses
• Opportunities for parallelization

3. **Database query patterns**:

• Check for N+1 queries
• Look for missing indexes
• Identify slow queries

**Findings**:

### External Dependencies

**API Calls**: X total found

**Issues**:
1. Sequential calls to 3 APIs - add 300ms latency
2. Database N+1 query pattern
3. No timeout on external fetch

**Recommend