Quan naveguem per internet, rara vegada ens detenim a pensar en la quantitat de dades que viatgen en cada sol·licitud. Un lloc modern pot entregar desenes de quilobytes d'HTML, JavaScript, CSS i JSON sense que l'usuari percebi demores. Darrere d'aquesta fluïdesa hi ha un procés silenciós que transforma arxius de text en paquets molt més lleugers: la compressió HTTP. Aquest mecanisme, implementat majoritàriament en capes intermèdies com servidors proxy, CDN o balancejadors de càrrega, és responsable de reduir fins a un 70% el pes de les respostes. En aquest article explorem com funciona, quins algoritmes dominen el panorama actual, com evitar errors comuns i per què triar la configuració adequada pot marcar una diferència significativa tant en l'experiència de l'usuari com en els costos d'infraestructura.
El procés comença fins i tot abans que el servidor enviï el primer byte. El navegador, en la seva petició inicial, inclou un encapçalat anomenat Accept-Encoding, on declara quins mètodes de descompressió entén: gzip, brotli, zstd. Pensa en això com un apretó de mans digital: el client indica quins idiomes de compressió domina, i el servidor tria el més adequat d'aquesta llista. Si no hi hagués coincidència, s' envia la resposta sense comprimir. Aquest intercanvi és automàtic i pràcticament invisible per a qui desenvolupa, però constitueix la base de tota l' optimització d' ample de banda a la web.
Un cop el servidor rep la petició, el treball de compressió no passa dins del codi de l' aplicació. Un endpoint a Express, Django o NestJS genera la seva resposta habitual —una cadena HTML, un objecte JSON— sense saber que serà empaquetada. La compressió s'aplica en una capa externa: el proxy invers (Nginx, Apache), un middleware específic o, cada vegada més, una CDN a la vora de la xarxa. Aquesta separació de responsabilitats permet que l' equip de desenvolupament es concentri en la lògica de negoci, mentre que els experts en infraestructura ajusten la compressió en els punts estratègics. Per exemple, en un projecte d'aplicacions a mida, aquesta arquitectura permet escalar sense modificar una sola línia del backend.
I per què el text es comprimeix tan bé? La resposta està en la repetició. Un document HTML típic repeteix etiquetes, atributs, noms de classe i espais en blanc una i altra vegada. Els algoritmes de compressió sense pèrdua, com LZ77 (base de gzip i brotli), detecten aquestes repeticions i les reemplacen per referències curtes. Per exemple, la cadena '<div class=\'card\'>' que apareix diverses vegades es pot emmagatzemar una sola vegada, i cada repetició se substitueix per una instrucció de còpia. A més, la codificació Huffman assigna codis més curts als bytes més freqüents —com el caràcter '<' 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.
Actualment, tres algoritmes competeixen en l'ecosistema web. Gzip continua sent l'estàndard universal, suportat per absolutament tots els clients i servidors. Brotli, desenvolupat per Google, ofereix una compressió lleugerament millor (entre 5% i 10% més ajustada) a costa d'un major consum de CPU, per la qual cosa resulta idoni per a actius estàtics que es comprimeixen una vegada i es catxen. Zstandard (zstd) de Meta guanya terreny en escenaris dinàmics i d'alt trànsit, ja que proporciona una relació compressió/velocitat molt favorable. La majoria de les configuracions modernes segueixen una jerarquia: intentar brotli primer, si el client el suporta; si no, gzip; i com a últim recurs, enviar sense comprimir. Aquest criteri es resol en mil·lisegons en cada petició.
Tanmateix, la compressió no és gratuïta. Cada algoritme té nivells d'intensitat (gzip d'1 a 9, brotli de 0 a 11). Pujar al màxim redueix uns pocs bytes addicionals però multiplica el temps de CPU. Per a respostes dinàmiques que es generen en cada sol·licitud —per exemple, una API de consulta a base de dades— convé usar nivells moderats (gzip 6, brotli 4–5). Per a fitxers estàtics que es compilen una vegada i se serveixen des de caixet, sí que mereix la pena exprimir al màxim. Aquest equilibri entre estalvi d' ample de banda i càrrega computacional és crucial quan es manegen milions de peticions al dia. Un error habitual és activar la compressió en múltiples capes (per exemple, en el middleware d'Express i també en Nginx), cosa que provoca doble compressió, rebuig de recursos i, en el pitjor cas, respostes corruptes. La regla d' or: que només una capa sigui responsable de comprimir.
Un altre aspecte que sovint es passa per alt és l'encapçalat Vary: Accept-Encoding. Quan una CDN emmagatzema en caixet una resposta comprimida amb brotli, un segon visitant el navegador del qual només suporta aquest mateix recurs i no podria descomprimir-lo, mostrant contingut escombraries. En afegir Vary: Accept-Encoding, la CDN sap que ha d'emmagatzemar versions separades segons l'algoritme sol·licitat. És una línia de configuració que evita un bug intermitent i difícil de diagnosticar. A la pràctica, les empreses que utilitzen serveis cloud AWS i Azure solen delegar aquesta gestió en els balancejadors de càrrega o en serveis gestionats com CloudFront o Azure Front Door, que manegen automàticament aquestes variants.
L' impacte econòmic de la compressió és directe. Imaginem una API que retorna 100 KB de JSON i rep un milió de peticions al dia. Sense compressió, el trànsit ascendeix a 100 GB diaris. Amb gzip, es redueix a uns 35 GB, estalviant 65 GB cada dia. En factures d'ample de banda o transferència de dades al núvol, aquest estalvi pot representar cents o milers de dòlars mensuals en un sol endpoint. Quan es multiplica per tots els recursos d'un lloc web —pàgines, estils, scripts, anomenades AJAX— l'optimització deixa de ser un mer detall tècnic per convertir-se en una decisió estratègica de negoci.
A més, la compressió HTTP dialoga amb altres capes de rendiment. Per exemple, en integrar serveis intel·ligència de negoci com Power BI, els informes i dashboards que es renderitzen al navegador solen descarregar grans volums de dades JSON. Aplicar compressió redueix dràsticament els temps de càrrega d'aquestes visualitzacions, millorant l'experiència de l'analista. De la mateixa manera, les solucions d'IA per a empreses que processen dades en temps real es beneficien de respostes més lleugeres, especialment quan intervenen agents IA que consumeixen APIs constantment. En Q2BSTUDIO, quan desenvolupem programari a mida, contemplem la compressió com a part integral del disseny de l'arquitectura, assegurant que cada capa —des del frontend fins a la base de dades— estigui optimitzada per minimitzar latència i costos.
Un aspecte de seguretat que mereix atenció és l'atac BREACH (2013). Es basa en el fet que, si una resposta comprimida conté tant un secret (com un token CSRF) com un valor controlat per l'atacant (un terme de recerca), les diferències en la mida comprimida poden filtrar informació, fins i tot sobre HTTPS. La solució és senzilla: no barrejar entrades de l'usuari amb dades sensibles en la mateixa resposta comprimida. Si un endpoint és vulnerable per disseny, el més prudent és desactivar la compressió per a aquesta ruta concreta. En projectes de ciberseguretat i pentesting que realitzem en Q2BSTUDIO, revisem aquests patrons per garantir que l'optimització no debiliti la seguretat.
Finalment, val la pena esmentar el mecanisme que permet al navegador saber quan ha rebut la resposta completa. Normalment, el servidor envia l'encapçalat Content-Length amb la mida del cos comprimit. Però quan la resposta es genera en streaming i no es coneix la mida final, s'utilitza Transfer-Encoding: chunked, que segmenta les dades i marca el final amb un bloc de mida zero. Ambdós mètodes conviuen perfectament amb la compressió, sempre que el servidor indiqui clarament quin algoritme es va utilitzar mitjançant Content-Encoding.
En resum, la compressió HTTP és una d'aquestes tecnologies invisibles que transforma l'experiència digital. Actua en segon pla, no requereix canvis en el codi de l' aplicació i, ben configurada, redueix dràsticament l' ample de banda, millora els temps de càrrega i disminueix els costos operatius. Per a qualsevol equip que desenvolupi aplicacions a mida o gestioni infraestructura al núvol, dominar aquests conceptes deixa de ser una opció tècnica per convertir-se en un avantatge competitiu. En Q2BSTUDIO, ajudem empreses a implementar aquestes optimitzacions juntament amb solucions d'intel·ligència artificial, ciberseguretat i automatització de processos, assegurant que cada capa de l'stack tecnològic estigui alineada amb els objectius de negoci.
