En el desarrollo web es muy importante los tiempos de carga y respuesta, ya sea de una página web, un sistema o aplicación web, ya sea de escritorio o aplicaciones progresivas que suelen estar orientadas a dispositivos móviles. En muchos sectores, como el comercio electrónico, se piensa que tiempos altos de carga afectan negativamente en la conversión y, por ende, en las cifras de venta.

Existen muchas técnicas en el desarrollo web para mejorar los tiempos de carga que se han hecho comunes, como el minimizado y optimización de archivos CSS, JS. Este tipo de técnicas ya son bastante conocidas y existen plugins, tools e incluso IDEs que ya incluyen funcionalidades para lograr esto por defecto. Incluso muchos frameworks como React, Angular y otros ya hacen esto como parte de sus procesos de empaquetado.

Otra técnica usada es implementar CDN, técnica que consiste en cachear el contenido estático (JS, CSS, imágenes, etc.) en servidores o nodos más cercanos a la ubicación del usuario real. Esto permite tiempos de transferencia menores, por lo tanto, mejora la experiencia del usuario.

Si nos damos cuenta, todas estas prácticas están relacionadas con el frontend de la aplicación, pero, ¿qué pasa con el backend? Por el lado del backend existe una práctica que, en la actualidad, pasa muy desapercibida. Esta técnica es la habilitación de compresión de respuestas. Esta técnica consiste en que el servidor que soporta nuestro backend comprima nuestras respuestas de texto con el fin de que las transferencias sean más livianas y, por ende, más rápidas. La razón por la que esta técnica es desapercibida es porque, en la actualidad, las redes han logrado ser muy rápidas en los hogares y en las estaciones de trabajo, pero en escenarios rurales y móviles esto aún es una realidad. Existen millones de usuarios que aún usan móviles y dispositivos que usan redes 4G, 4G lentas e incluso 3G. Aquí es donde la habilitación de compresión de respuestas tiene un aporte real.

En este artículo voy a centrarme en un escenario de implementación moderno, por ejemplo, un cliente de navegador hecho con React.js o cualquiera de sus frameworks, Angular, Vue, e incluso un cliente móvil como una app React Native, Android o iOS, y una API Backend con C# .NET 9. En este ejemplo estaré habilitando la compresión de respuesta de texto en la API, por lo tanto, las respuestas que se estarán comprimiendo serán respuestas application/json. Habilitar response compression en .NET consiste en agregar la librería Microsoft.AspNetCore.ResponseCompression al proyecto e implementar algo como las siguientes líneas en el Program.cs, tal como la siguiente imagen:

De esta manerá nuestra API .NET estará devolviendo las respuestas JSON comprimidas con el header response content-encoding=gzip.

Para finalizar este artículo dejo algunas consideraciones sobre Response Compression y sobre el código de ejemplo:

• En el ejemplo se usa Gzip y Brotli como algoritmos de compresión, esto quiere decir que, dependiendo del valor que envíen los clientes en el header Accept-Encoding, el servidor utilizará el algoritmo respectivo. Por ejemplo, los navegadores modernos basados en Chromium están preparados para enviar “gzip, deflate, br, zstd”. Muchas librerías móviles de Android y iOS ya están preparadas para enviar estos encabezados. Incluso Postman ya lo envía por defecto, pero si tu servidor no está habilitado para hacer compresión, simplemente este header se ignora.
• Gzip es uno de los formatos de compresión más usados. Como se comenta anteriormente, los navegadores ya lo envían por defecto y, si tu servidor está preparado, devolverá la respuesta con el header “content-encoding=gzip”. Al recibir esto, el navegador sabe que recibió una respuesta comprimida y debe descomprimirla antes de que la puedas usar.
• La compresión tiene su valor para respuestas “grandes”, por ejemplo, desde 10 KB para arriba comprimir las respuestas puede mejorar la velocidad de transferencia de forma muy positiva, sobre todo, como ya se había dicho, para redes lentas tipo 4G lento y 3G.
• Comprimir las responses tiene sus matices y contrapesos de los que debes ser consciente. El solo hecho de comprimir requiere poder de cómputo (CPU) y memoria (RAM) adicional, ya sea por el lado del servidor al comprimir y por el lado del cliente al descomprimir. Este uso adicional de CPU y memoria se puede considerar insignificante, pero para respuestas pequeñas de menos de 10 KB puede que no valga la pena comprimir, ya que la velocidad de transferencia también es insignificante.
• En una implementación real puedes aplicar compresión solo a los endpoints que sabes van a devolver respuestas “grandes”, pero, obviamente, esto depende de cada caso de uso y uno debe evaluar y ser consciente de los datos que está devolviendo.
• Si puedes ver en las líneas de código 17 y 22, se especifica un “CompressionLevel”. Los valores más comunes son Optimal y Fastest. Optimal logra producir respuestas más pequeñas, pero Fastest consigue buena compresión por menos tiempo de procesamiento. Cuál elegir depende de tu caso de uso, pero yo recomendaría el nivel Fastest para la web.
• Comprimir no tiene mucho sentido entre llamados de APIs internas, es decir, que estén dentro de la misma red, ya que aquí la latencia es casi nula y solo estaría generando uso de CPU adicional

Ahora dejo ua tabla para que puedas imaginarte las ganancias y matices de la compresión con Gzip y Brotli.

Como no hay mejor aprendizaje que poniendo en práctica, te dejo el enlace a un repositorio 100% Open Source que elaboré de ejemplo para C# y .NET tal cual la imagen anterior.

Repositorio Gzip con dotnet :)

Conclusiones

1. El response compression es una buena técnica que puedes aplicar en la búsqueda de mejor performance, ya sea de tu web o tus APIs públicas, sobre todo apuntando a los usuarios que trabajan con redes lentas.
2. Debes evaluar tu caso de uso real para habilitar response compression. Como ya se comentó, no suele tener un impacto significativo en redes internas, ni para llamados entre servicios en una misma red.

---

Sígueme en Linkedin para estar al tanto de mis publicaciones y novedades

Referencias

• Response compression in ASP.NET Core