When we browse the internet, we rarely stop to think about the amount of data that travels in each request. A modern site can deliver tens of kilobytes of HTML, JavaScript, CSS, and JSON without the user perceiving any delays. Behind that fluidity is a silent process that transforms text files into much lighter packages: HTTP compression. This mechanism, mostly implemented in intermediate layers such as proxy servers, CDNs or load balancers, is responsible for reducing the weight of responses by up to 70%. In this article, we explore how it works, which algorithms dominate the current landscape, how to avoid common mistakes, and why choosing the right configuration can make a significant difference in both user experience and infrastructure costs.
The process begins even before the server sends the first byte. The browser, in its initial request, includes a header called Accept-Encoding, where it states which decompression methods it understands: gzip, brotli, zstd. Think of it like a digital handshake: the client indicates which compression languages it masters, and the server chooses the most suitable one from that list. If there is no match, the response is sent uncompressed. This exchange is automatic and practically invisible to the developer, but it forms the basis of all bandwidth optimization on the web.
Once the request is received by the server, the compression job does not occur within the application code. An endpoint in Express, Django, or NestJS generates its usual response—an HTML string, a JSON object—without knowing that it will be packaged. Compression is applied at an external layer: the reverse proxy (Nginx, Apache), a specific middleware, or, increasingly, a CDN at the edge of the network. This separation of responsibilities allows the development team to focus on business logic, while infrastructure experts adjust compression at strategic points. For example, in a custom application project, this architecture allows scaling without modifying a single line of the backend.
And why does text compress so well? The answer lies in repetition. A typical HTML document repeats tags, attributes, class names, and whitespace over and over again. Lossless compression algorithms, such as LZ77 (base of gzip and brotli), detect these repetitions and replace them with short references. For example, the string '<div class=\'card\'>' that appears multiple times can be stored only once, and each occurrence is replaced by a copy statement. In addition, Huffman encoding assigns shorter codes to the most frequent bytes—such as the character '<' o el espacio— y códigos más largos a los infrecuentes. Esta doble estrategia consigue reducciones de entre un 60% y un 80% en archivos de texto, mientras que formatos ya comprimidos como JPEG, PNG o WebP apenas se benefician, por lo que los servidores inteligentes evitan comprimirlos para no malgastar CPU.
Currently, three algorithms compete in the web ecosystem. Gzip remains the universal standard, supported by absolutely all clients and servers. Brotli, developed by Google, offers slightly better compression (5% to 10% tighter) at the cost of higher CPU consumption, making it ideal for static assets that are compressed once and cached. Meta's Zstandard (zstd) gains ground in dynamic and high-traffic scenarios, as it provides a very favorable compression-to-speed ratio. Most modern setups follow a hierarchy: try brotli first, if the client supports it; if not, gzip; and as a last resort, send uncompressed. This criterion is resolved in milliseconds on each request.
However, compression is not free. Each algorithm has intensity levels (gzip from 1 to 9, brotli from 0 to 11). Going up to the max reduces a few additional bytes but multiplies the CPU time. For dynamic responses that are generated on a per-request basis—for example, a database query API—moderate levels (gzip 6, brotli 4–5) are recommended. For static files that are compiled once and served from the cache, it is worth squeezing the most out of it. This balance between bandwidth savings and computational load is crucial when handling millions of requests per day. A common mistake is to enable compression at multiple layers (e.g. in Express middleware and also in Nginx), which causes double compression, waste of resources, and in the worst case, corrupted responses. The rule of thumb: that only one layer is responsible for compressing.
Another aspect that is often overlooked is the Vary: Accept-Encoding heading. When a CDN caches a compressed response with brotli, a second visitor whose browser only supports gzip would receive that same resource and would not be able to unzip it, displaying junk content. By adding Vary: Accept-Encoding, the CDN knows to store separate versions based on the requested algorithm. It is a configuration line that avoids an intermittent and difficult to diagnose bug. In practice, companies using AWS and Azure cloud services typically delegate this management to load balancers or managed services such as CloudFront or Azure Front Door, which automatically handle these variants.
The economic impact of compression is direct. Let's imagine an API that returns 100 KB of JSON and receives a million requests per day. Without compression, traffic amounts to 100 GB per day. With gzip, it is reduced to about 35 GB, saving 65 GB each day. In bandwidth bills or cloud data transfer, those savings can represent hundreds or thousands of dollars per month on a single endpoint. When multiplied by all the resources of a website – pages, styles, scripts, AJAX calls – optimization is no longer a mere technical detail but a strategic business decision.
In addition, HTTP compression dialogues with other performance layers. For example, when integrating business intelligence services such as Power BI, reports and dashboards that are rendered in the browser often download large volumes of JSON data. Applying compression drastically reduces the load times of those visualizations, improving the analyst experience. Similarly, AI solutions for businesses that process data in real-time benefit from lighter responses, especially when AI agents are constantly consuming APIs. At Q2BSTUDIO, when we develop custom software, we look at compression as an integral part of the architecture design, ensuring that every layer—from the frontend to the database—is optimized to minimize latency and cost.
One security aspect that deserves attention is the BREACH attack (2013). It is based on the fact that if a compressed response contains both a secret (such as a CSRF token) and a value controlled by the attacker (a search term), differences in compressed size can leak information, even over HTTPS. The solution is simple: don't mix user input with sensitive data in the same compressed response. If an endpoint is vulnerable by design, the most prudent thing to do is to disable compression for that particular path. In cybersecurity and pentesting projects we do at Q2BSTUDIO, we review these patterns to ensure that optimization doesn't weaken security.
Finally, it's worth mentioning the mechanism that lets the browser know when you've received the full response. Typically, the server sends the Content-Length header with the size of the compressed body. But when the response is generated in streaming and the final size is not known, Transfer-Encoding: chunked is used, which segments the data and marks the end with a zero-size block. Both methods coexist perfectly with compression, as long as the server clearly indicates which algorithm was used using Content-Encoding.
In short, HTTP compression is one of those invisible technologies that transforms the digital experience. It acts in the background, requires no changes to the application code, and when properly configured, drastically reduces bandwidth, improves load times, and lowers operational costs. For any team developing custom applications or managing cloud infrastructure, mastering these concepts is no longer a technical option but a competitive advantage. At Q2BSTUDIO, we help companies implement these optimizations along with artificial intelligence, cybersecurity, and process automation solutions, ensuring that each layer of the technology stack is aligned with business objectives.
