¿Tienes un archivo Docker Compose? Tu proyecto se publica en segundos, con un solo comando en cdn.com.tr. Ver cómo ¿Creaste tu app con IA? De la carpeta a producción con un comando — sin git ni registry: cdnctl deploy. Ver cómo ¿Tu código en GitHub? Cada push se despliega solo en cdn.com.tr — conecta tu repo y listo. Ver cómo

Casos de estudio

Caso práctico: cómo un sitio de noticias organiza sus cabeceras de caché

Un sitio turco de noticias deportivas de alto tráfico gestiona la caché desde su propio origen, no desde el panel. Cuatro niveles de contenido, cuatro cabeceras Cache-Control distintas, todo verificable desde fuera.

Volver a la Ayuda de la Plataforma
Qué explica esta página

Las cabeceras de respuesta reales de una cuenta en producción, y por qué se eligió cada una. No se identifica al cliente; cada cabecera mostrada aquí está escrita para que pueda verificarla en su propio sitio ejecutando el mismo comando.

Cuatro niveles, cuatro tiempos de vida distintos

Un único tiempo de caché no sirve para un sitio de noticias: la portada cambia cada minuto, el logotipo no cambia en años. Esta cuenta separa el contenido según su velocidad de cambio.

Contenido Cabecera enviada por el origen Por qué
Portada public, max-age=30, s-maxage=30, stale-while-revalidate=60 Las noticias de última hora se renuevan cada 30 segundos; cuando expira, el visitante no debe esperar — el edge sirve la copia antigua mientras la actualiza en segundo plano.
Páginas de sección y listados public, max-age=300, s-maxage=300, stale-while-revalidate=600 Las páginas de categoría no cambian tan a menudo como la portada. Cinco minutos no es un retraso que note el equipo editorial, y reduce considerablemente la carga sobre el edge.
Archivo estático versionado public, max-age=31536000, s-maxage=31536000, immutable El nombre del archivo lleva la versión, así que su contenido nunca cambia. immutable impide que el navegador vuelva a preguntar incluso antes de que expire max-age.
Imagen optimizada max-age=31536000 + public en una línea aparte Esta línea la escribe el edge, no el origen — con Image Optimization activo en una regla, la cabecera se regenera incondicionalmente.

Cómo montar el mismo esquema en su propio sitio

1

Separe el contenido según su velocidad de cambio

Decida primero qué ruta cambia con qué frecuencia, no los tiempos de vida — el tiempo de vida es consecuencia de esa decisión.

  • Cambia en minutos: portada, marcador en vivo, hilo de última hora
  • Cambia en horas: páginas de categoría, listados de archivo
  • No cambia nunca: CSS, JS, fuentes, logotipo — todo lo que lleva versión en el nombre del archivo
  • Es personal: páginas con sesión iniciada, carrito, cuenta — esto no se cachea y no debe cachearse
2

Publique las cabeceras desde su origen

La cabecera la envía su aplicación o su servidor web. No hace falta introducir un tiempo de vida en el panel; los dos métodos no funcionan juntos en la misma regla.

  • s-maxage es para la caché compartida (el CDN), max-age es para el navegador; puede darles valores distintos
  • stale-while-revalidate evita que el visitante espere cuando expira el tiempo de vida — se sirve la copia antigua mientras se obtiene una nueva en segundo plano
  • immutable solo debe enviarse cuando el nombre del archivo está versionado; en un archivo sin versionar deja al navegador con una copia de un año de antigüedad
3

Deje que la regla dependa del origen

En Delivery Rules, la regla de esa ruta necesita **Use browser cache time** activado y **Cache Expire Time** vacío.

  • Si introduce un tiempo de vida, las cabeceras del origen se ignoran en esa regla y la cabecera enviada al navegador también se reescribe
  • Puede separar las reglas por ruta: una regla para archivos estáticos, otra para páginas
4

Mida y luego amplíe

Pruebe primero en una sola ruta. Cuando vea que vuelve la cabecera esperada y obtiene HIT, pase a los demás niveles.

Cómo comprobar que funciona

Todo se ve en las cabeceras de respuesta; no hace falta mirar el panel. Solicite la misma URL dos veces:

curl -sI https://tu-sitio.com/una-pagina | grep -iE "cache-control|x-proxy-cache-mt"
  • X-Proxy-Cache-MT: MISS es normal en la primera petición — el contenido se está cacheando en ese momento. La segunda petición debería devolver HIT.
  • STALE no es un error: significa que stale-while-revalidate está funcionando — el visitante recibe la copia antigua mientras se obtiene una nueva en segundo plano.
  • Si ve BYPASS, casi con toda seguridad ha iniciado sesión en el sitio; la cookie de sesión salta la caché a propósito. Vuelva a intentarlo en una ventana privada.
  • Si el Cache-Control que vuelve es distinto del que usted envió, es que se ha introducido un tiempo de vida fijo en esa regla.
  • Si además quiere ver qué envía el origen, active las cabeceras de diagnóstico de origen en la regla; X-Upstream-CacheControl muestra lo que dice el origen, Cache-Control lo que ve el visitante.

Tres cosas que dejan inútil la cabecera correcta

  • Una respuesta que envía Set-Cookie nunca se cachea. No importa lo correcto que sea el Cache-Control. Es la causa más frecuente de que una caché nunca llegue a calentarse: la aplicación está fijando una cookie de sesión en cada petición.
  • Con Image Optimization activo en una regla, las imágenes se conservan 365 días y la cabecera del origen se ignora. Si quiere gestionar las imágenes usted mismo, desactive este ajuste en esa regla.
  • No envíe immutable en un archivo sin versionar. Si el nombre del archivo no cambia, el navegador usa la copia antigua durante un año y un purge de CDN no lo corrige — el purge solo limpia el edge, no el disco del visitante.

Siga leyendo