m-performance-optimization

name	m-performance-optimization
description	Optimizes application performance. Use when performance requirements exist, when you suspect performance regressions, or when Core Web Vitals or load times need improvement. Use when profiling reveals bottlenecks that need fixing. Triggers: slow, performance, latency, Core Web Vitals, LCP, bundle size, N+1 query, profiling, load time.

Performance Optimization

Overview

Measure before optimizing. Performance work without measurement is guessing — and guessing leads to premature optimization that adds complexity without improving what matters. Profile first, identify the actual bottleneck, fix it, measure again. Optimize only what measurements prove matters.

When to Use

• Performance requirements exist in the spec (load time budgets, response time SLAs)
• Users or monitoring report slow behavior
• Core Web Vitals scores are below thresholds
• You suspect a change introduced a regression
• Building features that handle large datasets or high traffic

When NOT to use: Don't optimize before you have evidence of a problem. Premature optimization adds complexity that costs more than the performance it gains.

Core Web Vitals Targets

Current thresholds as of authoring — verify at web.dev/vitals.

Metric	Good	Needs Improvement	Poor
LCP (Largest Contentful Paint)	≤ 2.5s	≤ 4.0s	> 4.0s
INP (Interaction to Next Paint)	≤ 200ms	≤ 500ms	> 500ms
CLS (Cumulative Layout Shift)	≤ 0.1	≤ 0.25	> 0.25

The Optimization Workflow

1. MEASURE  → Establish baseline with real data
2. IDENTIFY → Find the actual bottleneck (not assumed)
3. FIX      → Address the specific bottleneck
4. VERIFY   → Measure again, confirm improvement
5. GUARD    → Add monitoring or tests to prevent regression

Step 1: Measure

Two complementary approaches — use both:

• Synthetic (Lighthouse, DevTools Performance tab): Controlled conditions, reproducible. Best for CI regression detection and isolating specific issues.
• RUM (web-vitals library, CrUX): Real user data in real conditions. Required to validate that a fix actually improved user experience.

Frontend:

# Synthetic: Lighthouse in Chrome DevTools (or CI)
# Chrome DevTools → Performance tab → Record
# Chrome DevTools MCP → Performance trace

# RUM: Web Vitals library in code
import { onLCP, onINP, onCLS } from 'web-vitals';

onLCP(console.log);
onINP(console.log);
onCLS(console.log);

Backend:

# Response time logging
# Application Performance Monitoring (APM)
# Database query logging with timing

# Simple timing
console.time('db-query');
const result = await db.query(...);
console.timeEnd('db-query');

Where to Start Measuring

Use the symptom to decide what to measure first:

What is slow?
├── First page load
│   ├── Large bundle? --> Measure bundle size, check code splitting
│   ├── Slow server response? --> Measure TTFB in DevTools Network waterfall
│   │   ├── DNS long? --> Add dns-prefetch / preconnect for known origins
│   │   ├── TCP/TLS long? --> Enable HTTP/2, check edge deployment, keep-alive
│   │   └── Waiting (server) long? --> Profile backend, check queries and caching
│   └── Render-blocking resources? --> Check network waterfall for CSS/JS blocking
├── Interaction feels sluggish
│   ├── UI freezes on click? --> Profile main thread, look for long tasks (>50ms)
│   ├── Form input lag? --> Check re-renders, controlled component overhead
│   └── Animation jank? --> Check layout thrashing, forced reflows
├── Page after navigation
│   ├── Data loading? --> Measure API response times, check for waterfalls
│   └── Client rendering? --> Profile component render time, check for N+1 fetches
└── Backend / API
    ├── Single endpoint slow? --> Profile database queries, check indexes
    ├── All endpoints slow? --> Check connection pool, memory, CPU
    └── Intermittent slowness? --> Check for lock contention, GC pauses, external deps

Step 2: Identify the Bottleneck

Common bottlenecks by category:

Frontend:

Symptom	Likely Cause	Investigation
Slow LCP	Large images, render-blocking resources, slow server	Check network waterfall, image sizes
High CLS	Images without dimensions, late-loading content, font shifts	Check layout shift attribution
Poor INP	Heavy JavaScript on main thread, large DOM updates	Check long tasks in Performance trace
Slow initial load	Large bundle, many network requests	Check bundle size, code splitting

Backend:

Symptom	Likely Cause	Investigation
Slow API responses	N+1 queries, missing indexes, unoptimized queries	Check database query log
Memory growth	Leaked references, unbounded caches, large payloads	Heap snapshot analysis
CPU spikes	Synchronous heavy computation, regex backtracking	CPU profiling
High latency	Missing caching, redundant computation, network hops	Trace requests through the stack

Step 3: Fix

When fixing an identified bottleneck, read references/optimization-patterns.md for the anti-pattern catalog and fixes (N+1 queries, unbounded data fetching, image optimization, unnecessary re-renders, bundle size, caching).

Performance Budget

Set budgets and enforce them. The numbers below are an example template — adapt them to your project's requirements:

JavaScript bundle: < 200KB gzipped (initial load)
CSS: < 50KB gzipped
Images: < 200KB per image (above the fold)
Fonts: < 100KB total
API response time: < 200ms (p95)
Time to Interactive: < 3.5s on 4G
Lighthouse Performance score: ≥ 90

Enforce in CI:

# Bundle size check
npx bundlesize --config bundlesize.config.json

# Lighthouse CI
npx lhci autorun

See Also

For detailed performance checklists, optimization commands, and anti-pattern reference, see references/performance-checklist.md.

Common Rationalizations

Rationalization	Reality
"We'll optimize later"	Performance debt compounds. Fix obvious anti-patterns now, defer micro-optimizations.
"It's fast on my machine"	Your machine isn't the user's. Profile on representative hardware and networks.
"This optimization is obvious"	If you didn't measure, you don't know. Profile first.
"Users won't notice 100ms"	Research shows 100ms delays impact conversion rates. Users notice more than you think.
"The framework handles performance"	Frameworks prevent some issues but can't fix N+1 queries or oversized bundles.

Red Flags

• Optimization without profiling data to justify it
• N+1 query patterns in data fetching
• List endpoints without pagination
• Images without dimensions, lazy loading, or responsive sizes
• Bundle size growing without review
• No performance monitoring in production
• React.memo and useMemo everywhere (overusing is as bad as underusing)

Verification

After any performance-related change:

• Before and after measurements exist (specific numbers)
• The specific bottleneck is identified and addressed
• Core Web Vitals are within "Good" thresholds
• Bundle size hasn't increased significantly
• No N+1 queries in new data fetching code
• Performance budget passes in CI (if configured)
• Existing tests still pass (optimization didn't break behavior)