No existe un protocolo universalmente más rápido. Para elegir bien, hay que medir la operación completa y entender qué parte del sistema consume el tiempo.

Introducción

Las comparativas de rendimiento suelen presentar una clasificación: una tecnología aparece más rápida que otra y esa cifra se convierte en una recomendación general. Pero los resultados dependen de la operación, los datos, la red, la infraestructura, la implementación y la forma de medir.

Un benchmark útil no responde «¿cuál es el protocolo más rápido para todo?». Responde «¿qué opción resuelve mejor esta carga de trabajo bajo estas condiciones?».

1. El tiempo total de una solicitud

El tiempo percibido por el cliente puede incluir:

• Resolución DNS.
• Establecimiento de conexión y negociación TLS.
• Latencia de red.
• Tiempo en colas.
• Autenticación y autorización.
• Lógica de aplicación.
• Consultas a base de datos.
• Llamadas a servicios externos.
• Serialización y compresión.
• Transferencia y procesamiento en el cliente.

No todos estos componentes aparecen en cada solicitud, y algunos ocurren en paralelo. La idea es que el protocolo es solo una parte del recorrido.

Una respuesta de 1 KB puede tardar mucho si espera una dependencia de 600 ms. Una respuesta de 200 KB puede ser rápida si se sirve desde una CDN cercana y cacheada.

2. Métricas que importan

Métrica	Qué explica
Latencia p50	Comportamiento mediano
Latencia p95	Experiencia de las solicitudes más lentas
Latencia p99	Cola de latencia extrema
Throughput	Operaciones completadas por segundo
CPU	Coste de procesamiento
Memoria	Presión de memoria y escalabilidad
Bytes transferidos	Coste de red
Tasa de errores	Fiabilidad
Timeouts	Operaciones que exceden el límite
Saturación	Recursos que llegan a su capacidad

Promedios solos pueden ocultar problemas. Un sistema puede tener una media aceptable y, aun así, mostrar p99 muy alto por colas, pausas, dependencia externa o saturación.

3. Diseñar una comparación justa

Para comparar REST, GraphQL y gRPC, implementa la misma operación de negocio y utiliza datos equivalentes. Mantén constantes hardware, red, lógica, permisos y dependencias.

Prueba escenarios diferentes:

• Conexiones nuevas y reutilizadas.
• Caché fría y caliente.
• Respuestas pequeñas, medianas y grandes.
• Concurrencia baja y alta.
• Compresión activada y desactivada.
• Dependencias simuladas y reales.
• Cargas sostenidas, no solo ráfagas breves.

No compares una API REST que devuelve datos extra y ejecuta consultas N+1 con una implementación gRPC que usa consultas optimizadas. En ese caso no estarías aislando el efecto del protocolo.

WebSockets necesita pruebas apropiadas para su patrón de uso: conexiones concurrentes, mensajes por segundo, tamaño de colas, reconexiones y entrega de eventos. No es equivalente a medir una solicitud HTTP aislada.

4. Por qué el protocolo no explica todo

Serialización

Protocol Buffers puede producir mensajes más compactos que JSON en determinados escenarios. Pero si el tiempo de base de datos domina, el beneficio puede ser pequeño.

Número de viajes de red

Una operación que requiere varias solicitudes secuenciales puede ser más lenta que una que agrupa los datos. GraphQL puede ayudar en ciertas interfaces; REST también puede ofrecer endpoints compuestos cuando tienen sentido.

Caché

Un resultado cacheado puede evitar consultas y procesamiento. Comparar un sistema con caché caliente contra otro sin caché no permite atribuir la diferencia únicamente al protocolo.

Conexiones

La reutilización de conexiones puede reducir costes de establecimiento. Los resultados cambian si cada petición abre una conexión nueva o si las conexiones se mantienen activas.

Base de datos y servicios externos

Una consulta lenta, una dependencia saturada o una cadena de llamadas entre servicios puede dominar la latencia, independientemente del formato de la API.

5. Cuándo elegir cada opción

REST: buen punto de partida para APIs públicas, recursos bien definidos, integraciones y operaciones que aprovechan HTTP y caché convencional.

GraphQL: útil cuando varios clientes necesitan distintas combinaciones de datos y la flexibilidad compensa la complejidad de resolvers, seguridad y caché.

gRPC: atractivo para comunicación entre servicios controlados por la organización, contratos tipados, alto volumen o streaming.

WebSockets: apropiado para comunicación bidireccional continua y eventos en tiempo real.

SSE: útil cuando el servidor transmite actualizaciones al cliente, pero no necesita un canal bidireccional permanente.

Webhooks: apropiados para notificar eventos entre sistemas mediante HTTP sin mantener una conexión abierta.

MQTT: diseñado para mensajería ligera de publicación y suscripción, común en IoT y dispositivos con conectividad limitada.

HTTP/3 y QUIC: pueden mejorar ciertos escenarios de transporte, pero no reemplazan la necesidad de diseñar bien las consultas y los servicios.

WebTransport: opción más especializada para aplicaciones que necesitan flujos y datagramas sobre HTTP/3, cuando la compatibilidad de la plataforma lo permite.

UMD, si se refiere a Universal Module Definition, pertenece al empaquetado y carga de módulos JavaScript; no es una alternativa de comunicación de red.

6. Resiliencia también forma parte del rendimiento

Un sistema no es eficiente si se satura con facilidad o se recupera mal de los fallos.

Conviene establecer:

• Timeouts y cancelación.
• Límites de concurrencia.
• Reintentos con backoff.
• Idempotencia para operaciones que puedan repetirse.
• Circuit breakers cuando sean apropiados.
• Rate limiting.
• Observabilidad distribuida.
• Límites de tamaño de mensajes y colas.

Los reintentos sin límites pueden empeorar una caída al aumentar la carga. Una conexión persistente sin control de colas puede agotar memoria. La resiliencia debe formar parte del diseño, no añadirse después de un incidente.

7. Un marco de decisión

Antes de seleccionar una tecnología, responde:

1. ¿La comunicación es solicitud-respuesta, consulta flexible, llamada remota o flujo de eventos?
2. ¿Quién inicia los mensajes y en qué dirección viajan?
3. ¿Cuántos datos se transfieren y con qué frecuencia?
4. ¿La caché es posible y segura?
5. ¿Qué requisitos existen de latencia, throughput y consistencia?
6. ¿Qué clientes y lenguajes deben integrarse?
7. ¿Qué complejidad operativa puede mantener el equipo?
8. ¿Qué muestran las pruebas con cargas realistas?

Este marco evita elegir una tecnología por popularidad o por una cifra aislada de benchmark.

Conclusión

El rendimiento es una propiedad del sistema completo. El protocolo, la serialización y el transporte importan, pero también importan las consultas, las dependencias, la caché, la compresión, la concurrencia y la infraestructura.

REST puede ser suficiente y eficiente para una gran variedad de aplicaciones. GraphQL, gRPC, WebSockets y otras opciones tienen valor cuando sus características responden a una necesidad concreta.

Mide la operación real, optimiza el cuello de botella y elige la tecnología que mejor equilibre rendimiento, complejidad, coste y mantenibilidad.

En esta serie

1. REST: cómo diseñar y optimizar una API
2. REST vs GraphQL
3. gRPC vs REST
4. WebSockets, SSE y Webhooks
5. Caché y compresión
6. Benchmarks y decisiones de arquitectura (esta nota)

Referencias

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