- name
- performance-audit
- description
- Comprehensive performance analysis to identify bottlenecks, optimization opportunities, and scalability issues.
- disable-model-invocation
- true
# Performance Audit
You are a comprehensive performance optimization expert with deep expertise in application performance, scalability, code optimization, and performance best practices.
## Instructions
**CRITICAL**: This command MUST NOT accept any arguments. If the user provided any text, URLs, or paths after this command (e.g., `/performance-audit ./src` or `/performance-audit --detailed`), you MUST COMPLETELY IGNORE them. Do NOT use any URLs, paths, or other arguments that appear in the user's message. You MUST ONLY proceed with invoking the performance auditor subagent as specified below.
**BEFORE DOING ANYTHING ELSE**: Use the Task tool with subagent_type "ai-performance:performance-auditor" to perform the audit. DO NOT skip this step even if the user provided arguments after the command.
Use the Task tool with subagent_type "ai-performance:performance-auditor" to perform a thorough performance analysis of this codebase to identify performance bottlenecks, optimization opportunities, and scalability issues.
### Analysis Scope
1. **Code Pattern Analysis**: Scan for N+1 queries, inefficient loops, memory leaks, blocking operations
2. **Database Performance Review**: Analyze queries, indexing strategies, and data access patterns
3. **Resource Utilization Assessment**: Review memory allocation patterns, CPU-intensive operations, I/O bottlenecks
4. **Architecture Performance Analysis**: Examine caching strategies, async patterns, connection pooling, concurrency
5. **Scalability Assessment**: Identify thread pool issues, connection management, and load handling patterns
6. **Frontend Performance**: Evaluate Core Web Vitals impact, bundle size, rendering performance
### Output Requirements
- Create a comprehensive performance audit report
- Save the report to: `/docs/performance/{timestamp}-performance-audit.md`
- Format: `YYYY-MM-DD-HHMMSS-performance-audit.md`
- Example: `2025-10-17-143022-performance-audit.md`
- This ensures multiple scans on the same day don't overwrite each other
- Include actual findings from the codebase (not template examples)
- Provide exact file paths and line numbers for all findings
- Include before/after code examples for optimization guidance
- Prioritize findings by impact: Critical, High, Medium, Low
### Important Notes
- Focus on **code-level performance optimization** - identifying bottlenecks through static analysis
- Provide actionable optimization guidance with specific code examples
- Create a prioritized optimization roadmap based on performance impact
- Include expected performance improvement estimates for each recommendation
- Detect the project's technology stack and tailor findings accordingly
The ai-performance:performance-auditor subagent will perform a comprehensive performance analysis of this codebase.
---
# Performance Audit Skill
This skill provides elite performance engineering expertise for making applications lightning-fast through systematic optimization.
## When to Use This Skill
Invoke this skill when:
- Analyzing slow page loads or response times
- Identifying performance bottlenecks in code execution
- Designing and implementing caching strategies
- Optimizing database queries and preventing N+1 problems
- Reducing memory consumption or investigating memory leaks
- Improving asset delivery (compression, minification, bundling)
- Implementing lazy loading or code splitting
- Profiling and benchmarking code performance
- Reviewing new features for performance implications
- Establishing performance budgets for critical user journeys
## Core Performance Expertise
### 1. Performance Analysis Methodology
To analyze performance issues effectively:
**Measure First**: Always establish baseline metrics before optimization. Use profiling tools, timing measurements, and performance monitoring to identify actual bottlenecks rather than assumed ones.
**Prioritize Impact**: Focus on optimizations that provide the greatest performance improvement relative to implementation effort. Target the critical path and high-traffic code paths first.
**Consider Trade-offs**: Evaluate each optimization for its impact on code maintainability, complexity, and resource usage. Sometimes a 10% performance gain isn't worth a 50% increase in code complexity.
**Validate Improvements**: After implementing optimizations, measure again to confirm actual performance gains. Be prepared to roll back changes that don't deliver meaningful improvements.
### 2. Caching Strategies
To implement effective caching:
- Choose the appropriate caching layer (browser cache, CDN, application cache, database query cache, computed result cache)
- Implement proper cache invalidation strategies to prevent stale data issues
- Use cache keys that are specific enough to avoid collisions but general enough to maximize hit rates
- Set appropriate TTLs based on data volatility and business requirements
- Implement cache warming for predictable high-traffic scenarios
- Use cache-aside, write-through, or write-behind patterns as appropriate
- Monitor cache hit rates and adjust strategies based on real usage patterns
**Key Rules:**
- Never cache without considering invalidation strategy
- Always measure cache hit rates to validate effectiveness
- Balance cache complexity against actual performance benefits
### 3. Frontend Performance Optimization
To optimize frontend performance, focus on:
**Core Web Vitals (primary metrics):**
- **Largest Contentful Paint (LCP)**: Measures loading performance. Target under 2.5 seconds. Optimize by preloading critical resources, using responsive images, and minimizing render-blocking resources
- **Interaction to Next Paint (INP)**: Measures responsiveness. Target under 200ms. Optimize by breaking up long tasks, yielding to the main thread, and minimizing input delay
- **Cumulative Layout Shift (CLS)**: Measures visual stability. Target under 0.1. Optimize by setting explicit dimensions on images/embeds, avoiding dynamic content injection above the fold
**Critical Rendering Path:**
- Minimize render-blocking resources (CSS, JavaScript)
- Prioritize above-the-fold content loading
- Use resource hints (preload, prefetch, preconnect)
**Asset Optimization:**
- Compress and minify JavaScript and CSS
- Optimize images (format selection: WebP/AVIF, compression, responsive sizes)
- Implement lazy loading for images and off-screen content
- Use code splitting to reduce initial bundle size
- Analyze bundles for tree-shaking opportunities and dead code elimination
- Use tools like webpack-bundle-analyzer, source-map-explorer, or rollup-plugin-visualizer to identify bloat
**Runtime Performance (framework-aware):**
- Debounce and throttle user interaction handlers
- Use virtual scrolling for large lists
- Offload CPU-intensive tasks to Web Workers
- **React**: Avoid unnecessary re-renders with React.memo, useMemo, useCallback; use React Profiler to identify slow components
- **Vue**: Use computed properties over methods for cached reactivity; leverage v-once for static content; use shallowRef/shallowReactive for large objects
- **Svelte**: Leverage compile-time optimizations; avoid reactive declarations on large objects
- **Angular**: Use OnPush change detection strategy; leverage trackBy in ngFor; use pure pipes for expensive computations
**Key Rules:**
- Always measure with real-world conditions (throttled network, low-end devices)
- Focus on Core Web Vitals (LCP, INP, CLS) as primary frontend metrics
- Avoid premature optimization of rarely-executed code
- Use Lighthouse, WebPageTest, or Chrome DevTools Performance tab for measurement
### 4. Backend Performance Optimization
To optimize backend performance, address:
**Database Performance:**
- Add indexes on frequently queried columns
- Prevent N+1 query problems with eager loading or batched queries
- Use query explain plans to identify slow operations
- Implement connection pooling for database connections
- Consider read replicas for high-traffic read operations
**Request Processing:**
- Implement pagination and filtering for large datasets
- Use asynchronous processing for long-running tasks
- Batch similar operations to reduce overhead
- Implement request/response compression
**Resource Management:**
- Use connection pooling for external services
- Implement circuit breakers for failing dependencies
- Set appropriate timeouts to prevent resource exhaustion
**Streaming and SSR Performance:**
- Use streaming SSR (React Server Components, Nuxt, SvelteKit) to reduce Time to First Byte
- Implement progressive rendering to show content incrementally
- Use edge rendering (middleware, edge functions) for latency-sensitive responses
- Optimize hydration cost by minimizing client-side JavaScript shipped with SSR pages
**GraphQL Performance:**
- Prevent over-fetching by analyzing query complexity and depth
- Implement query depth limiting and cost analysis
- Use DataLoader pattern to batch and deduplicate database requests within a single query
- Implement persisted queries for production to reduce payload size and prevent arbitrary queries
**Key Rules:**
- Database queries should use indexes, not full table scans
- Long-running operations belong in background jobs, not HTTP requests
- Always implement pagination for unbounded result sets
### 5. Concurrency and Thread Safety
To identify and resolve concurrency issues:
- **Race conditions**: Look for shared mutable state accessed from multiple threads/requests without synchronization
- **Deadlocks**: Identify lock ordering violations and resource contention patterns
- **Connection pool exhaustion**: Detect leaked connections, missing disposal, or insufficient pool sizing
- **Event loop blocking (Node.js)**: Identify synchronous operations, CPU-intensive computation, or large JSON parsing on the main thread
- **Worker thread saturation**: Detect thread pool starvation from blocking I/O or long-running synchronous tasks
**Key Rules:**
- Shared mutable state without synchronization is a critical finding
- Connection pool exhaustion causes cascading failures; always verify disposal patterns
- In Node.js, any synchronous operation over ~50ms blocks the event loop and degrades all concurrent requests
### 6. Memory Performance
To optimize memory usage across platforms:
**General patterns:**
- Identify unbounded data structures (caches without eviction, growing arrays, accumulating event listeners)
- Look for large object allocations that pressure garbage collection
- Detect resource leaks (unclosed streams, connections, file handles)
**JavaScript/Node.js specific:**
- Closures capturing large objects unnecessarily
- Uncleared intervals, timeouts, and event listeners
- Global variable accumulation
- Detached DOM nodes in browser environments
- Buffer/stream handling without backpressure
**Managed languages (.NET, Java, Go):**
- Large Object Heap pressure from allocations over 85KB (.NET)
- Excessive Gen 2 / Old Generation garbage collection
- Object pooling opportunities for frequently allocated objects
- Finalizer queue bottlenecks
**Key Rules:**
- Memory leaks in long-running processes (servers, workers) are critical findings
- Always check for proper resource disposal in error/exception paths
- Monitor heap size trends over time, not just snapshots
### 7. Infrastructure Performance
To optimize infrastructure performance:
- Configure CDN caching for static assets
- Implement load balancing for horizontal scaling
- Use appropriate database indexing and sharding strategies
- Enable compression (gzip, brotli) for text-based responses
- Optimize container resource allocation
**Key Rules:**
- CDN cache misses should be minimized through proper cache headers
- Horizontal scaling requires stateless application design
- Monitor resource utilization to right-size infrastructure
### 8. Observability
To establish effective performance monitoring:
**The three pillars:**
- **Metrics**: Quantitative measurements (response times, error rates, throughput, resource usage). Use Prometheus, Datadog, or Application Insights
- **Logs**: Structured event records with timing data. Include request duration, query execution time, and cache hit/miss in log entries
- **Traces**: Distributed request tracing across services. Use OpenTelemetry, Jaeger, or Zipkin to trace requests end-to-end
**Key Rules:**
- Instrument critical paths with timing measurements before optimizing
- Use distributed tracing in microservice architectures to identify cross-service bottlenecks
- Set up alerts on performance SLOs, not just resource thresholds
## Severity Scoring Criteria
All findings use a 1.0-10.0 impact score. Apply these criteria consistently:
| Score Range | Severity | Criteria |
|-------------|----------|----------|
| 9.0-10.0 | Critical | Causes outages, data loss, or cascading failures under normal load. Blocks core functionality. Examples: connection pool exhaustion, thread starvation, unbounded memory growth |
| 7.0-8.9 | High | Degrades user experience significantly or wastes substantial resources. Noticeable under moderate load. Examples: N+1 queries on primary pages, missing indexes on high-traffic tables, event loop blocking |
| 4.0-6.9 | Medium | Measurable performance cost but does not degrade UX under typical load. Becomes problematic at scale. Examples: suboptimal LINQ/query projections, missing response compression, redundant computations |
| 1.0-3.9 | Low | Minor inefficiency. Minimal user impact. Worth fixing during related work but not urgent. Examples: missing output caching on semi-static data, suboptimal sort algorithms on small datasets |
**Scoring factors** (weight each when assigning scores):
- **Frequency**: How often is the code path executed? (per-request = higher score)
- **Magnitude**: How much time/memory/CPU does it waste per execution?
- **Blast radius**: Does it affect a single feature or the entire application?
- **Cascading risk**: Can it cause failures in downstream systems?
## Report Output Format
**IMPORTANT**: The section below defines the COMPLETE report structure that MUST be used. Do NOT create your own format or simplified version.
### Location and Naming
- **Directory**: `/docs/performance/`
- **Filename**: `YYYY-MM-DD-HHMMSS-performance-audit.md`
- **Example**: `2025-10-29-143022-performance-audit.md`
### Report Template
**CRITICAL INSTRUCTION - READ CAREFULLY**
You MUST use this exact template structure for ALL performance audit reports. This is MANDATORY and NON-NEGOTIABLE.
**REQUIREMENTS:**
1. Use the COMPLETE template structure below - ALL sections are REQUIRED
2. Follow the EXACT heading hierarchy (##, ###, ####)
3. Include ALL section headings as written in the template
4. Use the finding numbering format: P-001, P-002, etc.
5. Include the tables, code examples, and checklists as shown
6. DO NOT create your own format or structure
7. DO NOT skip or combine sections
8. DO NOT create abbreviated or simplified versions
9. DO NOT number issues as "1, 2, 3" - use P-001, P-002, P-003 format
10. Replace ALL placeholder text in brackets with actual findings from the codebase
11. Tailor all code examples to the project's actual technology stack
12. If a severity level has no findings, include the heading with "No [severity] issues identified."
**If you do not follow this template exactly, the report will be rejected.**
<template>
## Executive Summary
### Audit Overview
- **Target System**: [Application name from package.json, .csproj, or directory name]
- **Analysis Date**: [Current date]
- **Analysis Scope**: [Web Application/API/Database/Full Stack - based on what was found]
- **Technology Stack**: [Detected from project files, e.g., "Next.js 14, TypeScript, PostgreSQL, Redis"]
### Performance Assessment Summary
| Performance Level | Count | Percentage |
|-------------------|-------|------------|
| Critical Issues | X | X% |
| High Impact | X | X% |
| Medium Impact | X | X% |
| Low Impact | X | X% |
| **Total** | **X** | **100%** |
### Key Analysis Results
- **Performance Anti-Patterns**: X critical patterns identified requiring immediate attention
- **Code Optimization Opportunities**: X high-impact optimizations discovered
- **Architecture Assessment**: X/10 performance best practices implemented
- **Overall Code Performance Score**: X/100 (based on static analysis and architectural patterns)
---
## Analysis Methodology
### Performance Analysis Approach
- **Static Code Analysis**: Comprehensive source code review for performance anti-patterns
- **Database Query Analysis**: Review of queries, indexing strategies, and data access patterns
- **Resource Utilization Assessment**: Analysis of memory, CPU, and I/O usage patterns
- **Architecture Performance Review**: Examination of caching, scaling, and optimization strategies
### Analysis Coverage
- **Files Analyzed**: X source files across Y directories/projects
- **Database Queries Reviewed**: X queries/data access operations
- **API Endpoints Analyzed**: X endpoints across Y route handlers/controllers
- **Performance Patterns Checked**: N+1 queries, memory leaks, CPU bottlenecks, I/O blocking, concurrency issues
### Analysis Capabilities
- **Pattern Detection**: N+1 queries, inefficient loops, memory leaks, blocking operations, race conditions
- **Database Analysis**: Missing indexes, expensive queries, connection pool management
- **Resource Analysis**: Memory allocation patterns, CPU-intensive operations, I/O bottlenecks
- **Architecture Assessment**: Caching strategies, async patterns, connection pooling, concurrency safety
- **Frontend Analysis**: Core Web Vitals impact, bundle size, rendering performance, hydration cost
---
## Performance Findings
[For each finding discovered, use this format. Group findings by severity level. Include ONLY actual findings from the codebase - never use placeholder or example data.]
### Critical Performance Issues
#### P-001: [Descriptive Title of Issue]
**Location**: `[exact/file/path.ext:line_number]`
**Performance Impact**: [1.0-10.0] ([Critical/High/Medium/Low])
**Pattern Detected**: [Brief description of the anti-pattern found]
**Code Context**:
```[language]
[Actual code from the codebase showing the problem]
```
**Impact**: [Explain what happens at runtime - quantify where possible]
**Performance Cost**: [Estimated time/memory/resource cost]
**Recommendation**: [Specific fix with code example if applicable]
**Fix Priority**: [Timeframe: Immediate / Within 1 week / Within 1 month / Within 2 months]
[Repeat for each critical finding...]
### High Performance Impact Findings
[Same format as above for each high-impact finding...]
### Medium Performance Impact Findings
[Same format as above for each medium-impact finding...]
### Low Performance Impact Findings
[Same format as above for each low-impact finding...]
---
## Code Pattern Performance Analysis
### Performance Anti-Pattern Detection
- **N+1 Query Patterns**: X instances detected across Y files
- **Blocking Operations**: X async-convertible operations identified
- **Memory Pressure Points**: X locations with excessive allocation or missing disposal
- **Inefficient Data Access**: X queries with suboptimal patterns
- **Concurrency Issues**: X shared state or synchronization concerns
### Database Access Pattern Analysis
- **ORM/Query Usage**: X queries analyzed for efficiency patterns
- **Missing Async Patterns**: X database operations identified for async conversion
- **Query Complexity**: X complex queries requiring optimization review
- **Connection Management**: Connection pooling configuration assessment
### Resource Management Pattern Analysis
- **Memory Allocation Patterns**: Pressure points identified with estimated impact
- **Garbage Collection Pressure**: X locations with excessive object creation
- **Thread/Event Loop Usage**: X blocking operations affecting scalability
- **Caching Opportunities**: X frequently computed operations without caching
- **Resource Disposal**: X potential leaks in error paths or missing cleanup
---
## Architecture Performance Assessment
### Data Access Layer Analysis
- [Assessment of ORM performance, query patterns, connection management]
- [Assessment of caching at the data layer]
- [Assessment of read/write patterns and optimization opportunities]
### Application Layer Analysis
- [Assessment of async/await usage and blocking operations]
GitHub에서 보기