Compresión WebSocket más rápida

· Características

La compresión WebSocket es esencial para reducir el ancho de banda y mejorar la capacidad de respuesta, especialmente al transmitir datos repetitivos como payloads JSON. La extensión permessage-deflate comprime cada frame WebSocket al vuelo — pero la velocidad de esa compresión impacta directamente en el throughput de tu aplicación.

A partir de sgcWebSockets 2026.4.0 se ha reescrito por completo la implementación de permessage-deflate para conseguir un rendimiento significativamente más rápido. En nuestros benchmarks, los mensajes pequeños comprimen y descomprimen hasta 15 veces más rápido, con ganancias medibles en todos los tamaños de payload.

¿Qué ha cambiado?

La implementación anterior inicializaba y destruía el motor de compresión en cada frame WebSocket. Esto significaba que incluso un mensaje minúsculo de 1 KB pagaba el coste completo de inicializar el compresor, comprimir los datos y luego destruirlo todo — sólo para repetir el proceso entero con el siguiente mensaje.

La nueva implementación mantiene vivo el motor de compresión entre frames. Se inicializa una vez al llegar el primer frame y se reutiliza durante toda la vida de la conexión. Esto elimina el overhead de inicialización por frame y, además, permite que el motor aprenda de los mensajes anteriores, comprimiendo más rápido los patrones de datos repetitivos.

Además del contexto de compresión persistente, la nueva implementación incluye otras optimizaciones:

Resultados de los benchmarks

Hemos ejecutado 10.000 round-trips de compresión + descompresión para cada tamaño de mensaje. En cada round-trip se comprime un payload JSON y se vuelve a descomprimir, verificando que la salida coincide con el original. La prueba se realizó en una máquina Windows de 64 bits compilada con Delphi 12 Athens.

Configuración por defecto (contexto persistente)

Es el modo por defecto en el que el contexto de compresión se mantiene entre frames — el escenario más habitual en el mundo real:

Tamaño del mensaje Anterior (ms) Nueva (ms) Mejora
1 KB 437 ms 28 ms 15,6x más rápido
4 KB 480 ms 88 ms 5,5x más rápido
16 KB 546 ms 431 ms 1,3x más rápido
64 KB 1,994 ms 1,725 ms 1,2x más rápido

Con NoContextTakeOver (frames independientes)

Cuando NoContextTakeOver está habilitado, cada frame se comprime de forma independiente. Incluso en este modo, las optimizaciones de reutilización de buffers y acceso directo a memoria aportan una mejora sólida:

Tamaño del mensaje Anterior (ms) Nueva (ms) Mejora
1 KB 149 ms 75 ms 2,0x más rápido
4 KB 173 ms 100 ms 1,7x más rápido
16 KB 302 ms 228 ms 1,3x más rápido
64 KB 1,216 ms 1,094 ms 1,1x más rápido

¿Quién se beneficia más?

La mejora es más espectacular en aplicaciones que intercambian muchos mensajes pequeños — que es precisamente el caso típico de uso de WebSocket:

Chat y mensajería
Los mensajes de texto cortos (normalmente por debajo de 4 KB) son los que más ganan: compresión 5–15 veces más rápida.
Feeds de datos en tiempo real
Las actualizaciones JSON para dashboards, tickers de bolsa y sensores IoT se benefician tanto de la velocidad como del aprendizaje de patrones repetitivos por el contexto persistente.
Juegos y multijugador
Las pequeñas actualizaciones de estado frecuentes se benefician del bajo overhead por frame.
Servidores de alta concurrencia
Menos tiempo de CPU por frame significa que el servidor puede manejar más conexiones simultáneas.

Totalmente compatible

La optimización es totalmente transparente — no hay que cambiar nada en tu aplicación. Los datos comprimidos sobre el cable son idénticos a los de la versión anterior, así que los servidores actualizados funcionan sin problemas con los clientes existentes y viceversa.

La nueva implementación admite todas las plataformas y compiladores:

Actualízate a 2026.4.0

La optimización de permessage-deflate está disponible en sgcWebSockets 2026.4.0. Simplemente actualiza a la última versión y tus conexiones WebSocket se beneficiarán automáticamente de una compresión más rápida. Descárgalo en esegece.com.

Un agradecimiento especial a Michael por aportar la implementación optimizada inicial que inspiró este trabajo. Su investigación sobre contextos zlib persistentes y acceso directo a memoria sentó las bases de estas mejoras de rendimiento.