Slow APIs are a drag on user experience, conversion rates, and engineering credibility. The good news is that most API latency problems are fixable — often with targeted changes rather than complete rewrites. Here are eight techniques that consistently make a measurable difference.
1. Measure Before You Optimise
The biggest mistake teams make is guessing which code is slow. Before making any changes, measure per-route latency in production. Route-level monitoring tells you which endpoints are actually slow — often the culprit is not where you expect it to be. Without a measurement baseline, you cannot know whether your optimisations are working.
2. Optimise Your Database Queries
The most common source of API latency is the database. Slow queries, missing indexes, N+1 query patterns, and fetching more data than needed all accumulate. Enable query logging, identify your slowest queries by execution time, and add indexes strategically to the columns used in your WHERE clauses and JOIN conditions.
3. Cache Aggressively
Cache results that do not change on every request. HTTP caching headers (Cache-Control, ETag) eliminate unnecessary round trips for static or slowly-changing resources. Redis or Memcached can cache computed results for expensive lookups. In-memory caches work for data that changes rarely and fits in memory. Be deliberate about what you cache and how you invalidate it.
4. Use Connection Pooling
Opening a new database connection for every API request is expensive — connection establishment can add 20-50ms. Connection pooling reuses existing connections, eliminating that handshake overhead on every request. Most database clients have pooling built in. Make sure it is enabled and sized correctly for your concurrency requirements.
5. Compress Responses
Enabling gzip or brotli compression on your API responses reduces payload size and network transmission time. For text-heavy responses — JSON, HTML, XML — compression ratios of 5:1 to 10:1 are common. The CPU cost of compression is small compared to the latency saved, especially for clients on slower mobile connections.
6. Move Work Off the Request Path
Not everything needs to happen synchronously before you return a response. Email delivery, webhook calls, analytics events, image processing, and search index updates can all be moved to background queues. The user gets a faster response; the work still happens. Job queues like BullMQ or pg-boss make this pattern straightforward in Node.js.
7. Use a CDN for Cacheable Endpoints
For API responses that are the same for all users or groups of users, a CDN can serve them from an edge node close to the requester rather than from your origin server. This reduces both latency and load on your backend. Public content, pricing data, and configuration responses are good candidates.
8. Monitor After Every Change
Every optimisation should be validated with data. Deploy the change, watch your P95 and P99 latency charts for the affected routes, and confirm the improvement is real and sustained. Without post-change monitoring, you cannot know whether your changes helped, had no effect, or introduced a regression elsewhere.
Statvisor gives you per-route latency percentiles in real time, so you can see exactly which endpoints need attention and verify that your optimisations are landing after each deployment. Start with a measurement baseline — then optimise from there.
Ready to monitor your API in production?
Statvisor gives you latency percentiles, error rates, and request volume for every route — in minutes, not days.
Get started free →