API Latency Benchmarking: REST, WebSocket, Webhooks

API latency benchmarking measures the time a request takes from client to server and back, and the method differs by protocol: REST uses one-off HTTP requests, WebSocket measures message round-trips over a persistent connection, and webhooks measure the delay from event occurrence to the receiver’s HTTP endpoint. This article explains how to measure each type accurately, what tools to use, and how to avoid common pitfalls that make latency numbers misleading.

Why Protocol Choice Changes Your Measurement

REST, WebSocket, and webhooks are fundamentally different delivery mechanisms, so a single latency test cannot cover all three. REST is synchronous: the client sends a request and waits for a response. WebSocket is a persistent, bidirectional channel where either side can send a message at any time. Webhooks are asynchronous push notifications: your server sends an HTTP POST to a pre-registered URL when an event occurs, and the receiver typically acknowledges immediately.

Because of these differences, the metric you care about varies. For REST, you usually measure the full round-trip time (RTT) including network and server processing. For WebSocket, you measure the time from sending a message to receiving the corresponding reply, but you must also account for connection establishment overhead. For webhooks, the meaningful latency is the time from when the triggering event happens (e.g., a payment is completed) to when the receiver processes the payload—this includes your internal event pipeline, not just the HTTP POST.

Measuring REST API Latency

REST latency is the simplest to measure because each request is independent. The standard approach is to send a single HTTP request and record the time from just before the request is sent to just after the response headers/body are received. Tools like curl, ab (ApacheBench), wrk, or hey give you this number, but you need to be careful about what you’re actually timing.

Here are the key steps for a reliable REST latency test:

• Warm up the server: send a few requests before recording so caches and connection pools are populated.
• Use a real client library (e.g., Python requests, Node axios) rather than raw curl if your production clients use those—they may add overhead like DNS resolution or TLS handshakes.
• Separate network and server time: if you can, instrument the server to log its own processing time, then subtract it from the client-measured RTT to get network latency.
• Test under load: latency is not a single number; it increases with concurrency. Run tests at 1, 10, 50, and 100 concurrent requests to see how latency degrades.
• Use percentiles: report p50, p95, and p99 rather than just the average, because outliers matter in production.

A common mistake is to measure the time to receive the response body when you only need the headers. If your API streams a large payload, the time-to-first-byte (TTFB) is often more meaningful than the full download time. Use curl -w to get both time_starttransfer and time_total.

Measuring WebSocket Latency

WebSocket latency is trickier because the connection is persistent. The most common method is the ping/pong frame: the WebSocket protocol has built-in control frames for this. A client sends a ping frame, the server responds with a pong frame, and the round-trip time is the latency. Most WebSocket libraries expose this as a built-in heartbeat or you can implement it manually.

However, ping/pong only measures the network and server’s event-loop responsiveness—it does not measure application-level processing time. If your server does heavy work when handling a message (e.g., database queries), you need to measure the time from sending a business message to receiving the corresponding reply. The steps are:

1. Establish a WebSocket connection and wait for the open event.
2. Record the timestamp immediately before sending a message (e.g., Date.now() or performance.now()).
3. On the client, listen for the matching reply message and record the timestamp when it arrives.
4. Subtract the two timestamps. This includes network RTT plus server processing time.

For a more accurate picture, run the test multiple times and take the median. Also measure the connection establishment time separately (from TCP handshake to the open event), because that is a one-time cost that can dominate if your clients connect frequently. Tools like wscat, websocat, or custom scripts in Node.js/Python work well. For load testing, artillery has WebSocket support.

Measuring Webhook Latency

Webhooks are asynchronous, so you cannot measure latency from the client side. The receiver gets an HTTP POST, but the sender’s event may have occurred seconds earlier. To measure true webhook latency, you need to timestamp at both ends:

1. When the event occurs (e.g., a user clicks “Pay”), record the server-side event timestamp and include it in the webhook payload (e.g., a custom header X-Event-Time).
2. On the receiver, record the time the HTTP request arrives.
3. Subtract the two timestamps. This gives you the end-to-end delay, which includes your event queue, any retries, and network transit.

If you cannot modify the payload, you can approximate latency by measuring the time from when you send a test webhook (e.g., from a script) to when the receiver logs it. But that only measures the HTTP POST delivery, not the event-to-webhook pipeline.

Important caveats: webhook providers often retry on failure, so a high latency number might be due to a retry after a timeout, not the original attempt. Check the X-Webhook-Attempt header (if present) to see if it’s a retry. Also, some providers batch events, so a webhook may be delayed while waiting for more events—this is not network latency but batching policy.

Choosing the Right Tool for Your Test

Your choice of tool depends on whether you need a quick check or a rigorous load test. For REST, curl is fine for a single measurement, but for percentiles under load, use wrk or hey. For WebSocket, wscat is good for manual testing, but artillery or a custom Node.js script with ws is better for repeatable benchmarks. For webhooks, you often need a public endpoint—use a tool like webhook.site or a small server you control to receive the POST and log timestamps.

If you are comparing different API providers or versions, run the same test on the same network and at the same time of day. Network conditions vary, so run tests from multiple locations if your users are distributed. Cloud providers offer latency testing tools (e.g., AWS’s CloudWatch Synthetics), but they are not free and may not be necessary for a simple benchmark.

Common Pitfalls That Invalidate Your Numbers

Even with the right tool, many factors can skew your latency measurements:

• DNS resolution: If your client resolves the hostname each time, it adds 10-100ms. Use an IP or a persistent connection to isolate server latency.
• TLS handshake: For HTTPS, the handshake adds one or two RTTs. If you want to measure the API itself, reuse connections or use HTTP/2 which multiplexes.
• Client-side processing: If your client parses JSON or does other work after receiving the response, that time is included in your measurement unless you timestamp right after the response is received.
• Server-side caching: A cached response is much faster than a cold one. Decide whether you are measuring cold or warm latency, and state it in your report.
• Time synchronization: For webhook latency, if the sender and receiver clocks are not synchronized (e.g., using NTP), your subtraction will be off by the clock skew. Use a single timestamp source if possible.

A common misconception is that a single latency number is enough. In practice, latency follows a distribution—the p99 can be 10x the median. Always report multiple percentiles, and run the test long enough to get a stable sample (at least 100 requests for REST, 1000 messages for WebSocket).

Interpreting Results and Setting Budgets

Once you have your measurements, compare them against user expectations. For REST, a p95 under 500ms is typical for public APIs, but it depends on your use case—a payment API may need p99 under 1 second, while a chat API can tolerate higher. For WebSocket, latency is usually lower because the connection is open, so p95 under 100ms is common for real-time features like typing indicators. For webhooks, latency is often less critical—most providers accept a few seconds, but if you are sending time-sensitive notifications (e.g., fraud alerts), you may need p95 under 1 second.

Set a latency budget based on your product requirements, then test against it. If you see degradation, profile the server (CPU, database queries, network) to find the bottleneck. Remember that latency is not just about the server—it includes the user’s network. If your users are on mobile, test on a throttled connection (e.g., using Chrome DevTools or tc on Linux) to simulate 3G/4G.

Frequently Asked Questions

Q: Can I use the same tool for REST, WebSocket, and webhooks?
No. REST tools like wrk don’t handle WebSocket’s persistent connection or webhook’s asynchronous nature. Use dedicated tools or custom scripts per protocol.

Q: What is a good latency for a REST API?
It depends on your domain. For public APIs, p95 under 500ms is a common target, but for internal microservices, p99 under 100ms is often expected. Always define your own budget based on user experience.

Q: Why is my WebSocket latency higher than my REST latency?
WebSocket latency includes the time to send a message and receive a reply over an established connection, but if your server processes messages synchronously, it may be similar to REST. Higher latency can be due to server-side event-loop blocking or network congestion. Also, if you are measuring the first message after connecting, it includes connection setup overhead.

Q: How do I measure webhook latency if I don’t control the sender?
You can only measure the time from when the HTTP request arrives, not when the event occurred. To get true end-to-end latency, you need the sender to include a timestamp in the payload. If they don’t, you can only measure delivery time, which is a lower bound.

Q: Should I use p50 or p99 for my latency report?
Use both. p50 gives you the typical experience, but p99 shows the worst-case. Many users experience p99 during peak times, so it’s critical for capacity planning. A single average hides outliers.

Q: Does HTTP/2 reduce REST API latency?
Yes, HTTP/2 can reduce latency by multiplexing multiple requests over one connection, avoiding head-of-line blocking and reducing connection overhead. However, the server must support it, and the improvement is most visible with many concurrent requests.

Related

• Valorant Reyna Guide: Tips, Tricks, and Ability Use
• Private-First Research Tools: Best Alternatives to AI Search
• Meta AI: What It Is and How Meta’s Chatbot Works