There is no universally faster protocol. To choose well, you must measure the full operation and understand which part of the system consumes the time.

Introduction

Performance comparisons often present a ranking: one technology appears faster than another and that figure becomes a general recommendation. But results depend on the operation, the data, the network, the infrastructure, the implementation, and how you measure.

A useful benchmark does not answer “which protocol is fastest for everything?”. It answers “which option best solves this workload under these conditions?”.

1. The total time of a request

The time perceived by the client may include:

• DNS resolution.
• Connection establishment and TLS negotiation.
• Network latency.
• Time in queues.
• Authentication and authorization.
• Application logic.
• Database queries.
• Calls to external services.
• Serialization and compression.
• Transfer and processing on the client.

Not all of these components appear in every request, and some happen in parallel. The point is that the protocol is only one part of the path.

A 1 KB response can take a long time if it waits on a 600 ms dependency. A 200 KB response can be fast if it is served from a nearby cached CDN.

2. Metrics that matter

Metric	What it explains
Latency p50	Median behavior
Latency p95	Experience of the slower requests
Latency p99	Extreme latency tail
Throughput	Operations completed per second
CPU	Processing cost
Memory	Memory pressure and scalability
Bytes transferred	Network cost
Error rate	Reliability
Timeouts	Operations that exceed the limit
Saturation	Resources that reach capacity

Averages alone can hide problems. A system can have an acceptable mean and still show a very high p99 due to queues, pauses, an external dependency, or saturation.

3. Designing a fair comparison

To compare REST, GraphQL, and gRPC, implement the same business operation and use equivalent data. Keep hardware, network, logic, permissions, and dependencies constant.

Test different scenarios:

• New and reused connections.
• Cold and warm cache.
• Small, medium, and large responses.
• Low and high concurrency.
• Compression on and off.
• Simulated and real dependencies.
• Sustained loads, not only short bursts.

Do not compare a REST API that returns extra data and runs N+1 queries with a gRPC implementation that uses optimized queries. In that case you would not be isolating the effect of the protocol.

WebSockets needs tests appropriate to its usage pattern: concurrent connections, messages per second, queue size, reconnections, and event delivery. It is not equivalent to measuring an isolated HTTP request.

4. Why the protocol does not explain everything

Serialization

Protocol Buffers can produce more compact messages than JSON in certain scenarios. But if database time dominates, the benefit may be small.

Number of network round trips

An operation that requires several sequential requests can be slower than one that aggregates the data. GraphQL can help in certain interfaces; REST can also offer composite endpoints when they make sense.

Cache

A cached result can avoid queries and processing. Comparing a system with a warm cache against another without cache does not let you attribute the difference to the protocol alone.

Connections

Connection reuse can reduce establishment costs. Results change if each request opens a new connection or if connections stay alive.

Database and external services

A slow query, a saturated dependency, or a chain of calls between services can dominate latency, regardless of the API format.

5. When to choose each option

REST: a good starting point for public APIs, well-defined resources, integrations, and operations that leverage HTTP and conventional caching.

GraphQL: useful when several clients need different combinations of data and the flexibility offsets the complexity of resolvers, security, and cache.

gRPC: attractive for communication between services controlled by the organization, typed contracts, high volume, or streaming.

WebSockets: appropriate for continuous bidirectional communication and real-time events.

SSE: useful when the server streams updates to the client, but you do not need a permanent bidirectional channel.

Webhooks: appropriate for notifying events between systems over HTTP without keeping an open connection.

MQTT: designed for lightweight publish-and-subscribe messaging, common in IoT and devices with limited connectivity.

HTTP/3 and QUIC: can improve certain transport scenarios, but they do not replace the need to design queries and services well.

WebTransport: a more specialized option for applications that need streams and datagrams over HTTP/3, when platform compatibility allows it.

UMD, if it means Universal Module Definition, belongs to packaging and loading JavaScript modules; it is not a network communication alternative.

6. Resilience is also part of performance

A system is not efficient if it saturates easily or recovers poorly from failures.

It is worth establishing:

• Timeouts and cancellation.
• Concurrency limits.
• Retries with backoff.
• Idempotency for operations that may be repeated.
• Circuit breakers when appropriate.
• Rate limiting.
• Distributed observability.
• Message and queue size limits.

Unbounded retries can worsen an outage by increasing load. A persistent connection without queue control can exhaust memory. Resilience should be part of the design, not added after an incident.

7. A decision framework

Before selecting a technology, answer:

1. Is the communication request-response, flexible query, remote call, or event stream?
2. Who initiates the messages and in which direction do they travel?
3. How much data is transferred and how often?
4. Is caching possible and safe?
5. What latency, throughput, and consistency requirements exist?
6. Which clients and languages must integrate?
7. What operational complexity can the team maintain?
8. What do tests with realistic loads show?

This framework avoids choosing a technology by popularity or by an isolated benchmark figure.

Conclusion

Performance is a property of the full system. Protocol, serialization, and transport matter, but so do queries, dependencies, cache, compression, concurrency, and infrastructure.

REST can be sufficient and efficient for a wide variety of applications. GraphQL, gRPC, WebSockets, and other options have value when their characteristics answer a concrete need.

Measure the real operation, optimize the bottleneck, and choose the technology that best balances performance, complexity, cost, and maintainability.

In this series

1. REST: how to design and optimize an API
2. REST vs GraphQL
3. gRPC vs REST
4. WebSockets, SSE, and Webhooks
5. Cache and compression
6. Benchmarks and architecture decisions (this note)

References

• gRPC — Performance Best Practices
• GraphQL — Performance
• MDN — HTTP caching
• RFC 9114 — HTTP/3
• RFC 9000 — QUIC
• W3C — WebTransport