Cloudflare RUM: Entendiendo la petición /cdn-cgi/rum? en tu web

Si has inspeccionado el tráfico de red de tu sitio y has visto una petición POST hacia una ruta extraña que termina en /cdn-cgi/rum?, es probable que te hayas preguntado si hay algún proceso oculto recolectando datos. No es un malware ni un error del servidor. Se trata de la ejecución del Cloudflare RUM (Real User Monitoring), una herramienta diseñada para medir la velocidad real de carga de tu web desde el navegador de tus visitantes.

#¿Qué es el Real User Monitoring (RUM)?

A diferencia de las pruebas sintéticas que realizas en herramientas como PageSpeed Insights o GTmetrix, el Cloudflare RUM mide lo que sucede en el mundo real. Recopila datos sobre cuánto tarda la página en pintar el primer elemento (LCP), cuánto tarda en responder tras el primer clic (FID) y si hay saltos visuales molestos (CLS). Estos datos son los que luego ves agregados en la pestaña «Analytics» de tu panel de control de Cloudflare.

La ventaja de este enfoque es que detecta problemas de latencia que solo afectan a ciertos países o proveedores de internet específicos. Es la diferencia entre saber que tu web es rápida en tu oficina y saber que también lo es para un usuario con una conexión 4G en el otro lado del mundo.

#Anatomía de la petición: El misterio del código 204

Cuando observas esta petición en tu consola de desarrollador, notarás que el servidor responde con un código 204 No Content. En el desarrollo de APIs modernas, esto es una práctica optimizada. El navegador envía un paquete de datos JSON (el payload) a Cloudflare, y el servidor responde diciendo: «He recibido los datos y los estoy procesando, no necesito enviarte nada de vuelta».

Al no tener que descargar una respuesta, se ahorra ancho de banda y tiempo de procesamiento en el hilo principal del navegador. Es, en esencia, un «dispara y olvida» tecnológico orientado a la máxima eficiencia.

#Caso real: El cuello de botella en dispositivos móviles

Personalmente, gestioné un proyecto donde la web volaba en escritorio pero los usuarios de Android se quejaban de lentitud extrema. No conseguíamos reproducirlo en nuestros entornos de prueba locales.

El Síntoma Clínico: Al revisar los informes generados por las peticiones /cdn-cgi/rum? acumuladas durante una semana, descubrimos que el tiempo de ejecución de JavaScript se triplicaba en navegadores móviles antiguos debido a un plugin de chat muy pesado.

El Intento Fallido: Inicialmente pensamos que era un problema de base de datos y optimizamos las queries del servidor. No sirvió de nada porque el problema era del cliente (frontend). Gracias a la analítica RUM, pudimos ver que el Time into Interactive era el culpable. Eliminamos el plugin y las quejas cesaron de inmediato. Sin esos datos «reales» enviados por el beacon, habríamos seguido optimizando el backend a ciegas.

#Pros y contras de mantener activo el RUM

#Protocolo de rescate: Cómo desactivarlo si es necesario

Si por alguna razón de cumplimiento estricto o por deseo de reducir las peticiones al mínimo absoluto necesitas desactivar este comportamiento, no debes intentar bloquear la ruta por .htaccess (ya que podrías generar errores 403 innecesarios). La forma correcta es hacerlo desde el origen.

Para desactivar el Real User Monitoring:

# No existe comando de terminal; se gestiona en el panel:
# 1. Accede a tu cuenta de Cloudflare.
# 2. Ve a la pestaña 'Analytics & Logs' -> 'Web Analytics'.
# 3. Haz clic en 'Manage Site'.
# 4. Elimina el sitio o desactiva la inyección del script.

Si lo haces, dejarás de recibir datos de rendimiento en tu panel de control, pero la petición /cdn-cgi/rum? desaparecerá de las herramientas de red de tu navegador.

Es posible que Cloudflare cambie el nombre del endpoint o lo unifique con otros servicios de telemetría en el futuro, pero la arquitectura de «beacons» ligeros seguirá siendo el estándar de la industria para medir la experiencia de usuario sin comprometer su privacidad.