performance-optimization

Performance Optimization

Do not optimize by instinct. Start with measurement, change one thing at a time, and confirm the result with the same metric you used at the beginning.

When to Use

• A user or monitoring system reports a slow page, endpoint, query, or job
• A new feature needs a performance baseline before release
• You suspect a regression and need evidence before changing code
• A hot path is doing real work at scale and latency or throughput matters

When NOT to Use

Instead of performance-optimization	Use
Obvious correctness bug	systematic-debugging
General frontend inspection without a clear perf question	browser-devtools
Micro-tuning without user impact	leave it alone
"Feels slow" with no measurement plan	define a measurable target first

Workflow

1. Define the metric that matters

Pick the metric before touching code:

• Web UI: LCP, INP, CLS, bundle size, render time
• API: p50 / p95 / p99 latency, throughput, error rate
• Database: query duration, rows scanned, lock wait time
• Background jobs: wall-clock duration, queue time, memory growth

Write the target in one line:

Goal: reduce p95 /search latency from 850ms to under 400ms.

2. Capture a baseline

Measure the current state using the closest native tool:

# Node.js CPU profiling
node --prof server.js

# Frontend runtime inspection
# Use browser devtools / Lighthouse and record the before numbers

# Database query analysis
# EXPLAIN ANALYZE <query>

Keep the baseline numbers in the task notes, PR, or issue.

3. Find the dominant bottleneck

Look for the one thing consuming most of the time:

• Repeated expensive work
• N+1 queries or redundant network calls
• Heavy rendering or oversized bundles
• Serialization / parsing cost
• Synchronous work on the critical path

Use the 80/20 rule: fix the dominant bottleneck before touching minor inefficiencies.