¿Qué es el contenido estático?

El contenido estático se sirve a partir de una representación almacenada que normalmente permanece idéntica entre solicitudes. Solo cambia cuando se actualiza el recurso subyacente, en lugar de generarse para cada solicitud.

El contenido estático es una propiedad de la entrega: el servidor puede devolver bytes que ya existen, como un archivo en disco o un objeto en un bucket, sin ejecutar lógica de la aplicación para la solicitud. El archivo puede haberse escrito a mano, haberse generado durante una compilación o haberse exportado mediante un pipeline multimedia, por lo que «estático» no significa que nunca cambie. Significa que el contenido cambia cuando se reemplaza el archivo almacenado, no cuando llega una solicitud. Por eso, dos mecanismos HTTP hacen la mayor parte del trabajo. La frescura, establecida con Cache-Control, indica a los navegadores y las CDN cuánto tiempo pueden reutilizar una copia sin consultar. Los validadores, un ETag o una fecha Last-Modified, permiten que una caché consulte si su copia sigue vigente y reciba una respuesta 304 sin cuerpo cuando así sea. Las imágenes, los segmentos de video, las fuentes, las hojas de estilo, los scripts y las páginas HTML pregeneradas son contenido estático típico; una respuesta construida para cada solicitud a partir del estado de la aplicación es contenido dinámico.

¿Un archivo estático se almacena en caché automáticamente? No de forma fiable ni durante un plazo predecible. Sin una frescura explícita indicada por Cache-Control o Expires, HTTP permite que una caché aplique frescura heurística: el RFC 9111 permite estimar un plazo de validez a partir de Last-Modified y propone el 10 % del tiempo transcurrido desde la última modificación como ajuste típico. Por ese motivo, MDN recomienda un encabezado Cache-Control explícito en cada respuesta. Las CDN añaden sus propios valores predeterminados. Cloudflare, por ejemplo, almacena en caché según la extensión del archivo y no según el tipo MIME, no almacena HTML ni JSON en caché de forma predeterminada y no almacena en caché una respuesta que incluya Set-Cookie.
¿Un archivo estático debería conservar su URL cuando cambia su contenido? Decide para cada archivo. Un archivo cuya URL cambia con su contenido, como un paquete con un hash en el nombre, puede servirse con un max-age prolongado (el ejemplo de MDN usa un año) junto con immutable, porque una nueva versión llega con una nueva URL. Un archivo que debe conservar su URL, como una página HTML, no debería tener un plazo de validez prolongado: actualizar el archivo en el servidor no reemplaza una copia fresca que un navegador ya haya almacenado, porque, como señala MDN, las solicitudes de ese archivo ya no llegan al servidor, de modo que el navegador puede seguir usando esa copia hasta que venza su plazo de validez. Una CDN que ofrezca purga puede eliminar su propia copia, pero la purga no alcanza las copias ya almacenadas en los navegadores. Sirve esos archivos con no-cache y validadores para que se compruebe cada reutilización y un archivo sin cambios solo requiera un 304.
¿Servir una respuesta desde un archivo hace que sea segura para una caché compartida? No. La posibilidad de almacenarla en caché depende de la solicitud y de los encabezados de respuesta, no de cómo se produjo el cuerpo. El RFC 9111 prohíbe que una caché compartida reutilice una respuesta a una solicitud que incluía Authorization, salvo que la respuesta lo permita con public, s-maxage o must-revalidate. No establece esa regla para una solicitud que incluía un encabezado Cookie, y MDN señala que una cookie por sí sola no hace que una respuesta sea privada. El RFC también indica que Set-Cookie no impide el almacenamiento en caché, por lo que una caché que siga el estándar puede almacenar un archivo estático enviado con una cookie y reutilizarlo para solicitudes posteriores. Una CDN puede aplicar su propia regla: Cloudflare, como se indicó antes, no almacena en caché esa respuesta de forma predeterminada. Es preferible no establecer cookies en rutas estáticas. Cuando una respuesta deba incluir una, o esté personalizada mediante una cookie, márcala como private: una caché compartida, como una CDN, no debe almacenarla en ese caso, de modo que ese archivo se almacene en caché solo en los navegadores.
¿Qué cambia cuando los archivos se comprimen de antemano? Los archivos comprimidos y sin comprimir son dos representaciones bajo una misma URL, por lo que las respuestas necesitan Vary: Accept-Encoding, y el RFC 9110 establece que un ETag fuerte para una representación con codificación de contenido debe ser distinto del de la representación sin codificar, para evitar conflictos durante las actualizaciones de caché y las solicitudes de rangos. Los servidores difieren en cuánto de esto hacen por ti. El gzip_static de nginx envía un archivo .gz existente en lugar del archivo normal, pero solo añade Vary: Accept-Encoding cuando gzip_vary está activado, lo que no ocurre de forma predeterminada. Ninguna de las dos páginas de los módulos de nginx explica cómo se forma el ETag de una respuesta .gz, así que solicita un archivo con y sin Accept-Encoding: gzip, confirma mediante Content-Encoding que solo la primera respuesta está comprimida y compara los encabezados Vary y ETag de ambas respuestas. Repite la comprobación a través de la CDN: gzip_static también tiene en cuenta gzip_proxied, y su valor predeterminado, off, desactiva la compresión para las solicitudes que incluyen un encabezado Via, por lo que una solicitud reenviada por una CDN puede recibir el archivo sin comprimir. El mod_deflate de Apache, que comprime sobre la marcha, añade el método de compresión al ETag de forma predeterminada, y su documentación indica que esto impide las respuestas 304 a solicitudes condicionales de contenido comprimido.

Aplica plazos de validez de caché prolongados cuando cada revisión del contenido tenga una URL única, para reducir la latencia y la carga en el origen. Un almacenamiento en caché más breve o la revalidación son opciones más seguras cuando una URL estable puede recibir actualizaciones.

Los archivos que una Assembly exporta con un Robot de almacenamiento son contenido estático a partir de ese momento: permanecen en tu bucket bajo la ruta que elegiste, y tu almacenamiento o CDN los sirve. El Robot /s3/store recibe un objeto headers que se establece en el archivo almacenado, y /video/adaptive asigna un relative_path a cada segmento y lista de reproducción para que la estructura almacenada coincida con las referencias de las listas de reproducción. Smart CDN es la contraparte bajo demanda: un resultado se genera cuando se solicita por primera vez y luego se almacena en caché, y el Robot /file/serve establece el encabezado Cache-Control que reciben los navegadores y la CDN, con cache_duration para cambiarlo.

Un reproductor del navegador que carga archivos HLS o MPEG-DASH desde un origen distinto al de la página, como el nombre de host de un bucket o una CDN, necesita encabezados CORS en el servidor que sirve los archivos; la página /video/adaptive los enumera. Una vez almacenados los archivos exportados, sus encabezados de caché son responsabilidad de tu almacenamiento o CDN.

Explora las capacidades de entrega de Transloadit

¿Qué es el contenido estático?

Cómo funciona el contenido estático

Datos clave

Cuándo importa el contenido estático

Cómo ayuda Transloadit con el contenido estático

Fuentes

Convierte tus conocimientos sobre multimedia en un pipeline funcional