¿Puedo usar SSE con autenticación basada en tokens?

Sí. Como SSE se ejecuta sobre HTTP, las peticiones de mismo origen envían cookies automáticamente. Para peticiones de origen diferente, pase conCredentials: true al constructor de EventSource para incluir las cookies. Para autenticación basada en token, pase el token como parámetro de consulta en la URL de EventSource — no es muy elegante, pero el HTTPS lo protege en tránsito y funciona con todas las implementaciones de EventSource.

¿Es el límite de conexión SSE de 6 un problema real en 2025?

Sólo en HTTP/1.1. HTTP/2 multiplexa flujos sobre una conexión única, por lo que el límite no se aplica. La mayoría de los entornos de alojamiento y CDNs se configuran por defecto en HTTP/2, por lo que esto es en gran medida un problema secundario — pero vale la pena confirmarlo en la configuración del servidor. Si estás usando HTTP/1.1 por alguna razón, una solución alternativa es servir SSE desde un subdominio dedicado con su propio presupuesto de conexiones.

¿Funcionan los WebSockets con funciones sin servidor?

AWS API Gateway tiene soporte nativo para APIs de WebSocket, pero las invocaciones de Lambda son inestables — por lo tanto, necesitas DynamoDB (o algo similar) para rastrear los IDs de conexión y dirigir mensajes entre clientes. Cloudflare Workers soporta WebSockets de forma nativa mediante Durable Objects. Funciona, pero añade una sobrecarga arquitectónica que SSE en un servidor persistente evita por completo.

¿Se sigue utilizando el polling largo en producción por empresas serias?

Sí. Los feeds de actividad en tiempo real de GitHub los han utilizado. Basecamp los ha dependido durante años. Cuando la actualización de los datos medida en segundos es aceptable y deseas la implementación más sencilla posible — sin actualizaciones de protocolo, sin sesiones pegadas, sin lógica de reconexión — el polling es una opción completamente legítima. No es glamoroso, pero es confiable.

¿Odias los anuncios? Ir Sin publicidad Hoy 

WebSockets vs SSE vs Long Polling — Tiempo real sin el pánico

Actualizado en 20 de mayo de 2026

WebSockets, SSE y el polling largo tienen cada uno su lugar. Aquí está cuándo usar cada uno — con una tabla de comparación, ejemplos de código y una guía de decisión.

WebSockets vs SSE vs Long Polling — Real-Time Without the Panic 1

ANUNCIO · ¿ELIMINAR?

La mayoría de desarrolladores optan por WebSockets por defecto. Eso normalmente es incorrecto.

No porque los WebSockets sean malos — son excelentes en lo que hacen. Pero implican un alto costo de infraestructura: sesiones pegadas en los balanceadores de carga, lógica personalizada de latidos, soluciones para autenticación y configuración de proxies que funcionan bien hasta que alguien abre tu aplicación en un office corporativo. Para la mayoría de los requisitos de «tiempo real», ese costo no está justificado.

La versión breve: si los datos fluyen solo desde el servidor al cliente, utiliza Server-Sent Events (SSE). Si el cliente necesita enviar datos de regreso con baja latencia, utiliza WebSockets. Si tu frecuencia de actualización se mide en segundos y deseas la implementación más sencilla posible, el long polling todavía funciona — y no hay vergüenza en eso.

UUID v7

Técnica	Dirección	Soporte en navegadores	Reconexión automática	Complejidad del balanceador de carga	APIs, microservicios, autenticación entre dominios
Long polling	Servidor → Cliente	Universal	Manual (requisición del cliente)	Ninguna (HTTP estándar)	Actualizaciones de baja frecuencia, intervalos ≥15 segundos
SSE	Servidor → Cliente	Todos los modernos (no IE11)	Incluida (EventSource)	Ninguna (HTTP estándar)	Flujos en tiempo real, notificaciones, dashboards
WebSockets	Bidireccional	Todos los modernos	Manual (heartbeat personalizado)	Requiere sesiones pegadas	Chat, juegos, edición colaborativa

Long polling

El long polling es el polling estándar HTTP donde el servidor mantiene la solicitud abierta hasta que tiene algo que devolver — o hasta que se produce un tiempo de espera. El cliente envía una solicitud, el servidor espera, devuelve la respuesta cuando hay datos disponibles y el cliente inmediatamente envía la siguiente solicitud. Es un bucle disfrazado de una llamada de red.

Esto es realmente adecuado para una amplia gama de casos de uso:

Indicadores de notificaciones — los conteos de mensajes no leídos que se actualizan cada 30 segundos no necesitan una conexión persistente.
Dashboards de administración con frescura relajada — métricas que se actualizan cada 15 a 60 segundos funcionan bien con el polling.
Aplicaciones móviles en conexiones inestables — las conexiones persistentes son eliminadas por el manejo agresivo de la red; el polling se reconecta correctamente en cada solicitud.
Detrás de proxies corporativos — muchos proxies empresariales bufferizan o terminan conexiones no estándar. El polling HTTP funciona en todos los lugares, sin excepciones.

La limitación en escalamiento es real. Cada solicitud mantenida abierta ocupa un slot de conexión. En servidores con hilos esto se vuelve costoso; en servidores con bucle de eventos (Node.js, Tornado, Go con gorutinas) es manejable pero no gratis. A nivel de decenas de miles de usuarios simultáneos, las matemáticas sobre los recursos del servidor comienzan a importar.

Server-Sent Events (SSE)

SSE es la opción que la mayoría de desarrolladores omiten al ir hacia los WebSockets. Ese es un error en cualquier caso donde los datos fluyen en una sola dirección: del servidor al cliente.

Funciona sobre HTTP estándar. El servidor establece Content-Type: text/event-stream y escribe mensajes separados por saltos de línea en el cuerpo de la respuesta indefinidamente. La API nativa del navegador EventSource maneja la reconexión automáticamente — incluyendo un Last-Event-ID encabezado para que el servidor pueda reanudar el flujo tras una pérdida. Obtienes tipos de eventos nombrados, intervalos de reintentos configurables y no se requiere ninguna biblioteca.

const source = new EventSource('/api/events');

source.addEventListener('priceUpdate', (e) => {
  const { price, symbol } = JSON.parse(e.data);
  updateTicker(symbol, price);
});

source.onerror = () => {
  // EventSource reconnects automatically — nothing to do here
};

Lo que SSE hace bien:

HTTP estándar — funciona a través de balanceadores de carga, proxies inversos y CDNs sin configuración adicional. Sin sesiones pegadas.
Reconexión automática — incluida en la especificación. Establece el retry: campo en el flujo para configurar el intervalo; el cliente maneja el resto.
Multiplexado HTTP/2 — elimina el límite anterior de 6 conexiones por dominio en HTTP/1.1. Si estás en HTTP/2 (deberías estarlo), este no es un problema.
Implementación más sencilla del servidor — mantiene una conexión abierta y escribe en ella. No requiere handshake de protocolo, no requiere análisis de marcos, no requiere lógica de latidos.

La única limitación real: SSE es unidireccional. Los clientes no pueden enviar datos a través de una conexión SSE. En la práctica, esto rara vez es un problema — utiliza solicitudes POST normales para cualquier cosa que el cliente necesite enviar, junto con el flujo SSE para eventos del servidor. Ambos coexisten sin problemas.

El límite de conexiones HTTP/1.1 merece conocerse. Los navegadores limitan a 6 conexiones simultáneas por dominio en todos los pestañas. Tres pestañas de navegador cada una consumiendo dos flujos SSE = límite alcanzado. HTTP/2 elimina esto mediante multiplexado. Si no puedes garantizar la entrega de HTTP/2 (algunas configuraciones antiguas de CDNs, algunos proxies corporativos), tenlo en cuenta.

WebSockets

Los WebSockets son la herramienta adecuada cuando realmente se necesita mensajería bidireccional de baja latencia. Los casos de uso que justifican la complejidad:

Chat — los mensajes de cada usuario deben llegar a otros en tiempo real. Los WebSockets son la solución estándar por una buena razón.
Juegos multijugador — el estado del juego se sincroniza constantemente entre los clientes, a menudo a 20-60 actualizaciones por segundo. Ninguna otra solución se acerca a la misma eficiencia por frame.
Edición colaborativa — la edición en tiempo real basada en CRDT o OT (Notion, Figma, estilo Google Docs) requiere que cada tecla se propague con mínima latencia.
Terminales de trading — flujos de precios sub-100ms con envío de órdenes en la misma conexión. Los WebSockets fueron diseñados para esto.

Los costos de infraestructura que SSE y el polling evitan:

Sesiones pegadas — las conexiones de WebSockets son estatales y vinculadas a un solo proceso de servidor. Los balanceadores de carga necesitan afinidad de sesión (hash de IP o basado en cookies) para dirigir correctamente los reintentos. Sin ello, un cliente que se reconecta puede caer en un servidor que no conozca su sesión.
Configuración de proxy y CDN — Nginx, HAProxy y Cloudflare todos soportan WebSockets pero requieren configuración explícita (Upgrade y Connection encabezados, proxy_http_version 1.1 en Nginx). Algunos firewalls corporativos bloquean 101 Switching Protocols. Te darás cuenta de esto en tickets de soporte de usuarios en oficinas específicas.
Complejidad de autenticación — los WebSockets no pueden establecer encabezados personalizados después del handshake inicial. La autenticación por token normalmente implica pasar el token en la cadena de consulta (feo, común) o en el primer mensaje tras la conexión (más limpio, pero requiere lógica de control en el servidor).
Latidos — la especificación no requiere keepalives. Sin lógica personalizada de ping/pong, no detectarás conexiones muertas hasta que el siguiente mensaje falle. O bien, implementa latidos o acepta conexiones estériles acumulándose silenciosamente.

Ninguna de estas no es un bloqueo — son complejidades que no existen con SSE o el polling HTTP. Si eliges WebSockets para un flujo de notificaciones o un dashboard en tiempo real, estás pagando ese costo sin razón.

Cómo elegir

Trabaja en orden por estos puntos:

¿El cliente necesita enviar datos al servidor con alta frecuencia, o ¿la latencia bajo 200ms es crítica? No → salta los WebSockets.
¿Los datos fluyen solo del servidor al cliente? Sí → SSE es casi seguramente la opción correcta.
¿Estás en HTTP/2? Si es afirmativo, SSE no tiene limitaciones significativas para la mayoría de los casos. Si no, ten en cuenta el límite de 6 conexiones.
¿Tu implementación es sin servidor o detrás de infraestructura que no soporta conexiones persistentes? SSE funciona en la mayoría de plataformas sin servidor (Vercel, Cloudflare Workers mediante la API de Streams); los WebSockets en entornos sin servidor requieren un sistema adicional.
¿Tu frecuencia de actualización es de 15 segundos o más? Long polling. Manténlo simple.

Si has revisado estos puntos y la respuesta sigue siendo WebSockets — bien. Ahora los estás utilizando por la razón correcta en lugar de por defecto.

Depuración de cargas de eventos

SSE data: Los campos y los mensajes de WebSocket casi siempre llevan JSON. Cuando estás depurando un flujo que funciona mal, pegar el payload bruto en IO Tools’ JSON Formatter es la forma más rápida de ver la estructura de forma general — especialmente para objetos anidados donde un paréntesis faltante o una coma extra mata la interpretación silenciosamente.