What is the most common cause of slow API response times?

Database query performance is the most common bottleneck, typically consuming 60-80% of total API response time. Missing indexes, N+1 query patterns, and unoptimized joins are the most frequent causes. Analyzing slow query logs and execution plans should be the first optimization step.

How does connection pooling improve API performance?

Connection pooling maintains pre-established database connections that are reused across requests, eliminating the 5-30ms overhead of creating a new connection for each request. For an API handling 1000 requests per second, this prevents 1000 unnecessary TCP handshakes, authentications, and session initializations.

Should I use offset or cursor-based pagination?

Cursor-based pagination maintains consistent performance regardless of page depth because it uses an indexed column to seek directly to the starting point. Offset-based pagination degrades for deep pages because the database must skip all preceding rows. Use cursor-based for large datasets and real-time feeds, offset-based for small datasets where page numbers are needed.

When should I move API work to background jobs?

Move work to background jobs when the operation is not required for the API response (email notifications, analytics updates, PDF generation), when it calls slow external services, or when failure should not block the user-facing response. The API enqueues the work (1-5ms) and returns immediately, reducing response times from hundreds of milliseconds to under 30ms.

API & Backend Ryan Matsuda May 18, 2026 12 min read

API Response Time Optimization: From Request to Response

Q: How much does JSON compression reduce response size?

JSON payloads typically achieve 60-85% compression ratios with gzip or Brotli because they contain repeated key names, quotes, and structural characters. A 100 KB JSON response compresses to 15-40 KB. Enable compression at the reverse proxy level for all responses over 1 KB.

Every millisecond of API response time matters. A 100ms increase in backend latency compounds through every frontend interaction that depends on the API — list views, search results, form submissions, real-time updates. For users on mobile connections, that 100ms might push a request past the threshold where the interface feels sluggish rather than instant. When an API serves as the backbone for dozens of frontend views and multiple client applications, even small latency improvements multiply across millions of daily requests.

Optimizing API response time requires a systematic approach that addresses every layer of the request lifecycle: network transport, request parsing, authentication, business logic, data access, serialization, and response delivery. The fastest APIs are not built by applying a single technique; they are the result of eliminating waste at every stage while maintaining the clarity and correctness that production systems demand.

Anatomy of API Latency

Before optimizing, you need to understand where time is spent. An API request passes through multiple phases, each contributing to the total response time. Measuring each phase independently reveals which optimizations will have the greatest impact.

The data access layer dominates most API response times. Database queries, external service calls, and cache lookups typically consume 60 to 80 percent of the total time. This makes data access optimization the highest-leverage improvement for most APIs. But optimizing only the database while ignoring serialization overhead, connection management, and response size leads to diminishing returns.

Connection Pooling and Keep-Alive

Every new database connection involves TCP handshake, authentication, and session initialization — typically 5 to 30ms per connection. Without connection pooling, an API handling 1000 requests per second would attempt 1000 new database connections per second, overwhelming the database server and adding unnecessary latency to every request.

Connection pooling maintains a set of pre-established database connections that are reused across requests. When a request needs a database connection, it borrows one from the pool; when the request completes, the connection is returned. This eliminates connection establishment overhead for all but the first request.

# PostgreSQL connection pool configuration
# pgbouncer.ini example

[databases]
myapp = host=db-primary.internal port=5432 dbname=myapp

[pgbouncer]
pool_mode = transaction       # release conn after each transaction
max_client_conn = 1000        # max incoming connections
default_pool_size = 25        # connections per database
min_pool_size = 5             # keep minimum connections warm
reserve_pool_size = 5         # overflow pool for bursts
reserve_pool_timeout = 3      # seconds before using reserve
server_idle_timeout = 600     # close idle server connections
server_lifetime = 3600        # max server connection age

HTTP keep-alive connections are equally important for APIs that call external services. Establishing a new HTTPS connection to an external service costs 100 to 300ms (DNS + TCP + TLS). Connection reuse via HTTP/1.1 keep-alive or HTTP/2 multiplexing eliminates this overhead for subsequent requests to the same host. Configure your HTTP client to maintain a connection pool for each external dependency, with pool sizes proportional to the expected request volume to that service.

Database Query Optimization

Index Strategy

Missing database indexes are the most common cause of slow API responses. An unindexed query on a table with a million rows performs a full sequential scan, reading every row to find matches. Adding the appropriate index reduces this to a B-tree lookup that examines a few dozen pages instead of thousands.

Analyze your slow query log to identify the most impactful queries. Focus on queries that appear frequently (high QPS) or take the longest (high latency). For each slow query, examine the execution plan to understand whether the optimizer uses indexes effectively. Common issues include missing indexes on foreign keys, missing composite indexes for multi-column WHERE clauses, and index scans that degrade to sequential scans due to low selectivity.

Monitor your database query performance continuously. A query that runs in 2ms today might degrade to 200ms when the table grows from 100K to 10M rows, because the working set no longer fits in memory and the query starts hitting disk.

The N+1 Query Problem

N+1 queries occur when an API endpoint loads a list of entities, then makes a separate query for each entity to load related data. Loading a list of 50 orders with their line items results in 1 query for the orders plus 50 queries for the line items — 51 total queries when 2 would suffice (one for orders, one for all line items with an IN clause). Each extra query adds round-trip latency to the database, typically 0.5 to 2ms per query over a local network. For 50 extra queries, that is 25 to 100ms of added latency.

Solve N+1 queries with eager loading (JOINs or IN-clause batch loading), DataLoader patterns that batch and deduplicate queries within a single request, or denormalized data models that store the necessary data together.

Caching Layers

Response Caching

Caching API responses is the most dramatic latency improvement available: a cache hit returns data in under 1ms, compared to 50 to 500ms for computing the response from scratch. The challenge is not implementing caching — it is maintaining cache correctness when the underlying data changes.

Design your cache strategy around data volatility. Categorize your endpoints into three tiers: immutable data (historical records, finalized transactions), slowly-changing data (user profiles, product catalogs), and frequently-changing data (inventory counts, live prices). Each tier gets a different cache TTL and invalidation strategy.

Data Type	Cache TTL	Invalidation	Example
Immutable	Indefinite	None needed	Historical transactions, audit logs
Slowly-changing	5-60 minutes	Event-driven purge	User profiles, product details
Frequently-changing	5-30 seconds	TTL expiry + write-through	Inventory counts, leaderboards
Real-time	No cache	N/A	Live prices, notifications

Multi-Layer Cache Architecture

Production APIs typically use multiple cache layers: in-process memory cache (fastest, limited by process memory), distributed cache like Redis (fast, shared across instances), and CDN or reverse proxy cache (offloads traffic before it reaches the API). Each layer has different latency characteristics and memory constraints. A well-designed multi-layer strategy checks the fastest layer first and falls back to slower layers only on miss.

Response Serialization and Compression

Serialization Performance

JSON serialization can consume a surprising portion of API response time for large payloads. Serializing a complex object graph with 10,000 nodes might take 20 to 50ms — comparable to the database query that fetched the data. For high-throughput APIs, serialization overhead is not negligible.

Reduce serialization cost by returning only the fields clients need (sparse fieldsets or GraphQL field selection), avoiding deep object nesting that requires recursive serialization, using streaming serialization for large responses, and choosing faster serialization libraries. For internal service-to-service communication where both sides are under your control, binary formats like Protocol Buffers or MessagePack offer 3 to 10 times faster serialization and 30 to 80 percent smaller payloads compared to JSON.

Response Compression

Enable gzip or Brotli compression for all API responses over 1 KB. JSON compresses exceptionally well — typical compression ratios are 60 to 85 percent — because JSON payloads contain repeated key names, quotes, and structural characters. A 100 KB JSON response compresses to 15 to 40 KB, reducing transfer time proportionally.

Configure compression at the reverse proxy level rather than in application code. This avoids consuming application server CPU for compression and allows the reverse proxy to cache compressed responses, serving them directly without recompression.

Async Processing Patterns

Not all work triggered by an API request needs to complete before the response is sent. Operations like sending notification emails, updating analytics, generating thumbnails, and syncing to external systems can happen asynchronously after the response is delivered.

Move non-critical work to background jobs. The API endpoint enqueues the work (adding a message to a queue takes 1 to 5ms) and returns immediately with a 202 Accepted status. The background worker processes the job without affecting API response time. This pattern reduces p50 response times by eliminating variable-latency operations from the critical path and reduces p99 times by preventing slow external service calls from cascading into request timeouts.

# Before: synchronous processing (150-500ms)
def create_order(request):
    order = save_to_database(request.data)      # 20ms
    send_confirmation_email(order)                # 80ms
    update_inventory_service(order)               # 50ms
    sync_to_analytics(order)                      # 30ms
    generate_invoice_pdf(order)                   # 120ms
    return Response(order, status=201)

# After: async processing (25ms)
def create_order(request):
    order = save_to_database(request.data)        # 20ms
    enqueue_task('order.created', order.id)        # 3ms
    return Response(order, status=201)

# Background worker handles the rest
def handle_order_created(order_id):
    order = load_order(order_id)
    send_confirmation_email(order)
    update_inventory_service(order)
    sync_to_analytics(order)
    generate_invoice_pdf(order)

Pagination and Payload Size

Returning unbounded result sets is one of the most common API performance mistakes. An endpoint that returns all matching records becomes progressively slower as data grows, eventually timing out or exhausting server memory. Always paginate list endpoints and set a reasonable default page size (20 to 50 items for most use cases).

Choose your pagination strategy based on your data access patterns. Offset-based pagination (?page=5&limit=20) is simple but degrades for deep pages because the database must skip all preceding rows. Cursor-based pagination (?after=abc123&limit=20) maintains consistent performance regardless of depth because it uses an indexed column to seek directly to the starting point.

For endpoints that serve large datasets, consider implementing field selection (allowing clients to request only the fields they need) and response envelopes that include pagination metadata (total count, next cursor, has_more flag) to help clients make efficient subsequent requests.