Transloadit

¿Qué es el almacenamiento en caché de contenido?

El almacenamiento de contenido en caché guarda copias reutilizables de respuestas, metadatos o recursos generados cerca de quienes los consumirán más adelante. Las solicitudes posteriores pueden evitar repetir cálculos o recuperaciones desde el origen.

Cómo funciona el almacenamiento en caché de contenido

Una caché HTTP almacena una respuesta bajo una clave de caché. La clave está formada, como mínimo, por el método y la URL de la solicitud, y puede ampliarse mediante los encabezados de solicitud que la respuesta especifica en Vary o mediante la configuración de la CDN. Mientras una respuesta almacenada está vigente, la caché puede responder con ella sin contactar al origen. Una vez que deja de estar vigente, la caché normalmente consulta al origen antes de volver a usarla, a menos que una directiva o la configuración de la caché permita servir la copia desactualizada. Cuando el origen envió un validador (ETag o Last-Modified), esa comprobación es una solicitud condicional, y una respuesta 304 Not Modified permite que la caché siga usando la copia sin descargar de nuevo el cuerpo. Hay dos tipos de caché que siguen reglas diferentes. Una caché privada, normalmente la del navegador, pertenece a un usuario y puede contener respuestas personalizadas. Una caché compartida se sitúa entre los clientes y el origen y atiende a muchos usuarios; las CDN y los proxies inversos son cachés compartidas administradas por el operador del sitio, que MDN denomina cachés administradas. Cache-Control establece un plazo de validez explícito con max-age y puede tratar los dos tipos por separado: private indica a las cachés compartidas que no almacenen una respuesta, y s-maxage prevalece sobre max-age solo para las cachés compartidas. Una caché administrada añade su propia configuración y operaciones de purga. Una purga elimina la copia en la CDN, pero las copias que ya tienen los navegadores permanecen hasta que vencen. Por eso, los recursos que nunca cambian se publican en URL versionadas con plazos de validez largos, mientras que las URL que deben permanecer estables se revalidan.

Datos clave

  1. ¿no-cache o no-store? no-store indica a todas las cachés, privadas o compartidas, que no conserven la respuesta. no-cache permite almacenar la respuesta, pero prohíbe reutilizarla sin revalidarla primero con el origen. Cuando la respuesta incluye un validador como ETag o Last-Modified y el origen responde a solicitudes condicionales, un recurso que no ha cambiado solo requiere un pequeño intercambio 304 Not Modified en lugar de una descarga completa; sin esas condiciones, reutilizarlo normalmente implica descargar de nuevo la respuesta completa. Ninguna de las dos directivas garantiza la privacidad por sí sola: no-cache sigue permitiendo el almacenamiento, y el RFC 9111 establece que no-store no es un mecanismo fiable ni suficiente para garantizar la privacidad. Una CDN también puede tratar no-cache de forma distinta a lo establecido en el RFC. Cloudflare documenta que, con su función Origin Cache Control deshabilitada, no almacena en caché ninguna respuesta no-cache y que, con la función habilitada, almacena la respuesta en caché y siempre la revalida.
  2. ¿Una respuesta sin Cache-Control queda fuera de la caché? No se puede contar con ello. Cuando no se indica un tiempo de vida explícito, el RFC 9111 permite que una caché lo estime, normalmente como una fracción del tiempo transcurrido desde Last-Modified (el ejemplo del RFC es 10 %), y recomienda que los servidores de origen envíen directivas explícitas si quieren impedir el almacenamiento en caché. Las CDN añaden sus propios valores predeterminados. Cloudflare decide según la extensión del archivo, no según el tipo MIME: almacena en caché una respuesta 200 para una extensión de su lista predeterminada, como JPG, PNG, CSS o JS, durante un período predeterminado, incluso cuando la respuesta no incluye ni Cache-Control ni Expires, y no almacena HTML ni JSON en caché a menos que una regla lo habilite. Ese comportamiento predeterminado depende de la extensión de la URL, y una regla de caché puede ampliarlo a todo el contenido, así que no confíes en él para mantener las páginas personalizadas fuera de la caché. Envía una política explícita en cada respuesta y consulta el comportamiento predeterminado de la CDN antes de confiar en cualquiera de los dos.
  3. ¿Cómo se mantienen las respuestas personalizadas fuera de una caché compartida? Envía Cache-Control: private, que indica a las cachés compartidas, como las CDN, que no almacenen la respuesta, pero permite que el navegador del usuario sí la almacene; para las páginas personalizadas después de iniciar sesión, MDN recomienda Cache-Control: no-cache, private, para que el navegador también revalide la respuesta antes de reutilizarla. HTTP solo protege automáticamente un caso: una caché compartida no debe reutilizar una respuesta a una solicitud que incluía Authorization a menos que la respuesta lo permita mediante public, s-maxage o must-revalidate. Una respuesta personalizada mediante una cookie no recibe esa protección, y MDN señala que una cookie por sí sola no hace que una respuesta sea privada. Una CDN respeta la directiva solo mientras sigue los encabezados del origen: Cloudflare, por ejemplo, documenta que respeta los encabezados de caché del origen a menos que una regla de caché Edge Cache TTL los anule, así que revisa las reglas de la CDN que se aplican a las URL personalizadas. private solo controla dónde se puede almacenar una respuesta; el RFC 9111 indica que no puede garantizar la privacidad del contenido.
  4. ¿Qué debe incluir la clave de caché para las variantes de contenido multimedia? Cada dato de entrada que cambie el resultado, y ningún otro. Cuando la variante depende de un encabezado de la solicitud, por ejemplo, un formato de imagen negociado mediante Accept, la respuesta debe incluir ese encabezado en Vary; según el RFC 9111, una caché puede entonces reutilizar una respuesta almacenada solo para solicitudes cuyos encabezados indicados coincidan. Una CDN no aplica necesariamente esa regla de forma predeterminada: Cloudflare documenta que no tiene en cuenta Vary en sus decisiones de almacenamiento en caché, excepto en el caso de Vary: Accept-Encoding, a menos que se configure el ajuste Vary de las reglas de caché o Vary for images. Confirma que la CDN varíe su caché según el encabezado antes de confiar únicamente en Vary. Cuando la variante depende de parámetros de la URL, como el ancho, el recorte o el formato, esos parámetros deben permanecer en la clave, y los valores predeterminados de las CDN también difieren en este aspecto: la clave de caché predeterminada de Cloudflare incluye la cadena de consulta, mientras que Amazon CloudFront no almacena contenido en caché según los parámetros de la cadena de consulta cuando no está configurado para reenviar las cadenas de consulta al origen. Una clave que omite un dato de entrada entrega a un solicitante la versión derivada de otro. Una clave que incluye más de lo necesario almacena duplicados: CloudFront recomienda almacenar contenido en caché solo según los parámetros para los que el origen devuelve versiones diferentes, y señala que trata las cadenas de consulta con diferencias de mayúsculas y minúsculas o de orden como objetos distintos.

Cuándo es importante el almacenamiento en caché de contenido

Almacena en caché el contenido multimedia y las variantes que se solicitan con frecuencia cuando la menor latencia y la reducción de la carga del origen tengan más peso que los requisitos de actualización del contenido. Las claves o reglas de invalidación incorrectas pueden hacer que se entregue contenido desactualizado, privado o que no corresponda a lo solicitado.

Cómo ayuda Transloadit con el almacenamiento en caché de contenido

Smart CDN de Transloadit almacena en caché el resultado de un Template en el borde de la red. Cuando no encuentra el contenido en la caché, importa el original desde tu almacenamiento y ejecuta la Assembly; las solicitudes posteriores a la misma URL se responden con la copia almacenada en caché, sin volver a ejecutar la Assembly. Los parámetros de transformación forman parte de la URL, por lo que cada combinación se solicita y se almacena en caché como una variante independiente.

La primera solicitud a cada URL nueva incluye el tiempo necesario para obtener y procesar el original. Para las URL firmadas de Smart CDN, el tiempo de vida efectivo de una respuesta en la caché está limitado por el tiempo de validez restante de la firma, por lo que un plazo de expiración corto también reduce el tiempo durante el que se reutiliza un resultado.

Explora las capacidades de entrega de Transloadit

Fuentes

Convierte tus conocimientos sobre multimedia en un pipeline funcional

Conecta las subidas, el procesamiento, la IA, el almacenamiento y la entrega mediante una sola API declarativa, mientras nos encargamos por ti del stack de encoding, el escalado y los cambios constantes de formatos.

Prueba Transloadit gratis