> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tryprofound.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Limitaciones del almacenamiento en caché de CDN

> Conoce las limitaciones del plugin de WordPress cuando se usa con una CDN para el almacenamiento en caché

<Warning>
  **Importante**: si tu hosting de WordPress usa una CDN para el almacenamiento en caché (Cloudflare, Fastly, etc.), el plugin **solo capturará los fallos de caché** (cache misses), no los aciertos de caché (cache hits). Es una limitación de la plataforma, no del plugin.
</Warning>

### El problema

Muchos hostings administrados de WordPress (WP Engine, Kinsta, Flywheel, etc.) colocan una CDN delante de tu sitio de WordPress para mejorar el rendimiento. Cuando un visitante solicita una página:

1. **Fallo de caché** → La solicitud pasa a WordPress → El plugin captura la solicitud → Se registra correctamente
2. **Acierto de caché** → La CDN sirve el contenido en caché directamente → **La solicitud nunca llega a WordPress** → El plugin no la registra

Esto significa que solo verás una parte de tu tráfico real: en concreto, el tráfico que no se sirvió desde la caché.

#### Ejemplo

En este ejemplo, el sitio está alojado en WordPress Engine con la capa de caché de aplicación de WPE habilitada.

En este ejemplo, se obtiene la página por primera vez, por lo que se produce un fallo de caché.

```shell theme={null}
curl -I "https://my-wp-site.com/some-page"


HTTP/2 200 OK
...
x-cache: MISS
# Cache missed, request reaches WordPress and is logged by the plugin
...
```

En la segunda solicitud, la página ya está en la caché, por lo que se sirve desde la capa de caché y nunca llega a WordPress.

```shell theme={null}
curl -I "https://my-wp-site.com/some-page"


HTTP/2 200 OK
...
x-cache: HIT: 1
# Cache hit, request never reaches WordPress and is not logged by the plugin
...
```

### Por qué ocurre esto

El plugin funciona en la capa de aplicación de WordPress. Solo puede registrar las solicitudes que realmente llegan a tu servidor de WordPress. Cuando una CDN sirve contenido en caché, la solicitud termina en los servidores perimetrales de la CDN y nunca llega a tu instalación de WordPress.

**La solución completa** es usar los log drains nativos de la CDN, que Agent Analytics ya admite por completo. Los logs de la CDN capturan *todo*: aciertos de caché, fallos de caché, tráfico de bots, intentos de DDoS; el panorama completo.

### El problema de la plataforma

Lamentablemente, la mayoría de los hostings administrados de WordPress, como WP Engine y Kinsta, no ofrecen a sus clientes acceso para configurar los log drains de su CDN.
Profound se ha puesto en contacto con estos proveedores para solicitar acceso para los clientes, pero por ahora lo han rechazado. Estamos buscando oportunidades de colaboración con estos proveedores para habilitar esta funcionalidad.

### Impacto en la analítica

<AccordionGroup>
  <Accordion title="Qué se captura">
    * Visitas iniciales a una página (fallo de caché)
    * Páginas dinámicas o personalizadas que omiten la caché
    * Solicitudes POST y envíos de formularios
    * Tráfico generado por administradores hacia páginas públicas
    * Páginas con parámetros de consulta (a menudo no se almacenan en caché)
    * Solicitudes durante los períodos de purga o reconstrucción de la caché
  </Accordion>

  <Accordion title="Qué se pierde">
    * Visitas posteriores a la misma página (aciertos de caché)
    * Páginas populares con altas tasas de aciertos de caché (normalmente más del 90 %)
    * Recursos estáticos servidos desde la CDN (CSS, JS, imágenes)
    * Tráfico de bots filtrado o servido en el perímetro de la CDN
    * Ataques o DDoS bloqueados en la capa de la CDN
  </Accordion>

  <Accordion title="Tasas típicas de aciertos de caché">
    * **Sitios bien optimizados**: tasa de aciertos de caché del 85-95 %
    * **Sitios promedio**: tasa de aciertos de caché del 60-80 %
    * **Sitios dinámicos o personalizados**: tasa de aciertos de caché del 20-40 %
  </Accordion>
</AccordionGroup>

### Alternativas

Si necesitas visibilidad completa del tráfico, considera lo siguiente:

1. **Cambiar a un hosting que ofrezca control de la CDN**: muchos proveedores (AWS, Google Cloud, etc.) te permiten configurar tu propia CDN
2. **Solicitar acceso a la CDN de nivel empresarial**: algunos hostings administrados ofrecen acceso a los logs a clientes empresariales
3. **Aceptar datos parciales**: para la detección de bots y la supervisión de abusos, los fallos de caché suelen ser suficientes, ya que los bots normalmente no se benefician de la caché
4. **Usar Agent Analytics directamente con una CDN compatible**: si puedes configurar tu propia CDN de Cloudflare, Fastly u otra compatible, usa nuestras integraciones nativas

<Note>
  Esta limitación no es exclusiva de Agent Analytics. Cualquier plugin de WordPress que intente registrar solicitudes HTTP enfrenta la misma restricción: solo puede ver lo que llega a WordPress. La solución estándar del sector es la recopilación de logs nativa de la CDN, que admitimos por completo para los clientes con acceso a su CDN.
</Note>