¿Tu tasa de aciertos de caché en Cloudflare es solo del 30%? Configura estas 3 reglas para subirla al 90%

La tasa de aciertos de caché de mi blog en Cloudflare se quedaba alrededor del 30%. Las imágenes y el CSS se cacheaban, pero el HTML volvía al origen en cada visita y el servidor seguía saturado. Cloudflare no cachea HTML por defecto y Page Rules ya está obsoleto.

Tras estudiar Cache Rules y Edge TTL, la tasa pasó del 30% al 90%, el TTFB de 500 ms a poco más de 100 ms y la carga del servidor bajó un 90%. Este artículo explica por qué el HTML no se cachea, cómo configurar Cache Rules y cómo verificar el resultado.

¿Por qué Cloudflare no cachea HTML por defecto?

Comportamiento de caché por defecto

Primero, el comportamiento por defecto. Cloudflare solo cachea recursos estáticos: imágenes (JPG, PNG, GIF), CSS y JS. ¿HTML? Por defecto, no.

¿Por qué? Cloudflare decide si un recurso es cacheable según tres condiciones:

1. Cabecera Cache-Control: si hay private, no-store, no-cache o max-age=0, no cachea
2. Código de respuesta: solo ciertos códigos HTTP (200, 301, 404, etc.)
3. Método de la petición: solo GET; POST y PUT no

Las páginas HTML suelen verse como contenido dinámico con datos del usuario, así que no se cachean. Es razonable: con login, el HTML puede mostrar nombre o datos personales que no deben quedar en la CDN.

La razón real de no cachear HTML

En el fondo, es seguridad. Vi en un foro a alguien que activó caché en todo el sitio y cacheó hasta wp-login.php, credenciales incluidas. Cualquier visitante podía entrar al panel de WordPress. Da miedo solo pensarlo.

Si tu sitio es mayormente estático, por ejemplo:

• Blog estático generado con Next.js o Gatsby
• Web corporativa o documentación con poca actualización
• Páginas de producto puramente informativas

cachear HTML mejora mucho el rendimiento. La clave es excluir bien panel, login y rutas sensibles.

¿Cuánto mejora cachear HTML?

Alguien compartió en Medium que, tras cachear HTML, el TTFB bajó de 500 ms a 100-160 ms y la carga del servidor se redujo un 90%.

La diferencia es simple: antes cada visita pedía HTML al origen (procesar, base de datos, render). Ahora la CDN lo entrega y el origen casi no trabaja. Más tráfico, más se nota.

Page Rules está obsoleto: cómo usar Cache Rules

El fin de Page Rules

Si ya usaste Cloudflare, conoces Page Rules y la opción Cache Everything para HTML. Hoy Page Rules está marcado como deprecated.

Cronología:

• Julio de 2024: cuentas gratuitas nuevas sin Page Rules
• 2025: Cloudflare migrará Page Rules al nuevo sistema
• Toda configuración nueva: Cache Rules

Page Rules es viejo, poco flexible y en el plan gratuito solo 3 reglas. Para estrategias complejas, se queda corto.

El mundo de Cache Rules

Cache Rules es el sistema nuevo y mucho más potente. La diferencia clave:

Era Page Rules: elegías manualmente Cache Everything

Era Cache Rules: al elegir Eligible for cache, Cache Everything queda activo

Al principio busqué Cache Everything hasta ver que ya tenía otro nombre.

Además, las condiciones son más flexibles:

• Ruta URI, extensión, hostname, etc.
• Expresiones regulares (poco las uso)
• Combinación de condiciones

Notas de migración

Si aún usas Page Rules:

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

1. Cloudflare migra por ti: en 2025 convertirá Page Rules (también puedes migrar antes)
2. Algunos ajustes no migran: Disable Security y Disable Performance están obsoletos
3. Comportamiento distinto: Eligible for cache ≈ Cache Everything, con matices internos

Recomiendo pasar ya a Cache Rules: tarde o temprano toca, y la configuración es más clara.

Configuración práctica: 3 reglas para cachear todo el sitio

Pasemos a la práctica. Configuraremos 3 Cache Rules: exclusión del panel, estáticos y resto del sitio.

Preparación: entrar a la configuración

Inicia sesión en Cloudflare, elige el dominio y:

1. Menú izquierdo: Caching
2. Pestaña Cache Rules
3. Create rule

Vamos regla por regla.

Regla 1: omitir panel y administración (máxima prioridad)

¿Por qué primero? Seguridad. El panel y el login nunca deben cachearse.

Pasos:

1. Rule name: Bypass Admin Pages
2. When incoming requests match:
   • Custom filter expression
   • Field: URI Path
   • Operator: contains
   • Value: /wp-admin (añade más rutas después)
3. Más exclusiones con Or:
   • /wp-login.php
   • /admin/
   • /api/auth/
4. Then:
   • Bypass cache
5. Prioridad: 1

Pulsa Deploy. Esas rutas irán siempre al origen.

Lista completa típica en WordPress:

/wp-admin
/wp-login.php
/wp-json
/cart
/checkout
/my-account

Ajústala a tu sitio.

Regla 2: cachear recursos estáticos (prioridad media)

Opcional porque Cloudflare ya cachea estáticos, pero así controlas mejor el TTL.

Pasos:

1. Rule name: Cache Static Assets
2. When incoming requests match:
   • File extension
   • Operator: is in
   • Value: jpg png gif css js woff woff2 ttf svg ico
3. Then:
   • Eligible for cache
   • Edge cache TTL: Use cache-control header if present, use default Cloudflare caching behavior if not
4. Prioridad: 2

Los estáticos respetan Cache-Control del origen; si no hay, usa el TTL por defecto de Cloudflare (suele ir de 4 horas a 1 mes según el tipo).

Regla 3: cachear todo lo demás (mínima prioridad)

Aquí entra el HTML y el resto.

Pasos:

1. Rule name: Cache Everything Else
2. When incoming requests match:
   • All incoming requests
   • O Custom filter expression si quieres excluir rutas concretas
3. Then:
   • Eligible for cache
   • Edge cache TTL: Ignore cache-control header and use this TTL
   • Duración: 7 days
4. Prioridad: 3

¿Por qué 1 semana? Equilibrio: 1 día aporta poco; 1 mes retrasa actualizaciones. Para blogs y documentación, 1 semana encaja bien.

Plan gratuito: TTL mínimo 2 horas; en Pro, 1 hora. Si actualizas mucho, acorta el TTL.

El orden de ejecución importa

Cloudflare aplica por prioridad ascendente:

1. Regla 1 (prioridad 1): ¿es panel? Bypass
2. Regla 2 (prioridad 2): ¿es estático? TTL adecuado
3. Regla 3 (prioridad 3): el resto, 1 semana

Así el panel nunca se cachea, los estáticos tienen TTL razonable y el HTML se fuerza 1 semana.

Lista de comprobación

Tras las tres reglas:

• Regla 1 con la prioridad más alta (número más bajo)
• Rutas de panel en la lista de exclusión
• TTL de la regla 3 acorde a tu frecuencia de actualización
• Todas las reglas desplegadas (Deploy)

Configuración lista. Ahora los posibles problemas de Edge TTL.

Edge TTL en detalle: evita estas trampas

Edge TTL (tiempo de vida en el edge) es el núcleo de la estrategia y donde más errores vi.

Los tres modos de Edge TTL

Modo 1: Use cache-control header if present, bypass cache if not

• Si hay Cache-Control se respeta; si no, no cachea
• Para orígenes con Cache-Control completo
• Demasiado estricto para sitios pequeños sin cabeceras

Modo 2: Use cache-control header if present, use default Cloudflare caching behavior if not (recomendado en general)

• Respeta Cache-Control; si no hay, comportamiento por defecto de Cloudflare
• Origen parcialmente configurado
• El más equilibrado para la mayoría

Modo 3: Ignore cache-control header and use this TTL

• Ignora el origen y fuerza tu TTL
• Sitios estáticos o estrategia clara
• Contundente y efectivo para HTML en todo el sitio

Para HTML recomiendo el modo 3. Muchas páginas no tienen Cache-Control o usan no-cache; los modos 1 y 2 no cachean. El 3 fuerza directamente.

¿Cómo elegir la duración del TTL?

Plan gratuito: mínimo 2 horas. Si no puedes bajar más, es límite del plan.

En mi blog uso 1 semana. Tras publicar purgo manualmente (más abajo) y el resto del tiempo la tasa de aciertos es altísima.

Errores frecuentes (los he cometido)

Error 1: olvidar excluir el panel

Al principio puse una sola regla Cache Everything y cacheé el panel de WordPress. Login con páginas viejas y que refrescar a mano. Frustrante.

Alibaba Cloud - Opción preferida para desarrolladores, 15 % de descuento exclusivo en Lighthouse

Obtener 15% dto. →Anuncio

Solución: primero la regla Bypass con prioridad máxima.

Error 2: TTL demasiado largo

Con 1 mes de TTL cambié un título y los visitantes vieron el antiguo días.

Solución: TTL según frecuencia de actualización. Si dudas, 1 semana.

Error 3: confundir Edge TTL y Browser TTL

Edge TTL = nodos CDN. Browser TTL = navegador del visitante. Son independientes.

• Edge TTL: cuándo la CDN vuelve al origen
• Browser TTL: cuándo el navegador vuelve a pedir a la CDN

Solo Edge TTL: el origen descansa, pero el navegador sigue pidiendo a menudo a la CDN.

Solución: Browser TTL en Respect origin o ~1 día.

Purgar caché manualmente

¿Contenido actualizado? No esperes al TTL.

En Cloudflare:

1. Menú Caching
2. Purge Cache
3. Opciones:
   • Purge Everything: todo el sitio
   • Custom Purge: URLs concretas

Uso Custom Purge. Purgar todo dispara todas las peticiones al origen de golpe.

Truco: plugin de Cloudflare en WordPress para purgar al publicar.

Verificación y optimización

Configurado, hay que comprobarlo con datos.

Método 1: herramientas de desarrollo del navegador

1. Chrome (u otro navegador)
2. F12
3. Pestaña Network
4. Visita la home
5. Localiza el documento HTML (suele ser la primera petición)
6. Abre Headers

Cabeceras clave:

cf-cache-status:

• HIT: acierto, contenido desde la CDN
• MISS: fallo, fue al origen pero quedará cacheado
• DYNAMIC: dinámico, no cachea (o Bypass activo)
• BYPASS: omisión explícita (panel)
• EXPIRED: caducado, la CDN actualiza

Primera visita: MISS. Segunda: HIT. Si siempre DYNAMIC o BYPASS, revisa reglas.

age: segundos en caché en la CDN. age: 3600 = 1 hora.

cache-control: estrategia del origen. Con Ignore cache-control, Cloudflare no la sigue pero la cabecera puede seguir visible.

Método 2: curl

curl -I https://your-website.com

Busca cf-cache-status en los headers.

Más detalle:

curl -svo /dev/null https://your-website.com 2>&1 | grep -i "cf-cache"

Método 3: Cloudflare Analytics

1. Tu dominio
2. Analytics
3. Caching
4. Cache Hit Ratio

Antes: 30%. Al día siguiente: 85%. Ahora: ~90%. Si ves un salto similar, la configuración funciona.

Referencias:

• Tasa de aciertos: objetivo >80%
• Ancho de banda: debería bajar claramente
• Peticiones: más en CDN, muchas menos en origen

Técnicas avanzadas

Técnica 1: precalentar caché

Lo nuevo empieza en MISS. Tras publicar, visita tú las páginas o usa un script que recorra el sitio.

Técnica 2: unificar URLs

Variantes distintas = objetos de caché distintos:

Railway - Plataforma de despliegue moderna, sin ops complejas, en producción en minutos

Empezar ahora →Anuncio

• https://example.com/page y https://example.com/page? no son lo mismo
• https://example.com/page y https://example.com/page/ tampoco

Unifica enlaces para evitar MISS innecesarios.

Técnica 3: quitar query strings inútiles

?utm_source=twitter y cada variante son páginas distintas para la caché.

Cloudflare tiene Query String Sort en Caching; ayuda ordenando parámetros.

Mejor aún: Transform Rules para eliminar parámetros que no cambian el contenido.

Resolución de problemas

Problema 1: cf-cache-status siempre DYNAMIC

Posibles causas:

• Cache-Control no-cache o private en el origen
• Regla sin coincidencia para Eligible for cache

Solución: revisa condiciones. Con modo 3 (Ignore cache-control) debería forzar caché.

Problema 2: tasa solo 50-60%

Posibles causas:

• URLs con parámetros dinámicos
• Cabeceras del origen que bloquean
• Nodos CDN aún calentando (tras configurar, espera 1-2 días)

Solución: tiempo + Analytics para ver qué peticiones fallan.

Problema 3: visitantes ven contenido viejo

Posibles causas: TTL largo o caché del navegador

Solución: Purge Cache al publicar o plugin automático (WordPress tiene varios).

Resumen

Pasos clave:

1. Por qué no cachea HTML: seguridad, evitar contenido dinámico y rutas sensibles
2. De Page Rules a Cache Rules: Page Rules obsoleto; Eligible for cache ≈ Cache Everything
3. 3 Cache Rules:
   • Regla 1 (prioridad 1): Bypass panel y login
   • Regla 2 (prioridad 2): estáticos
   • Regla 3 (prioridad 3): resto (HTML), TTL ~1 semana
4. Edge TTL: para HTML, Ignore cache-control and use this TTL; ajusta duración
5. Verificación: cf-cache-status en devtools, Analytics >80%

Tras configurar, pasé del 30% al 90%, TTFB de 500 ms a poco más de 100 ms y carga del servidor -90%. Muy visible con mucho tráfico.

Pruébalo ya:

1. Mira tu Cache Hit Ratio en Analytics
2. Configura las 3 reglas (¡excluye el panel primero!)
3. Espera 1-2 días y revisa Analytics

Si algo falla:

• ¿Panel en Bypass?
• ¿Prioridades correctas?
• ¿Modo Edge TTL adecuado?

Con WordPress, el plugin oficial de Cloudflare purga al publicar y ahorra dolores de cabeza.

¿Experiencias o dudas? Compártelas en los comentarios.