Cloudflare Edge Cache TTL: cómo funciona y cómo configurarlo
Hace poco escribí un post introduciendo Cloudflare, y este es un post que le sigue enfocado solo en el Edge Cache TTL de Cloudflare. Puedes leer primero A Beginner's Guide to Cloudflare.
Qué es
El Edge Cache TTL controla cuánto tiempo se queda un recurso en el caché de la red global de Cloudflare. En vez de que cada petición llegue al servidor de origen, Cloudflare entrega una copia cacheada desde el nodo edge más cercano al visitante.
Edge TTL vs Browser TTL
- Edge TTL: cuánto tiempo lo cachean los servidores de Cloudflare.
- Browser Cache TTL: cuánto tiempo lo cachea localmente el navegador del visitante.
Opciones de configuración (Cache Rules)
- Usar el header
cache-controlsi existe, si no, hacer bypass (no cachear). - Usar el header
cache-controlsi existe, si no, usar el comportamiento de TTL por defecto de Cloudflare. - Ignorar
cache-controlpor completo y usar un TTL fijo que tú defines.
Headers
age: cuántos segundos lleva guardada esta copia en el caché de Cloudflare.cf-cache-status: el estado del caché de Cloudflare. HIT indica que la respuesta vino de Cloudflare. Hay otros estados que puedes ver en Cache Status.
Cloudflare Cache Status
| Estado | Significado |
|---|---|
HIT | Se entregó directo desde el caché de Cloudflare. No se tocó el origen. |
MISS | Es cacheable, pero esta vez no estaba guardado (primera visita o ya expiró). Cloudflare lo pidió al origen y lo cacheó. |
EXPIRED | Estaba cacheado pero se le acabó el TTL (quedó obsoleto). Cloudflare está pidiendo una copia nueva al origen. |
BYPASS | Cloudflare se saltó el caché a propósito (por ejemplo, una Cache Rule excluye la ruta, hay un header Set-Cookie, o el origen manda Cache-Control: no-store/private). |
DYNAMIC | Cloudflare determinó que este contenido no es cacheable por defecto (el caso más común: el HTML, que no se cachea a menos que crees una Cache Rule explícita). |
REVALIDATED | El contenido había expirado, pero al revalidarlo con el origen (con ETag/If-Modified-Since) devolvió 304 Not Modified, así que se entrega la misma copia cacheada con el TTL renovado. |
UPDATING | El caché expiró, pero se entrega la copia vieja mientras Cloudflare pide una nueva en segundo plano (comportamiento stale-while-revalidate). |
STALE | Se entrega una copia expirada porque el origen no respondió a tiempo o devolvió un error. Mejor entregar algo viejo que nada. |
IGNORED | La petición no pasó por el flujo normal de caché (por ejemplo, el método no es GET ni HEAD). |
NONE/UNKNOWN | Este tipo de recurso o la configuración de la zona no soportan caché para nada, nunca se evaluó. |
Purge Cache
La función Purge Cache te permite limpiar manualmente el contenido guardado en el caché de Cloudflare, sin tener que esperar a que expire el Edge TTL.
- Purge Everything: limpia de una vez todo el caché de tu zona. En tu siguiente visita, cualquier recurso va a dar MISS.
- Purge by URL: limpias solo las URLs específicas que cambiaron.
- Purge by hostname: limpia el caché de un subdominio específico sin afectar a los demás.
- Purge by tag o prefix: te permite etiquetar recursos al cachearlos y purgar solo ese grupo con un solo comando.
Ejemplo: excluir una ruta dinámica del caché
Las Cache Rules se ejecutan en orden, y gana la última regla que coincide. Para hacer bypass del caché en una ruta mientras mantienes una regla general para todo lo demás, hay dos opciones:
Una regla de bypass aparte
Ponla después de la regla general en la lista:
When: http.request.uri.path wildcard "/api/likes/*"
Then: Cache eligibility → Bypass cache
Es explícita: cualquiera que lea las reglas después entiende de inmediato que /api/likes/* está excluido a propósito.
Excluir la ruta en la regla que ya existe
http.host eq "www.example.dev" and not starts_with(http.request.uri.path, "/api/likes/")
Funciona, pero la exclusión queda implícita, escondida en una cláusula not en vez de ser una regla visible por sí sola.
Por ejemplo, estas son las cache rules que tengo en mi blog:
Browser TTL
Esta opción está en Caching > Cache Rules, cuando creas o editas una regla. Es el equivalente al Edge TTL, pero para el navegador del visitante, no para los servidores de Cloudflare. Hay 3 opciones:
Bypass cache: no guarda nada en el caché del navegador.Respect origin: Cloudflare pasa el headerCache-Controlque manda el origen tal cual.Override origin: ignora lo que diga tu origen y obliga al navegador a usar el valor de TTL que tú definas.
Cache Key
Cloudflare usa la cache key para decidir si dos peticiones son la misma página o páginas distintas a efectos de caché. Por defecto, Cloudflare arma la key con el host, la ruta y toda la query string.
Por eso /products?id=5 y /products?id=5&utm_source=facebook se consideran dos páginas distintas aunque el HTML sea el mismo.
Esto lo puedes configurar en Caching > Cache Rules al crear o editar una regla:
- Cache deception armor: protección contra un ataque específico en el que alguien engaña a Cloudflare para que cachee una respuesta dinámica bajo una ruta que parece estática.
- Cache by device type: separa el caché entre móvil, escritorio y tablet.
- Ignore query string: trata todas las variantes de
?x=xcomo la misma página. - Sort query string params: normaliza el orden. Por ejemplo,
?b=2&a=1y?a=1&b=2se considerarían iguales.
Frequently asked questions
¿Cuál es la diferencia entre el TTL de Edge y el TTL de la caché del navegador?
El TTL de Edge controla por cuánto tiempo los servidores de Cloudflare almacenan en caché un recurso, mientras que el TTL de la caché del navegador controla por cuánto tiempo el propio navegador del visitante lo almacena en caché localmente. Se configuran por separado y sirven para diferentes niveles de almacenamiento en caché.
¿Qué significa una respuesta cf-cache-status: DYNAMIC y por qué aparece tan a menudo para el HTML?
DYNAMIC significa que Cloudflare determinó que el contenido no es almacenable en caché de forma predeterminada, lo más común es el HTML, ya que Cloudflare no lo almacenará en caché a menos que configures una regla de caché explícita para él.
Comments