Cómo purgar la caché de una CDN sin romper tu sitio

Por qué el edge sigue sirviendo el archivo antiguo

Cuando un visitante pide un archivo, la ubicación edge más cercana comprueba si tiene una copia válida. Si la tiene, responde de inmediato sin preguntar a tu servidor — ese es todo el sentido de una CDN, y es por lo que tu sitio es rápido. Cuánto dura ese "válida" viene de las cabeceras de caché que tu origen envió cuando el edge trajo el archivo por primera vez, casi siempre Cache-Control: max-age.

Así que cuando subes una versión nueva y sigues viendo la antigua, no hay nada roto. Has cambiado el archivo en el origen, pero el edge sigue dentro de la ventana durante la cual le dijiste que conservara la copia anterior. Tienes tres salidas: esperar a que caduque, purgarla ahora o publicar en una URL nueva para que no haya nada obsoleto que servir. Cuál elegir es el resto de esta guía.

Exacta, prefijo, variantes — usa el martillo más pequeño

Una purga exacta elimina una URL concreta. Es el valor por defecto correcto: has reemplazado /images/hero.jpg, así que purgas /images/hero.jpg. Precisa, instantánea, y todo lo demás sigue caliente.

Una purga por prefijo elimina todo lo que hay bajo una ruta — /assets/ vacía todos los archivos que cuelgan de ahí. Úsala tras un despliegue que ha reescrito un directorio entero. Es potente, así que apunta con cuidado: purgar /images/ porque ha cambiado un logo tira a la basura miles de objetos cacheados que sí eran útiles.

Una purga de variantes limpia todas las versiones cacheadas de la misma clave. El edge puede conservar varias copias de una misma URL — comprimida y sin comprimir, o variantes por tipo de dispositivo — y si reemplazas el archivo subyacente querrás que desaparezcan todas, no solo la que casualmente coincide con tu propio navegador. Esta es la opción que a la gente se le escapa cuando una purga "no funcionó" para algunos visitantes pero sí para ellos.

Las mismas tres opciones desde la CLI

# one URL (the usual case)
cdnctl purge --account <uuid> --path /images/hero.jpg

# several at once
cdnctl purge --account <uuid> --paths "/css/app.css,/js/app.js"

# everything under a folder
cdnctl purge --account <uuid> --path /assets --type prefix

# every cached variant of one key
cdnctl purge --account <uuid> --path /index.html --type variants

# save this list to re-run after future deploys
cdnctl purge --account <uuid> --paths "/,/sitemap.xml" --save

Cuándo purgarlo todo (y qué cuesta)

Purgar la caché completa de la cuenta es la decisión correcta después de un cambio que afecta a todo el sitio: un rediseño, la edición de una plantilla que toca todas las páginas, una migración de CMS. Es un solo comando y es honesto sobre lo que hace — todo desaparece.

Entiende primero el coste. Durante un rato tras una purga total, el edge no tiene nada, así que las peticiones que antes se respondían cerca del usuario ahora viajan hasta tu origen. Un sitio que sirve cómodamente diez peticiones por segundo detrás de la caché puede encontrarse de golpe con todas ellas a la vez. En un origen pequeño, esa es la diferencia entre ir rápido y ir a duras penas. Precisamente por ser deliberadamente contundente, la CLI te exige confirmarlo.

Se exige confirmación explícita — es intencionado

# clear the whole account cache
cdnctl purge all --account <uuid> --yes

# watch it complete
cdnctl purge all status --account <uuid>

La purga que nunca tienes que ejecutar

La mejor estrategia de invalidación es no necesitar ninguna. Si el nombre de un archivo cambia cada vez que cambia su contenido — app.a1b2c3.js, style.9f8e7d.css —, entonces un despliegue publica URLs nuevas. Las antiguas siguen cacheadas, inofensivas y sin que nada las referencie; las nuevas no se han cacheado nunca, así que todos los visitantes obtienen la nueva versión al instante. Cualquier herramienta de build moderna lo hace por ti, y por eso el caché de assets se puede configurar sin riesgo a un año.

Eso deja los archivos cuyo nombre no puede cambiar: tus páginas HTML, /sitemap.xml, robots.txt, los feeds JSON. Dales un max-age corto para que se refresquen solos, y púrgalos explícitamente cuando necesites que el cambio se vea de inmediato. En la práctica, una configuración sana purga un puñado de rutas tras un despliegue, no miles.

Por qué parece que la purga no funcionó

Casi todos los avisos de "la purga no hizo nada" son una de estas cuatro cosas, y ninguna consiste en que el edge se equivoque.

Tu propio navegador también lo cacheó. Cache-Control se aplica igualmente al navegador; el edge está fresco pero tu portátil no. Comprueba en una ventana privada o con una cadena de consulta que rompa la caché antes de escalar el problema.

Purgaste una URL distinta de la que se está sirviendo. /page y /page/ pueden ser claves de caché separadas, igual que las versiones http y https, o una URL con parámetros de seguimiento añadidos. Purga la URL que tus usuarios piden realmente.

Purgaste una sola variante. Las copias comprimida y sin comprimir del mismo archivo son entradas distintas — si algunos visitantes ven la versión nueva y otros no, purga con el tipo variants.

O el origen volvió a servir el archivo antiguo. Una purga solo le dice al edge que olvide; la siguiente petición vuelve a pedirlo a tu servidor. Si la caché de tu propia aplicación o de un plugin todavía conserva la página antigua, el edge volverá a cachear fielmente la copia obsoleta. Limpia primero la caché de la aplicación y purga después el edge.

Que forme parte del despliegue, no de tu memoria

Purgar a mano después de cada release es un paso que alguien acaba olvidando, normalmente en la release que importaba. Ponlo en el pipeline: cuando el despliegue termine bien, ejecuta una purga para el puñado de rutas cuyos nombres nunca cambian. En cdn.com.tr puedes hacerlo desde el panel, a través de la API REST o con cdnctl en un job de CI — el mismo comando tanto si se ejecuta desde tu terminal como desde un runner. Las listas de rutas guardadas (--save) convierten esto en una única línea que conservas en lugar de una lista que reescribes cada vez.