From godmode
Use when performance is a concern - sluggish pages, slow queries, bloated bundles, high-latency APIs, or whenever someone says "optimize" or "make it faster"
npx claudepluginhub noobygains/godmode --plugin godmodeThis skill uses the workspace's default tool permissions.
Blind optimization is the root of wasted effort. Measure, pinpoint the bottleneck, fix that specific thing.
Identifies and fixes performance bottlenecks in code, databases, and APIs. Measures before/after execution times, profiles with DevTools/Node, optimizes queries/indexes/caching. Use for slow apps, APIs, or DB queries.
Optimizes application performance via measure-identify-fix-verify workflow. Use for Core Web Vitals, load times, regressions, or profiling bottlenecks.
Guides performance optimization workflow: profile baselines, identify bottlenecks, apply fixes for frontend (bundle size, rendering, images), backend (queries, caching), and database layers.
Share bugs, ideas, or general feedback.
Blind optimization is the root of wasted effort. Measure, pinpoint the bottleneck, fix that specific thing.
Core principle: No optimization without measurement. No measurement without a demonstrated performance problem.
No exceptions. No workarounds. No shortcuts.
NO OPTIMIZATION WITHOUT A MEASUREMENT PROVING THE PROBLEM
If you have not profiled it, you are not qualified to optimize it. Intuitions about performance are reliably wrong.
digraph perf_gate {
problem [label="Is there a\nmeasurable\nperformance deficit?", shape=diamond];
measure [label="MEASURE\nProfile and locate\nthe bottleneck", shape=box, style=filled, fillcolor="#ccffcc"];
halt [label="HALT\nDo not optimize", shape=box, style=filled, fillcolor="#ffcccc"];
found [label="Bottleneck\npinpointed?", shape=diamond];
fix [label="FIX\nthat specific thing", shape=box, style=filled, fillcolor="#ccccff"];
dig [label="Investigate further\nor accept current\nperformance", shape=box];
problem -> measure [label="yes"];
problem -> halt [label="no"];
measure -> found;
found -> fix [label="yes"];
found -> dig [label="no"];
fix -> measure [label="re-measure"];
}
Engage when:
Do not engage when:
BEFORE any optimization effort:
1. MEASURE: What is the current performance? (Numbers, not hunches)
2. TARGET: What performance level is required? (Specific threshold)
3. PINPOINT: Where is the bottleneck? (Profiler data, not speculation)
4. FIX: Address that specific bottleneck
5. VERIFY: Did the measurement improve? By how much?
Omit any step = premature optimization
You must have numbers before changing anything.
| Dimension | How to Measure |
|---|---|
| Page load latency | Lighthouse, WebPageTest, browser DevTools Performance panel |
| API response time | Server logs, APM instrumentation, time curl |
| Query execution time | EXPLAIN ANALYZE, slow query log, ORM query logging |
| Bundle weight | webpack-bundle-analyzer, source-map-explorer |
| Memory consumption | Heap snapshots, process.memoryUsage() |
| CPU utilization | Flame charts via profiler, perf, py-spy |
Record the baseline. You need it to prove the optimization was effective.
The bottleneck is almost never where you expect it.
Profile -> identify the function/query/resource consuming the most time
|
That is your optimization target
|
Everything else is a distraction
Check these locations in order (most common first):
Fix only what the profiler revealed. Change one variable at a time.
| Symptom | Remedy |
|---|---|
| N+1 queries | Eager loading / JOIN / batched query |
| Missing index | Add index on columns in WHERE/JOIN/ORDER BY clauses |
| Full table scan | Add appropriate index; constrain result set |
| Oversized result sets | Cursor-based pagination for large datasets |
| Expensive aggregations | Materialized views or pre-computed summaries |
| Lock contention | Tighten transaction scope; introduce read replicas |
-- BEFORE: Diagnose the problem
EXPLAIN ANALYZE SELECT * FROM transactions WHERE account_id = 789;
-- Look for: Seq Scan (missing index), high cost, slow execution
-- AFTER: Add index, re-run EXPLAIN ANALYZE, compare numbers
| Metric | Threshold | Typical Remedies |
|---|---|---|
| LCP (Largest Contentful Paint) | < 2.5s | Optimize hero images, preload critical resources, enable SSR |
| INP (Interaction to Next Paint) | < 200ms | Break long tasks, defer non-critical JS, offload to web workers |
| CLS (Cumulative Layout Shift) | < 0.1 | Set explicit dimensions on media, avoid dynamic content insertion above fold |
Bundle weight reduction:
1. Audit: what occupies space in the bundle?
2. Remove unused dependencies
3. Code-split by route (lazy loading)
4. Ensure ESM imports for tree-shaking
5. Enable compression (gzip/brotli)
| Symptom | Remedy |
|---|---|
| Over-fetching | Return only requested fields; support sparse fieldsets |
| Under-fetching | Batch endpoints; return compound documents |
| No caching | Add Cache-Control headers and ETags |
| Synchronous heavy processing | Return 202 Accepted with async processing + polling |
| Oversized responses | Paginate, compress, or stream |
| Slow serialization | Profile the serializer; reduce nesting depth |
Only when the profiler points to computation as the bottleneck:
| From | To | When Applicable |
|---|---|---|
| O(n^2) nested loops | Hash map lookup O(n) | Large input sets |
| Repeated computation | Memoization or caching | Same inputs, expensive function |
| Synchronous blocking | Async / parallel execution | I/O-bound work |
| Full recomputation | Incremental update | Small mutations to large datasets |
Re-run the identical measurement. Compare the numbers.
Baseline: API response 920ms
After optimization: API response 145ms
Improvement: 84% reduction
Required threshold: < 500ms -- ACHIEVED
If the improvement is not measurable, revert the change. An optimization that cannot be measured is not an optimization.
| Anti-Pattern | Why It Fails | Better Approach |
|---|---|---|
| Premature caching | Adds complexity and stale-data risks | Optimize the query first |
| Premature indexing | Indexes degrade write throughput and consume storage | Add only when a query is demonstrably slow |
| Micro-optimizing tight loops | Saves nanoseconds, destroys readability | Profile first; only touch what the profiler flags |
| "Async all the things" | Adds cognitive complexity, harder debugging | Apply async only to I/O-bound operations |
| Optimizing in dev environment | Dev performance diverges from production | Profile in a production-like environment |
| Caching without invalidation | Stale data, consistency bugs | Design invalidation strategy before adding cache |
| Rationalization | Truth |
|---|---|
| "This will be slow at scale" | Is it slow NOW? Optimize when evidence arrives. |
| "Best practice says to add an index" | Is the query actually slow? Indexes impose write overhead. |
| "Caching will speed everything up" | Have you measured what is actually slow? Caching adds complexity. |
| "Async will make this faster" | Is this I/O-bound? Async adds mental overhead for no gain on CPU-bound work. |
| "I know where the bottleneck is" | Profilers exist because human intuition about performance is unreliable. Measure. |
| "Quick optimization while I am in here" | Unplanned optimizations are premature by definition. |
Every item on this list means: HALT. Measure first. Optimize only the measured bottleneck.
Complementary skills:
Measure -> Pinpoint bottleneck -> Fix that one thing -> Confirm improvement
Everything else is speculation. Speculation about performance is always wrong.