pwp-perf
Scannednpx machina-cli add skill shandar/pwp-plugin/pwp-perf --openclawPerformance Optimization Skill
The cardinal rule: never optimize on vibes. Measure, identify the bottleneck, fix it, prove it's faster.
Performance Mindset
- Measure before optimizing. Intuition about performance is wrong more often than right. Profile first.
- Optimize the bottleneck. Making a fast operation faster doesn't help.
- Premature optimization is real. Only optimize measured problems or known-critical paths.
- Verify the improvement. Before/after numbers or it didn't happen.
Investigation Protocol
Step 1: Define the Problem
- What is slow? (Page load, API, render, build)
- How slow? (Actual numbers: "3.2 seconds")
- What is the target? ("Under 1 second")
Step 2: Measure Current State
| Area | How to Measure |
|---|---|
| Page load | Lighthouse, DevTools Performance tab |
| Core Web Vitals | LCP, INP, CLS via Lighthouse |
| API response | Network tab timing, server-side logging |
| Render | React DevTools Profiler |
| Bundle size | Build output, bundlephobia |
| Memory | DevTools Memory tab, heap snapshots |
| Database | Query EXPLAIN plans |
Step 3: Identify the Bottleneck
- Network — too many requests, large payloads, no caching
- Data — slow queries, over-fetching, N+1 patterns
- Rendering — unnecessary re-renders, layout thrashing
- Compute — expensive calculations on main thread
- Assets — uncompressed images, unminified JS
Step 4: Fix the Bottleneck
| Bottleneck | Common Fixes |
|---|---|
| Large bundle | Code splitting, dynamic imports, tree shaking |
| Slow page load | Lazy loading, preload critical resources |
| Re-renders | useMemo, useCallback, React.memo (only where profiled) |
| Slow API | Caching, pagination, field selection |
| N+1 queries | Batch queries, eager loading, DataLoader |
| Large images | WebP/AVIF, responsive srcset, lazy loading |
| Heavy computation | Web Workers, caching results |
Step 5: Verify
**Before:** {metric} = {value}
**After:** {metric} = {value}
**Improvement:** {percentage}%
**Target met:** Yes / No
**Method:** {tool, conditions}
Web Performance Targets
| Metric | Good | Needs Work | Poor |
|---|---|---|---|
| LCP | < 2.5s | 2.5-4.0s | > 4.0s |
| INP | < 200ms | 200-500ms | > 500ms |
| CLS | < 0.1 | 0.1-0.25 | > 0.25 |
| TTFB | < 800ms | 800-1800ms | > 1800ms |
| Bundle (gzip) | < 100KB | 100-300KB | > 300KB |
Anti-Patterns
| Anti-Pattern | Do This Instead |
|---|---|
| Memoizing everything | Profile first, memoize measured bottlenecks |
| Optimizing render count | Profile actual paint/layout cost |
| Cache without TTL | Always set expiration |
| Lazy loading everything | Only lazy load below-fold content |
| Compressing at runtime | Compress at build time |
Source
git clone https://github.com/shandar/pwp-plugin/blob/main/skills/pwp-perf/SKILL.mdView on GitHub Overview
This skill follows a disciplined, measure-then-optimize workflow to improve performance. It emphasizes profiling, bottleneck identification, and before/after verification to ensure changes deliver real gains. It covers web vitals, rendering, memory, and database performance as part of a structured protocol.
How This Skill Works
Follow the investigation protocol: define the problem, measure current state with tools like Lighthouse, DevTools, and profilers, then identify bottlenecks in areas such as Network, Data, Rendering, Compute, and Assets. Apply targeted fixes (code splitting, lazy loading, caching, batching, image optimization) and then verify improvements using concrete before/after metrics.
When to Use It
- When a user reports something is slow or the app feels laggy.
- When you’re asked about performance or optimization opportunities.
- When you’re concerned about load times, bundle size, rendering speed, memory usage, or database query performance.
- When Core Web Vitals indicate room for improvement (LCP, INP, CLS, TTFB) and you need to diagnose.
- When you want to validate that changes actually improved performance after a deployment.
Quick Start
- Step 1: Define the problem and the target metric.
- Step 2: Measure current state with Lighthouse, DevTools, and profilers to identify bottlenecks.
- Step 3: Implement fixes for the bottleneck and verify with before/after metrics to confirm improvement.
Best Practices
- Measure before optimizing; profile first to identify the true bottleneck.
- Target bottlenecks, not every component; optimize the critical path.
- Iterate on measured problems or known-critical paths only, avoid premature optimization.
- Verify improvements with before/after metrics and clear target met.
- Document the results and keep changes incremental for traceability.
Example Use Cases
- Reduce a large bundle by code splitting, dynamic imports, and tree shaking.
- Improve page load by lazy loading non-critical resources and preloading critical assets.
- Decrease re-renders by applying useMemo/useCallback and React.memo after profiling.
- Speed up slow API calls with caching, pagination, and field selection.
- Address N+1 database queries by batching and eager loading (DataLoader) or proper indexing.