Cómo funciona nuestro test de velocidad

Este documento detalla la especificación técnica completa de nuestro test de velocidad: el motor de medición de código abierto, la arquitectura Anycast, las APIs de temporización de alta precisión, las fórmulas estadísticas y el protocolo WebRTC de pérdida de paquetes.

Actualizado el 6 de octubre de 2026

Motor de medición y arquitectura cliente

Nuestro test de velocidad está desarrollado sobre @cloudflare/speedtest, el motor de medición JavaScript de código abierto de Cloudflare (licencia MIT). Se ejecuta íntegramente dentro del entorno seguro del navegador web del usuario, sin requerir complementos, ejecutables externos ni permisos de administrador.

Para garantizar una carga web ultrarrápida a quienes solo leen documentación informativa, el motor se importa dinámicamente bajo demanda cuando el usuario pulsa “Iniciar test”. No alteramos ni manipulamos los cálculos de temporización internos del motor: todos los números provienen de eventos de red directos registrados por el navegador.

Infraestructura de servidores perimetrales Anycast

Todas las peticiones HTTP de descarga, subida y latencia conectan con la red perimetral de Cloudflare en speed.cloudflare.com mediante enrutamiento BGP Anycast:

  • Enrutamiento automático al nodo más próximo: En lugar de exigir que el usuario seleccione un servidor de una lista arbitraria, los protocolos troncales de internet encaminan el tráfico al punto de presencia (PoP) de Cloudflare geográficamente más cercano.
  • Evaluación limpia del tramo final: Al ubicarse el servidor en la misma área metropolitana o en el punto neutro de intercambio de tu operador, la prueba mide la capacidad física de tu bucle de acceso local sin distorsiones provocadas por tránsitos transcontinentales saturados.

Secuencia de prueba y fases de ejecución

  1. Fase 1: Calentamiento de la conexión: Ejecuta una petición inicial de 0 bytes y otra de 100 KB para inicializar el protocolo TLS 1.3 y la resolución DNS, evitando que el coste del arranque en frío distorsione las métricas.
  2. Fase 2: Latencia y jitter en reposo: Envía 21 peticiones sucesivas con la línea descargada, registrando la mediana del tiempo de ida y vuelta (RTT).
  3. Fase 3: Medición de descarga: Descarga bloques de datos progresivos (desde 256 KB hasta 25 MB o más) cronometrados mediante la Performance Resource Timing API.
  4. Fase 4: Medición de subida: Transfiere bloques de datos hacia el servidor calculando la tasa de envío.
  5. Fase 5: Pérdida de paquetes WebRTC: Envía ráfagas de datagramas UDP a través de un repetidor TURN para contabilizar descartes.

Fuentes y referencias

  1. @cloudflare/speedtest (measurement engine source and documentation) Cloudflare

    How download, upload, latency, jitter and packet loss are measured by the engine this site uses.

    Verificado el octubre de 2026

  2. PerformanceResourceTiming MDN Web Docs

    The browser timing API used to time each test request.

    Verificado el octubre de 2026

  3. Cloudflare Realtime TURN service Cloudflare Docs

    The relay used to send and count UDP packets in the packet loss test.

    Verificado el octubre de 2026

  4. Aggregated Internet Measurement (AIM) Cloudflare Docs

    Background on judging connection quality by use case rather than by a single number.

    Verificado el octubre de 2026

  5. RFC 3550: RTP, A Transport Protocol for Real-Time Applications (interarrival jitter) IETF

    Formal definition of jitter used by voice and video software.

    Verificado el octubre de 2026

  6. Measurement Lab (M-Lab) Measurement Lab

    Open internet measurement data and methodology.

    Verificado el octubre de 2026