Performance Optimization

Most "slow" problems are diagnosed by guesswork. This skill replaces guessing with a measure-first workflow: profile, fix minimally, re-measure against a budget. Covers backend (database, caching, concurrency), frontend (bundles, images, rendering), network (CDN, compression, HTTP), and memory, with concrete tools and before/after examples.

Quick Reference

Core Workflow

1. Measure First

Never optimize before you can answer: "how do I know it got faster?"

1. Reproduce — get a repeatable trigger (endpoint, page, script, load profile).
2. Baseline — record current latency distribution, throughput, and resource usage.
3. Budget — set an explicit target (e.g., p95 < 200 ms, initial JS < 170 KB gzipped).
4. Profile — find where time actually goes (CPU, I/O wait, dependency latency, GC).
5. Hypothesize — one bottleneck, one predicted fix, one measurable effect.
6. Fix minimally — the smallest change that tests the hypothesis.
7. Re-measure — same tool, load, and environment; keep the fix only if it moves the metric.

2. The Triage Loop (symptom → cause)

Choosing the Right Metrics

Track percentiles, not just the mean — a mean hides whether 5% of users wait 10x longer.

Turn metrics into SLOs (e.g., "99% of GET /api/orders < 300 ms", "error rate < 0.1%") and load test with k6 or locust before production does:

import http from "k6/http";
export const options = {
  stages: [{ duration: "30s", target: 20 }, { duration: "1m", target: 100 }],
  thresholds: { http_req_duration: ["p(95)<250"] },
};
export default function () { http.get("http://localhost:8000/api/orders/42"); }

Backend Optimization

Database

-- Red flags: Seq Scan on large tables, rows far higher than returned, missing indexes
EXPLAIN ANALYZE
SELECT o.*, i.* FROM orders o JOIN order_items i ON i.order_id = o.id
WHERE o.customer_id = 123 ORDER BY o.created_at DESC LIMIT 20;

N+1 — one query for the parent, one per child — is the most common backend perf bug:

# BAD: 1 + N queries
for order in session.query(Order).filter_by(customer_id=123):
    for item in order.items:      # lazy load -> one query per order
        ...
# GOOD: 2 queries
from sqlalchemy.orm import selectinload
orders = session.query(Order).options(selectinload(Order.items)).filter_by(customer_id=123)

Caching

Cache-aside (read-through on miss, delete on write) is the default pattern:

def get_order(order_id: int):
    cached = redis.get(f"order:{order_id}")
    if cached is not None:
        return json.loads(cached)          # cache hit — no DB
    order = db.query(Order).get(order_id)  # miss — DB
    redis.setex(f"order:{order_id}", 60, json.dumps(order.to_dict()))  # TTL 60s
    return order

Rules that prevent cache bugs:

• Set a TTL on everything — short TTLs make correctness bugs self-heal.
• Invalidate on write — delete the key in the same flow that mutates the row.
• Cap cache size (LRU / maxmemory-policy allkeys-lru) — an unbounded cache is a leak.
• Guard against stampedes — single-flight lock so concurrent misses don't all hit the DB (example in backend-optimization.md).

Concurrency & I/O

• Pool your connections (DB, HTTP, Redis) — establishing connections is expensive; size pools to cores x expected concurrency (pgbouncer, explicit pool bounds).
• Batch external calls — fan out parallel requests instead of serial ones:

# BAD: 3 round trips, serial — latency adds up
a = api_a.get(x); b = api_b.get(x); c = api_c.get(x)
# GOOD: 3 round trips, parallel — latency of the slowest
import asyncio
a, b, c = await asyncio.gather(api_a.get(x), api_b.get(x), api_c.get(x))

• Async I/O beats threads for I/O-bound work; threads or multiprocessing beat async for CPU-bound work (see Concurrency Models below).

Frontend Optimization

Bundle size

• Code splitting — load route/feature chunks on demand with React.lazy + Suspense or dynamic import().
• Tree shaking — import named exports, avoid side-effectful imports; verify with webpack-bundle-analyzer / rollup-plugin-visualizer.
• Budget the initial JS (roughly 170 KB gzipped) and fail CI over it with size-limit.

const OrdersPage = React.lazy(() => import("./pages/OrdersPage"));
function App() {
  return (
    <Suspense fallback={<Spinner />}>
      <OrdersPage />
    </Suspense>
  );
}

Images & asset delivery

• Serve modern formats (AVIF > WebP > JPEG) via CDN resizing or build-time conversion.
• Use srcset/sizes so mobile users download small files; set width/height or aspect-ratio to prevent layout shift (CLS).
• loading="lazy" below the fold, fetchpriority="high" for the LCP image.
• Inline critical CSS; load JS with defer (or async where order doesn't matter).
• preconnect to CDNs/APIs hit early; preload the LCP image or font.
• Hashed assets: Cache-Control: public, max-age=31536000, immutable; no-cache on HTML.

React rendering

• React.memo to skip re-renders of expensive subtrees; useMemo/useCallback only where identity/cost actually matters — don't wrap everything.
• Virtualize long lists (react-window) instead of rendering 10k rows.
• Avoid layout thrash — batch DOM reads then writes; prefer CSS transforms over JS layout.
• Profile with React DevTools Profiler first — if renders are cheap, the problem is elsewhere.

Network Optimization

curl -sS -o /dev/null -w "DNS %{time_namelookup} | TCP %{time_connect} | TLS %{time_appconnect} | TTFB %{time_starttransfer} | Total %{time_total}\n" https://example.com/api/orders/42

Concurrency Models

Python note: the GIL means threads only help I/O-bound work — use multiprocessing for CPU-bound. Node's event loop is the mirror image: offload sync CPU-heavy work from request handlers to worker_threads or a job queue.

Memory

• Leaks — JS: retained listeners, detached DOM nodes, module-level caches, closures. Python: unclosed files/connections, global caches, cyclic refs with __del__. Prove with heap snapshots (tracemalloc, Chrome Memory panel) taken at two points and diffed.
• Unbounded caches — every cache needs a size cap (LRU) or a TTL: lru_cache(maxsize=...), maxmemory-policy allkeys-lru.
• Object churn — allocating in hot loops forces GC pressure. Reuse buffers; prefer typed arrays over per-iteration string concatenation.

Worked Example: Optimizing GET /api/orders/{id}

Baseline (k6, 50 concurrent users): p50 210 ms, p95 480 ms, error rate 0.4%. Step 1 — profile. Attach py-spy; the dump shows ~380 ms spent in the DB driver:

Thread 0x10a (idle 3ms):
  File "app/orders.py:42" _fetch_order
    File "sqlalchemy/orm/query.py:310" execute
      File "psycopg2/extensions.py:512" poll          <- waiting on DB (~370ms)

Step 2 — hypothesis. The latency is DB time, not Python. Confirm with EXPLAIN:

EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 123 ORDER BY created_at DESC;
-- Seq Scan on orders (cost=0.00..1420.00 rows=1 actual rows=3800)  <- full scan

Step 3 — fix the missing customer_id index and the N+1 (3,800 queries/request); cache hot orders for 60s:

CREATE INDEX idx_orders_customer ON orders (customer_id, created_at DESC);

order = db.query(Order).options(selectinload(Order.items)).get(order_id)
cached = redis.get(f"order:{order_id}")
if cached is not None:
    return json.loads(cached)
redis.setex(f"order:{order_id}", 60, json.dumps(order.to_dict()))

Step 4 — re-measure with the identical k6 script:

The index removed the scan (380 ms → ~15 ms), eager loading removed 3,800 round trips, and the cache removed the DB for repeated hits — each change measured in isolation.

Anti-Patterns to Avoid

• Optimizing before measuring — "fast" micro-optimizations that move nothing.
• Fixing symptoms, not bottlenecks — adding a cache without reading the plan; sometimes the index alone is the whole fix.
• Mean-only dashboards — a healthy mean hides a terrible p99 and the long tail.
• Unbounded caches — no TTL, no size cap: today's cache is tomorrow's OOM.
• Premature concurrency — threads/async add complexity; apply only after profiling shows I/O wait is the bottleneck.
• Blindly memoizing React — useMemo/React.memo add overhead; measure render cost first.

When to Use / Not Use

Use when:

• The user reports slow endpoints, slow page loads, high latency, or poor throughput.
• You need to profile, load test, or establish performance budgets/SLOs.
• The task involves DB query optimization, caching, bundle/image optimization, or tuning concurrency — and you can measure the effect.

Do NOT use when:

• The task is a pure correctness bug, feature, or refactor with no performance concern.
• The user only needs a one-off metric readout, not a systematic optimization pass.
• Performance already meets the budget — resist optimizing without a target.