Caché y CDN: por qué no ves un cambio publicado

Publicaste un cambio, lo abrís y sigue todo igual. Recargás y nada. En un celular sí se ve, en otro no. Esa situación casi siempre tiene un nombre: caché. Entender cómo funcionan la caché y CDN ahorra horas de confusión y permite configurar tu sitio para que sea rápido sin mostrar contenido viejo.

Esta guía técnica explica en qué lugares se guarda una copia de tu web, quién decide cuánto dura, cómo verificar qué versión estás viendo y cómo lograr que un cambio se vea al instante cuando hace falta.

Caché y CDN: qué son y por qué existen

La caché es una copia guardada de un recurso (una página, una imagen, un archivo de estilos) para no tener que pedirlo de nuevo cada vez. Ahorra tiempo y ancho de banda: si el navegador ya tiene el logo, no lo vuelve a descargar. La contracara es que si el recurso cambia y la copia no se actualiza, se sigue viendo la versión vieja.

Hay varias capas de caché entre tu servidor y quien mira tu web:

1. El navegador de cada visitante.
2. Un CDN (red de entrega de contenido) que tiene copias en servidores cercanos a los visitantes. MDN explica qué es un CDN.
3. Cachés del servidor o de la aplicación: páginas ya generadas que se reutilizan.
4. Proxies intermedios, más raros hoy.

Un cambio publicado tiene que atravesar todas las capas, y cada una puede seguir sirviendo lo viejo por un tiempo.

Cache-Control: quién decide cuánto dura

Tu servidor le indica a navegadores y CDN qué hacer con cada respuesta mediante la cabecera Cache-Control. Los valores principales, documentados en MDN:

Un detalle que confunde: no-cache no significa "no guardar", sino "consultar antes de usar". Una página con no-cache se sirve rápido si no cambió, y se actualiza si cambió. La guía de MDN sobre caché HTTP desarrolla el modelo completo.

La estrategia que funciona: dos reglas distintas

Un sitio moderno suele combinar dos políticas:

• Archivos con nombre único (con "huella" o hash), como app.4f9c2.js o estilos.a81b3.css: se pueden guardar para siempre (max-age largo e immutable), porque cuando cambian el contenido, cambia el nombre. Así el navegador pide el archivo nuevo sin caché que lo detenga.
• Las páginas HTML, que apuntan a esos archivos: deben revalidarse siempre (no-cache), para que el visitante reciba el HTML nuevo, que a su vez referencia los archivos nuevos.

Si el HTML se guarda por mucho tiempo, el navegador puede intentar cargar archivos que ya no existen después de un despliegue. Ese es el origen de muchos "se rompió después de publicar".

Cómo saber qué versión estás viendo

Antes de asumir que el cambio no se publicó, comprobá:

1. Abrí una ventana privada. Si ahí se ve el cambio, era la caché de tu navegador.
2. Recargá forzando (Ctrl + Shift + R en Windows y Linux, Cmd + Shift + R en Mac).
3. Mirá las cabeceras en las herramientas de desarrollo del navegador (pestaña Red o Network): buscá Cache-Control y, si hay CDN, cabeceras que indican si la respuesta salió de su caché (suelen llamarse Age o CF-Cache-Status, según el proveedor).
4. Probá con un parámetro en la dirección (?v=2) para saltar la caché de esa URL y confirmar que el cambio existe en el servidor.
5. Consultá por terminal, que no usa caché de navegador:

curl -I https://tuempresa.com.ar/pagina/

Con eso ves las cabeceras exactas que recibe cualquier cliente.

Cómo forzar la actualización

• En el navegador: recarga forzada o borrar los datos del sitio.
• En el CDN: la mayoría ofrece purgar la caché (de todo el sitio o de direcciones puntuales). Después de un cambio importante, purgar evita esperar que expire.
• En el servidor o la aplicación: limpiar la caché de la aplicación o del plugin de caché.
• Para archivos estáticos: cambiar el nombre (versionar) es más confiable que depender de purgas.

Qué no conviene cachear

• Páginas con datos personales o de sesión (private o no-store).
• Respuestas de APIs que cambian a cada momento.
• Pasos de pago y formularios con estado.

Errores frecuentes

• Poner max-age largo a las páginas HTML. Los visitantes ven versiones viejas y, tras un despliegue, pueden cargar archivos inexistentes.
• Confundir no-cache con no-store.
• Purgar el CDN pero no la caché del navegador (o al revés), y ver resultados distintos según el lugar.
• Cambiar un archivo sin cambiarle el nombre y esperar que todos lo recarguen.
• No probar en una ventana privada antes de reportar que "no se publicó".

Preguntas frecuentes

¿Por qué mi cliente ve el cambio y yo no?

Cada navegador tiene su propia caché. Probá en una ventana privada o forzando la recarga.

¿La caché puede afectar mi posicionamiento?

Bien usada, lo ayuda: un sitio rápido se recorre mejor. Mal configurada, puede hacer que se vea contenido desactualizado. Para más sobre velocidad, mirá la guía de Core Web Vitals.

¿Cuánto tarda un cambio en verse para todos?

Depende del Cache-Control que tenían las respuestas anteriores y de si purgaste el CDN. Con una buena configuración, es inmediato o casi.

Cómo seguir

Si pediste un cambio y no lo ves, revisá primero con estos pasos y, si persiste, escribinos desde soporte. Si querés que nos encarguemos de la configuración de caché de tu sitio, mirá la puesta a punto. Y para aprender a pedir cambios con claridad, leé cómo pedir cambios en tu web sin perder tiempo.