Qué cachea Cloudflare por defecto

Cuando activas Cloudflare en un sitio WordPress, automáticamente empieza a guardar en caché los recursos estáticos: imágenes, CSS, JavaScript, fuentes, vídeos y, en general, cualquier archivo con extensiones reconocidas. Esto ya ofrece una mejora notable sin tocar nada más.

Sin embargo, el HTML no se cachea por defecto. Cada vez que alguien visita una entrada del blog, Cloudflare sigue yendo al origen a pedir la página. Para un sitio con mucho tráfico, eso deja bastante rendimiento sobre la mesa.

Cache Levels

En el panel, dentro de la sección Caching, encontrarás tres niveles básicos:

• No Query String: cachea solo cuando la URL no tiene parámetros.
• Ignore Query String: trata pagina?utm=abc y pagina?utm=xyz como la misma URL.
• Standard: cada combinación de URL + parámetros es un recurso distinto.

Para la mayoría de WordPress, el nivel Standard es seguro y predecible.

Purga: manual vs automática

La caché se vuelve un problema cuando actualizas un artículo y los visitantes siguen viendo la versión antigua. Tienes dos formas de resolverlo:

• Purga manual: desde el panel de Cloudflare puedes limpiar toda la caché de un botonazo, o limpiar URLs específicas.
• Purga automática: el plugin oficial de Cloudflare para WordPress detecta cuando publicas o editas contenido y purga automáticamente las URLs afectadas.

La purga automática es claramente superior para un flujo editorial normal, porque evita el olvido humano.

El plugin oficial WP Cloudflare

El plugin se instala desde el repositorio de WordPress, se conecta a tu cuenta con una API key o token y te da:

• Purga automática al publicar/editar/eliminar contenido.
• Activación con un clic de un perfil de optimización recomendado.
• Estadísticas básicas de Cloudflare dentro del admin de WordPress.
• Botón para limpiar toda la caché sin salir de WordPress.

Si solo vas a instalar un plugin relacionado con Cloudflare, este es el que debes usar.

Cachear también el HTML con Page Rules

El salto de rendimiento grande viene cuando usas Cache Everything en el HTML de las páginas públicas. Una Page Rule típica para WordPress:

Patrón: midominio.com/*

Acciones:

• Cache Level: Cache Everything
• Edge Cache TTL: 2 horas

Con esto, una entrada de blog servida desde la caché de Cloudflare responde en unos pocos milisegundos, sin tocar PHP ni MySQL. Pero esta regla, aplicada tal cual, rompe cosas: el panel de administración, los carritos de WooCommerce y las páginas de usuario logueado. Hay que excluirlas.

Excluir wp-admin y el backend

Crea otra Page Rule antes de la anterior (más arriba en la lista) con patrón *midominio.com/wp-admin* y acción Cache Level: Bypass. Considera hacer lo mismo para:

• /wp-login.php
• /cart, /checkout, /mi-cuenta (en tiendas WooCommerce)
• /feed si quieres que los lectores RSS vean cambios al instante

Recuerda que Cloudflare respeta además cookies típicas de sesión: si configuras Bypass Cache on Cookie (disponible en Page Rules), puedes evitar servir HTML cacheado a usuarios logueados.

Verifica que el cache funciona

Abre una página pública con las herramientas de desarrollador del navegador, mira los headers de la respuesta y busca cf-cache-status:

• HIT: Cloudflare sirvió desde caché. Objetivo conseguido.
• MISS: Cloudflare fue al origen. Normal en la primera visita.
• BYPASS: alguna regla está saltando el cache.
• DYNAMIC: el contenido se trata como dinámico (cookies, tipo MIME, etc.).

Si siempre ves DYNAMIC en el HTML público, necesitas la Page Rule de Cache Everything. Si ves BYPASS, revisa el orden de tus reglas.