Performance Improvement

Performance Improvement

The iron law: no optimization without a measurement, and no "it's faster now" without a second measurement. Guessed bottlenecks are wrong more than half the time; optimizing a guess makes code worse and no faster.

The loop (never skip a step)

1. Define the target. "Fast" is not a spec. Get a number: "list endpoint p95 5 queries deserves suspicion.

• Missing indexes: EXPLAIN ANALYZE the slow query. Seq scan on a big table in a hot path → index the filter/sort columns (composite, leading with equality columns; tenant id first in multi-tenant).
• Fetching too much: SELECT only needed columns for lists; paginate everything (keyset for deep pages); never load all rows to count them (COUNT(*)) or to filter in app code what SQL can filter.
• Chatty transactions: many round trips inside one request → batch into fewer statements; move multi-row inserts to bulk operations.

External calls

• Sequential awaits that could be parallel; missing timeouts (a "slow" system is often one hung dependency); calls in loops that need batching; synchronous calls that belong in a background job (see system-design).

App code

• Only after DB and I/O are clean: accidental O(n²) (lookup in a list inside a loop → use a set/dict), repeated parsing/serialization of the same data, loading whole files into memory to stream them out.

Frontend

• Measure with the browser's own tools (Lighthouse/Performance tab) on throttled mobile, not your dev machine.
• Usual suspects in order: oversized/unoptimized images, render-blocking or oversized JS bundles (analyze the bundle; lazy-load routes and heavy components), waterfalls of dependent fetches (parallelize or move to the server), missing caching headers on static assets, re-render storms (fix state placement before reaching for memo).
• Perceived speed counts: skeletons, optimistic updates, and streaming beat a spinner even at equal latency.

Caching is the last resort, not the first

A cache is a bug you haven't had yet (staleness, invalidation, memory). Before caching: fix the query, add the index, batch the calls. Cache when the computation is irreducibly expensive and read-heavy — then follow system-design's cache rules (source of truth, invalidation, max staleness, tenant-scoped keys).

Load & capacity sanity

• Before launch or a big campaign: one basic load test of the golden path at 2–3× expected peak (any tool — k6, locust, even a bash loop with concurrency). You're looking for the knee: where latency bends and errors start.
• Watch connection limits: DB max_connections vs app pool size × instances is the classic silent ceiling.
• Memory leaks announce themselves as restarts-fix-it: track RSS over hours under steady load if you suspect one.

Anti-patterns to refuse

• Micro-optimizing readable code (loop unrolling, clever bit tricks) in an app whose time is 95% I/O.
• Adding Redis/queues/read-replicas to fix what one index fixes.
• "It feels faster" as evidence. Numbers or it didn't happen.
• Benchmarking dev builds, cold caches, or localhost and drawing production conclusions.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: 05-deepak-patidar
• Source: 05-deepak-patidar/claude-skills
• License: MIT

Install and usage instructions live in the source repository linked above.