Comprimir y cachear: Brotli, Gzip, HTTP y CDN

Gzip usa el algoritmo DEFLATE, que busca fragmentos repetidos y los sustituye por referencias más cortas. Los formatos de texto de la web (HTML, CSS, JavaScript, JSON, SVG) están llenos de repeticiones, así que encogen muchísimo.

Lo entiende cualquier cliente HTTP, tiene niveles del 1 al 9 y comprime rápido incluso en los niveles medios, así que puedes usarlo para comprimir cada respuesta al vuelo, también las que genera tu API.

Brotli, creado por Google, consigue archivos de texto algo más pequeños que Gzip, en parte gracias a un diccionario incorporado con palabras y fragmentos muy comunes en la web. Todos los navegadores modernos lo soportan, aunque solo lo anuncian en conexiones HTTPS.

Tiene niveles del 0 al 11, y los más altos son lentos. Por eso la estrategia habitual es doble: precomprimir los archivos estáticos al máximo durante la build y servir el .br ya hecho, y usar un nivel medio para las respuestas dinámicas.

Empieza a aparecer un tercer candidato, Zstandard (zstd), creado en Meta, que algunos navegadores y CDN recientes ya aceptan. Comprueba el soporte antes de contar con él.

Con max-age=N, la respuesta está fresca durante N segundos: mientras lo esté, el navegador la reutiliza sin hacer ninguna petición. Cuando caduca, pasa a estar obsoleta y tiene que comprobar si sigue valiendo.

Dos directivas se confunden constantemente. no-cache no significa «no guardar»: significa «guárdala, pero pregunta al servidor antes de cada uso». La que prohíbe guardar es no-store, pensada para datos sensibles. Además, private permite guardarla solo al navegador del usuario, nunca a una caché compartida, e immutable le dice al navegador que, mientras esté fresca, no la revalide ni siquiera si el usuario recarga la página.

Que una copia haya caducado no significa que esté desactualizada. El ETag es un identificador de la versión de una respuesta, a menudo un hash de su contenido. Cuando la copia caduca, el navegador pregunta con If-None-Match y ese valor; si nada ha cambiado, el servidor responde 304 Not Modified, sin cuerpo, y el navegador reutiliza su copia.

Si sí ha cambiado, responde 200 con la versión nueva y su nuevo ETag. La alternativa más antigua es por fechas, con Last-Modified e If-Modified-Since.

El dilema es este: con un max-age largo, las visitas repetidas vuelan, pero los usuarios no verán tus cambios; con uno corto, verán los cambios, pero todo irá más lento. La solución es poner en el nombre del archivo un hash de su contenido: main-7KQ2XG3B.js.

Si cambias una sola línea, la build genera otro nombre, y el archivo viejo simplemente no se vuelve a pedir. Esos archivos pueden llevar max-age de un año e immutable. Lo que no puede cachearse tanto es el HTML que los enlaza, que se sirve con no-cache para que siempre apunte a los nombres nuevos. Vite, webpack y el CLI de Angular lo hacen solos en las builds de producción.

s-maxage fija la vida de la respuesta solo en las cachés compartidas, como la CDN, y allí manda sobre max-age. Así puedes hacer que la CDN guarde el HTML una hora mientras los navegadores lo revalidan siempre: las revalidaciones las contesta la CDN y tu servidor descansa.

Cuando algo cambia antes de caducar, lo purgas: lo borras de la CDN por URL, por etiqueta o entero, y la siguiente petición va al origen. Y Vary indica qué cabeceras de la petición cambian la respuesta, para que la CDN guarde una versión por cada valor: Vary: Accept-Encoding guarda una copia con Brotli y otra con Gzip.

Cuando una copia caduca, el siguiente usuario normalmente espera a que la caché consulte al origen. Con stale-while-revalidate=N, durante N segundos después de caducar, la caché sirve la copia vieja al instante y, a la vez, pide la nueva en segundo plano. Ese usuario no espera, y el siguiente ya recibe la versión fresca.

Muchas CDN lo soportan, y algunos navegadores lo aplican también en su propia caché. Su hermano, stale-if-error, permite servir la copia vieja si el origen falla.