Al servir y almacenar archivos hay una serie de cosas que debemos tener en cuenta para equilibrar la ergonomía, el rendimiento y la eficacia. En esta publicación, dividiré estos procesos en 3 C’s:
🤝 Concatenar: nuestros archivos en el servidor: ¿Vamos a enviar muchos archivos más pequeños o vamos a enviar un archivo monolítico? El primero simplifica el paso de construcción, pero ¿es más rápido?
🗜️ Comprimir a través de la red: ¿Qué algoritmo de compresión, si corresponde, usaremos? ¿Cuál es la disponibilidad, configurabilidad y eficacia de cada uno?
🗳️ Cachear en el otro extremo: ¿Cuánto tiempo debemos almacenar en caché los archivos en el dispositivo de un usuario? ¿Y alguna de nuestras decisiones anteriores dicta nuestras opciones?
Contenido de la página
🤝 Concatenar
La concatenación es probablemente la parte más complicada de hacer bien porque, aunque las tres C se suceden en orden, las decisiones que tomemos más adelante influirán en las que tomemos aquí. Necesitamos pensar en todo ahora mismo.
En el mundo HTTP/1.1, solo podíamos recuperar seis recursos a la vez de un origen determinado. Dada esta limitación, era ventajoso tener menos archivos: si necesitábamos descargar 18 archivos, eran tres partes separadas de trabajo; Si de alguna manera pudiéramos reducir ese número a seis, sería sólo una parte discreta del trabajo. Esto dio lugar a una gran agrupación y concatenación: ¿por qué descargar tres archivos CSS (la mitad de nuestro presupuesto) si podíamos comprimirlos en uno?
Con la introducción de HTTP/2, las cosas cambiaron. En lugar de estar limitados a solo seis solicitudes paralelas a un origen determinado, se nos dio la posibilidad de abrir una conexión que podía reutilizarse infinitamente. De repente, podíamos realizar más de seis solicitudes a la vez, por lo que la agrupación y la concatenación se volvieron mucho menos relevantes. Incluso un antipatrón.
🗜️ Comprimir
- con compresión baja (o nula), muchos archivos más pequeños son más rápidos que uno grande;
- con compresión media, un archivo grande es marginalmente más rápido que muchos archivos más pequeños;
- con una compresión más alta, un archivo grande es notablemente más rápido que muchos archivos más pequeños.
Básicamente, cuanto más agresiva sea tu capacidad para comprimir, mejor te irá con archivos más grandes. Esto se debe a que, en la actualidad, algoritmos como Gzip y Brotli se vuelven más efectivos cuanto más datos históricos tienen. En otras palabras, los archivos más grandes se comprimen más que los más pequeños.
Esto nos muestra el gran poder y la importancia de la compresión, así que asegurémonos de tener la mejor configuración posible. Si actualmente no estás comprimiendo tus recursos de texto, es un error y debes solucionarlo. No optimices a un escenario subóptimo.
🗳️ Caché
El almacenamiento en caché es algo con lo que he estado obsesionado últimamente, pero para los activos estáticos que estamos analizando hoy, no necesitamos saber mucho más que: almacenar en caché todo de la forma más agresiva posible.
Cada uno de sus paquetes requiere una huella digital única, por ejemplo main.agta12.css. Una vez que hayamos hecho esto, el almacenamiento en caché es un caso simple de almacenar el archivo para siempre, de manera inmutable:
Cache-Control: max-age=2147483648, immutable
max-age=2147483648: Esta directiva indica a todos los cachés que almacenen la respuesta durante el máximo tiempo posible. Todos estamos acostumbrados a ver max-age=31536000, que es un año. Esto es perfectamente razonable y práctico para casi cualquier contenido estático, pero si el archivo realmente es inmutable, también podríamos cachearlo para siempre. En el mundo de 32 bits, siempre es 2.147.483.648 segundos, o 68 años.
immutable: Esta directiva indica a los cachés que el contenido del archivo nunca cambiará y, por lo tanto, nunca se molestarán en revalidar el archivo una vez que se max-age se cumpla. Solo puede agregar esta directiva a las respuestas que tengan huellas digitales (p. ej. main.agta12.css)
Todos los activos estáticos, siempre que tengan huellas digitales, pueden llevar de manera segura una cabecera Cache-Control tan agresivo, ya que es muy fácil almacenarlos en caché. Lo que me lleva muy bien a…
La parte importante de esta sección es la prevención de caché.
Hemos visto cómo los archivos muy concatenados se comprimen mejor y, por tanto, se descargan más rápido, pero ¿cómo afecta eso a nuestra estrategia de almacenamiento en caché?
Si bien los paquetes monolíticos pueden ser más rápidos en general para las visitas por primera vez, sufren una gran desventaja: incluso un pequeño cambio de un carácter en el paquete requeriría que un usuario volviera a descargar el archivo completo solo para acceder a un cambio trivial. Imagínese tener que recuperar un archivo CSS de varios cientos de kilobytes nuevamente para cambiar un código hexadecimal:
.btn { - background: #C077EE; + background: #BA0000; }
Este es el riesgo de los paquetes monolíticos: las actualizaciones discretas pueden conllevar mucha redundancia. Esto se agrava aún más si publicamos con mucha frecuencia: si bien almacenar en caché durante 68 años y publicar más de 10 veces al día es perfectamente seguro, genera mucha rotación y no queremos retransmitir los mismos bytes sin cambios una y otra vez.
Por lo tanto, la estrategia de agrupación más efectiva sería optar por la menor cantidad posible de paquetes para aprovechar al máximo la compresión y la programación, pero suficientes paquetes para dividir las partes de código base con una tasa de cambio alta y baja para alcanzar la estrategia de almacenamiento en caché más óptima. Sin duda es un acto de equilibrio.
