Cache-Control — qué es, directivas y gestión del almacenamiento en caché

¿Qué es Cache-Control?

Cache-Control es un encabezado HTTP, estandarizado en HTTP/1.1 (RFC 7234), que permite al servidor especificar cómo y durante cuánto tiempo los clientes, proxies y CDN pueden almacenar en caché la respuesta. A diferencia de Expires (HTTP/1.0), Cache-Control utiliza directivas — comandos de texto combinados con comas: Cache-Control: public, max-age=3600, must-revalidate. El encabezado proporciona un control detallado sobre cada eslabón de la cadena de caché.

El almacenamiento en caché es uno de los mecanismos fundamentales del rendimiento de aplicaciones web y móviles. Sin él, cada solicitud del usuario iría directamente al servidor, provocando una carga excesiva y latencia. Cache-Control define tres niveles de caché: navegador/aplicación (caché privada), servidores proxy (caché compartida) y CDN (caché distribuida). Cada nivel interpreta las directivas de manera diferente.

La configuración incorrecta de Cache-Control es una de las causas más comunes de problemas de rendimiento. Un almacenamiento en caché demasiado agresivo hace que los usuarios vean datos desactualizados. Un almacenamiento en caché demasiado débil provoca solicitudes excesivas al servidor y una carga lenta. Según Akamai (2025), optimizar Cache-Control para contenido estático reduce la carga del servidor en un 70-90% y mejora el tiempo de carga en un 40-60% para usuarios móviles.

Historia del encabezado

Cache-Control apareció en HTTP/1.1 (RFC 2616, 1999) como reemplazo de Expires. Expires tenía un problema fundamental: usaba una fecha absoluta que dependía de las zonas horarias del servidor y el cliente. Cache-Control resolvió este problema al cambiar a tiempo relativo (max-age en segundos desde el momento en que se recibe la respuesta). Más tarde, en RFC 7234 (2014), se agregaron nuevas directivas: immutable para activos estáticos, stale-while-revalidate y stale-if-error para validación diferida.

Directivas de Cache-Control

Cache-Control incluye más de 10 directivas divididas en tres grupos: directivas de solicitud (cliente → servidor), directivas de respuesta (servidor → cliente) y extensiones. En la práctica, el desarrollo móvil utiliza 6-7 directivas de respuesta principales que cubren el 95% de los escenarios de caché. Veamos cada una con ejemplos y recomendaciones.

max-age es la directiva más importante. Prohíbe al cliente realizar una solicitud al servidor durante el tiempo especificado. Para activos estáticos (CSS, JS, imágenes), max-age generalmente se establece de 1 día a 1 año. Para respuestas de API — de 0 segundos (datos siempre frescos) a 5-10 minutos (datos de referencia). s-maxage permite establecer diferentes tiempos de vida para CDN y navegador: la CDN almacena una copia durante 1 día, el navegador durante 1 hora.

no-cache vs no-store

Estas dos directivas a menudo se confunden. no-cache no prohíbe el almacenamiento en caché — requiere validar la copia almacenada en caché en cada uso mediante una solicitud condicional (If-Modified-Since o If-None-Match). Si el servidor responde con 304 — el cliente usa la caché. Si 200 — la actualiza. no-store, por otro lado, prohíbe completamente guardar la respuesta en cualquier caché, incluido el disco y la memoria. Use no-store solo para datos sensibles — tokens, datos de pago, documentos personales.

Cache-Control vs Expires

El encabezado Expires (HTTP/1.0) también especifica el tiempo de vida del recurso pero usa una fecha absoluta: Expires: Thu, 03 Jul 2026 12:00:00 GMT. Cache-Control max-age usa tiempo relativo desde el momento de la respuesta. La diferencia es crítica para sistemas distribuidos: si el servidor y el cliente están en diferentes zonas horarias, Expires puede interpretarse incorrectamente. Cache-Control no tiene este problema — 3600 segundos siempre son 3600 segundos.

Cuando ambos encabezados están presentes, Cache-Control tiene prioridad sobre Expires. Esto está definido en RFC 7234: “Si una respuesta incluye un campo Cache-Control con la directiva max-age, el destinatario DEBE ignorar el campo Expires.” En la práctica, se recomienda no devolver Expires en absoluto para clientes modernos, ya que Cache-Control cubre todos los escenarios de Expires. Sin embargo, para compatibilidad con proxies y navegadores antiguos, se pueden devolver ambos encabezados.

Expires ha sobrevivido principalmente para contenido estático en Nginx y Apache — estos servidores agregan automáticamente ambos encabezados. Si su proyecto encuentra Expires sin Cache-Control, reemplácelo por Cache-Control con max-age: la precisión del control de caché mejora y se elimina la dependencia de la zona horaria. Para la migración, basta con configurar el servidor para que agregue Cache-Control en lugar de Expires.

# Nginx: Cache-Control para archivos estáticos
location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
    expires 30d;
    add_header Cache-Control "public, immutable, max-age=2592000";
}

# Diferentes políticas para diferentes tipos de contenido
location /api/config {
    expires -1;
    add_header Cache-Control "no-cache, must-revalidate";
}

location /api/static-data {
    expires 5m;
    add_header Cache-Control "public, max-age=300";
}

En la configuración de Nginx, los archivos estáticos (CSS, JS, imágenes) se configuran con Cache-Control durante 30 días con el atributo immutable — este atributo le indica al navegador que el recurso nunca cambia en esta URL (versionado mediante hash en el nombre del archivo). Los endpoints de API usan no-cache para datos dinámicos y public con un max-age corto para datos de referencia — listas solicitadas con frecuencia y que raramente cambian.

Caché en aplicaciones móviles

En las aplicaciones móviles, Cache-Control juega un papel especial debido a las limitaciones de las redes móviles: alta latencia, conexión inestable, límites de tráfico. Un almacenamiento en caché adecuado permite mostrar los datos al usuario al instante, incluso sin conexión, y actualizarlos en segundo plano. OkHttp en Android y URLSession en iOS tienen sistemas de caché integrados que respetan Cache-Control.

OkHttp usa CacheInterceptor, que lee Cache-Control de la respuesta y gestiona automáticamente el almacenamiento en caché. Si el servidor devolvió Cache-Control: max-age=3600, OkHttp no realizará una solicitud al servidor durante una hora. Después de que expire max-age, OkHttp envía una solicitud condicional con If-Modified-Since e If-None-Match. Configuración de caché en OkHttp: OkHttpClient.Builder().cache(Cache(directory, maxSize)).

fun createCachedClient(cacheDir: File): OkHttpClient {
    return OkHttpClient.Builder()
        .cache(Cache(cacheDir, 10L * 1024 * 1024))
        .addNetworkInterceptor { chain ->
            val response = chain.proceed(chain.request())
            response.newBuilder()
                .header("Cache-Control",
                    "public, max-age=300")
                .removeHeader("Pragma")
                .build()
        }
        .build()
}

El código crea un OkHttpClient con una caché de 10 MB y anula Cache-Control a través de NetworkInterceptor. Si el servidor no devuelve Cache-Control o usa Expires, el interceptor agrega public, max-age=300 (5 minutos). El interceptor elimina el obsoleto encabezado Pragma (HTTP/1.0) para compatibilidad. El almacenamiento en caché en iOS funciona de manera similar a través de URLCache.shared con las configuraciones memoryCapacity y diskCapacity.

Modo sin conexión y stale-while-revalidate

La directiva stale-while-revalidate permite mostrar al usuario una caché obsoleta mientras la aplicación obtiene datos nuevos en segundo plano. Esto proporciona un efecto de respuesta instantánea: el usuario ve el contenido de inmediato y, después de un segundo, se actualiza a la versión actual. Compatible con OkHttp a partir de la versión 3.10 y URLCache en iOS 14+. Ejemplo: Cache-Control: max-age=3600, stale-while-revalidate=300 — 1 hora de caché actualizada, luego 5 minutos de mostrar datos obsoletos con actualización en segundo plano.

Ejemplos de configuración de Cache-Control

Diferentes tipos de recursos requieren diferentes estrategias de almacenamiento en caché. Veamos las configuraciones óptimas para escenarios típicos en el desarrollo móvil. Para contenido estático con un hash en el nombre del archivo (bundle.abc123.js), puede establecer max-age hasta 1 año con immutable. Para listas de API que se actualizan raramente (directorios, categorías) — max-age de 5 minutos a 1 hora con stale-while-revalidate.

Es importante recordar la seguridad: para las respuestas que contienen datos personales del usuario, siempre establezca private. Sin esta directiva, un proxy público (por ejemplo, corporativo) puede almacenar en caché la respuesta y entregarla a otro usuario. Para tokens de autenticación e información de pago, use no-store — ni siquiera una caché privada debe almacenar estos datos en disco.

Depuración del almacenamiento en caché

Para verificar la corrección de Cache-Control, use el encabezado Age (cuántos segundos se ha almacenado la caché) y X-Cache (hit/miss en CDN). En el navegador — la pestaña Network, la columna Size muestra “from disk cache” o “304 Not Modified”. Si un recurso debería almacenarse en caché pero se carga cada vez, verifique si el servidor está agregando Cache-Control: no-cache o Pragma: no-cache junto con sus directivas.