tech stack

CDN detectada

MetricSpot detecta la CDN que sirve la página (Cloudflare, Fastly, CloudFront, Bunny, Vercel, Netlify, Akamai) a partir de las cabeceras. La capa de edge marca el techo de cada métrica de rendimiento.

Qué comprueba esta verificación

Mira las cabeceras HTTP de respuesta en la URL auditada e identifica la CDN (Content Delivery Network) que la sirve. Es una comprobación informativa — no hay pass/fail. El resultado te dice si existe una capa de edge entre los usuarios y tu origen, y a través de qué proveedor te están enrutando.

Por qué importa

Una CDN cachea tus assets en docenas o cientos de puntos de presencia (PoP) por el mundo. Un usuario en São Paulo pega contra un nodo de São Paulo, no contra tu origen en Frankfurt. Esa sola capa cambia el suelo de cada métrica de rendimiento que mide la auditoría:

Una CDN también absorbe tráfico DDoS, termina TLS en el edge y permite correr lógica (auth, redirecciones, splits A/B) cerca del usuario vía edge workers. Si MetricSpot reporta “Sin CDN detectada” y tu audiencia es global, ese es el cambio de infraestructura con mayor leverage que puedes hacer.

Cómo arreglarlo

Esta comprobación es informativa, así que la acción depende de lo detectado.

Sin CDN detectada. Pon una delante de tu origen. Defaults que funcionan para la mayoría de sitios:

  • Cloudflare — la capa gratuita cubre la mayoría de sitios de marketing y landings de SaaS. Mejor protección DDoS. Se detecta vía Server: cloudflare y la cabecera CF-Ray.
  • Bunny — el egress más barato para sitios pesados en imagen y vídeo. Pay-as-you-go, sin mínimos. Se detecta vía Server: BunnyCDN y CDN-PullZone.
  • Fastly — lógica de edge granular vía VCL. Fuerte para medios y ecommerce que necesitan invalidar caché en milisegundos. Se detecta vía X-Served-By y X-Cache.
  • AWS CloudFront — encaja natural si tu origen está en AWS. Se detecta vía X-Amz-Cf-Id y Via: ... cloudfront.net.
  • Vercel / Netlify Edge — automático si despliegas en cualquiera de las dos. Se detecta vía X-Vercel-Id / X-Vercel-Cache y Server: Netlify.

CDN detectada, pero el rendimiento sigue siendo malo. La CDN está reenviando al origen sin cachear. Causas habituales:

  • Cache-Control: no-store o private en respuestas HTML desde tu origen.
  • Set-Cookie en cada respuesta (algunas CDNs se niegan a cachear respuestas con cookies).
  • Sin cabeceras Cache-Control en absoluto — Cloudflare no cachea HTML por defecto; necesitas una Page Rule o una cabecera Cache-Control: public, max-age=....

Comprueba la cabecera de caché para ver el ratio de hits:

curl -I https://yourdomain.com/ | grep -iE 'cache|cf-cache|x-cache|x-vercel'

HIT significa cacheado en el edge. MISS o DYNAMIC significa que cada petición golpea tu origen — estás pagando por una CDN que no usas.

Cómo elegir entre proveedores. Si ya estás en Vercel o Netlify, usa su edge — cambiarte cuesta más de lo que ahorras. Si necesitas protección DDoS o gestionas un sitio WordPress / hosting compartido, Cloudflare. Si los costes de egress dominan (vídeo, imágenes grandes, descargas de software), Bunny. Si tus ingenieros quieren escribir código en el edge como ciudadano de primera clase, Fastly o Cloudflare Workers.

Preguntas frecuentes

¿Merece la pena una CDN para un B2B mono-región?

Si el 95% de tu tráfico está en un solo país y estás alojado en ese país, el beneficio de caché de la CDN es pequeño — la mayoría de usuarios ya están cerca de tu origen. Aun así te llevas terminación TLS, protección DDoS y filtrado de bots, que merece la pena en la capa gratuita de Cloudflare. Salta los planes de pago hasta que cambie la forma del tráfico.

¿Detecta MetricSpot CDNs delante de CDNs?

Solo la capa más externa — eso es lo que ve el navegador del visitante. Si tienes Cloudflare → Fastly → origen, reportaremos Cloudflare. El setup encadenado es inusual fuera de grandes medios y suele significar que hay una migración en curso; una de las dos debería irse.

¿Una CDN rompe mi analítica o mis tests A/B?

No, pero puede ocultar la IP del cliente a tus logs de origen. Las CDNs reenvían la IP original en X-Forwarded-For o CF-Connecting-IP; el código de tu aplicación o tu herramienta de analítica necesita leer esa cabecera en lugar de la IP fuente TCP. La mayoría de frameworks de servidor tienen un ajuste de trusted-proxy para esto — configúralo una vez y las features basadas en IP (geolocalización, rate limits) funcionan como esperas.

Fuentes

Última actualización 2026-05-11