APIPerformanceBackendLatencyDevOps

REST API Performance Testing: How to Benchmark Latency, TTFB, and Throughput

A complete guide to benchmarking REST API speed. Discover how to measure endpoint latency, diagnose backend bottlenecks, and optimize API response times.

PingXD Team4 min read

In modern web development, frontend applications, single-page apps (SPAs), mobile apps, and microservices depend entirely on REST APIs for data retrieval and state mutations. A sluggish API directly translates into slow client-side rendering, unresponsive user interfaces, and elevated cart abandonment rates.

Unlike static web pages where assets can be aggressively cached at the edge, API endpoints often involve database queries, token authentication, JSON serialization, and third-party webhooks.

This guide explores how to benchmark API speed, break down the lifecycle of an API request, and systematically eliminate backend bottlenecks using an API speed test.

Anatomy of an API request lifecycle

When a client sends an HTTP request to an API endpoint (e.g., GET /api/v1/products), total latency is comprised of five distinct phases:

[ DNS Lookup ] -> [ TCP Handshake ] -> [ TLS Negotiation ] -> [ TTFB (Server Processing) ] -> [ Response Download ]
  1. DNS Lookup: Time spent resolving the API hostname to an IP address. Can add 20–100ms on un-cached lookups.
  2. TCP Connection: Three-way handshake between client and server (1 round trip time, or RTT).
  3. TLS Handshake: Cryptographic negotiation for HTTPS (1–2 RTTs).
  4. Time to First Byte (TTFB): The time between sending the HTTP request and receiving the first byte of data. This reflects pure server processing, database execution, and internal queueing.
  5. Content Download: Transferring the JSON response body over the network, determined by payload size and connection bandwidth.

Key metrics to measure in API benchmarking

When running an API speed test, focus on these core benchmarks:

  • p50 (Median) Response Time: The typical latency experienced by average users.
  • p95 / p99 Tail Latency: The slowest 5% and 1% of requests. Tail latency reveals database lock contention, garbage collection pauses, and serverless cold starts.
  • Payload Size: The uncompressed and compressed size of the JSON response payload.
  • Status Code Reliability: Consistency of 200 OK responses versus intermittent 429 (Rate Limit) or 504 (Gateway Timeout) errors.

Common API performance bottlenecks and fixes

1. The N+1 database query problem

The most common cause of high TTFB in REST APIs is the N+1 query pattern in ORMs (Object-Relational Mappers). If fetching 50 orders triggers 1 query for the orders and 50 separate queries to fetch customer names, database overhead explodes.

Fix: Use eager loading (such as include or select_related) or batch database queries with JOIN statements.

2. Excessive JSON payload sizes

Returning unnecessary database columns, deeply nested relationship trees, or uncompressed 5MB JSON blobs creates severe network serialization and client parsing overhead.

Fix:

  • Implement field filtering (sparse fieldsets) or pagination (cursor-based or limit/offset).
  • Enable Gzip or Brotli compression on your API gateway or web server (e.g., NGINX, Caddy, or Cloudflare). Brotli can reduce JSON response sizes by up to 80%.
# NGINX JSON compression configuration
gzip on;
gzip_types application/json text/plain;
gzip_min_length 1000;

3. Serverless cold starts

If your API runs on AWS Lambda, Google Cloud Functions, or Vercel Serverless, instances that have not received traffic for several minutes must initialize the runtime environment, download packages, and connect to databases, adding 500ms to 3 seconds of latency.

Fix:

  • Maintain lightweight bundle sizes by tree-shaking dependencies.
  • Use provisioned concurrency for mission-critical endpoints.
  • Utilize database connection poolers like Prisma Accelerate, AWS RDS Proxy, or PgBouncer to prevent opening new database connections on every cold invocation.

4. Lack of caching on read-heavy endpoints

Endpoints returning catalog data, user profiles, or public metadata often perform identical database queries on every hit.

Fix:

  • Implement in-memory caching with Redis or Valkey.
  • Return HTTP Cache-Control headers with stale-while-revalidate to allow API gateways and CDNs to serve cached JSON responses instantly while refreshing data in the background:
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: public, max-age=60, stale-while-revalidate=300

Step-by-step: Testing your API with PingXD

  1. Navigate to the PingXD API Speed Test.
  2. Enter your endpoint URL (e.g., https://api.yourdomain.com/v1/health).
  3. Select your HTTP method: GET, POST, PUT, or DELETE.
  4. Add custom headers (such as Authorization: Bearer <token> or Content-Type: application/json).
  5. For POST/PUT requests, provide your test JSON payload.
  6. Select your test regions (e.g., North America, Europe, or Asia-Pacific) to benchmark geographical response differences.

Review the latency breakdown and TTFB to pinpoint whether slowness is caused by network distance, connection negotiation, or backend server execution.

Combine your API testing with a DNS lookup check and server response time analysis to ensure end-to-end performance across your entire stack.

Keep learning