Cloudflare BEACON: mide la web real en BigQuery

Cloudflare BEACON: el dataset abierto que pone a prueba la velocidad real de la web

Cloudflare publicó BEACON, un conjunto de datos abierto con miles de millones de mediciones de rendimiento web recopiladas de forma anónima sobre las 10.000 webs más grandes de su red, actualizadas a diario en Google BigQuery y construidas sobre los estándares comunitarios de RUM Archive. La compañía describe la iniciativa como una expansión de 100 veces en la cobertura de proyectos similares y la presenta como una herramienta para estudiar el rendimiento web a una escala y con una diversidad geográfica y de navegadores que no había estado disponible públicamente hasta ahora.

El dato importa a cualquier fundador que venda online o tenga un SaaS: lo que tu CTO ve en el MacBook de oficina y lo que vive tu cliente en un Android de cuatro años con 2 GB de datos throttled no son el mismo internet. BEACON existe, precisamente, para cerrar esa brecha.

Qué mide BEACON (y por qué no es solo "otro reporte de velocidad")

BEACON no publica promedios: publica histogramas completos. La diferencia es enorme. Cualquier investigación o producto puede derivar el percentil que necesite, en lugar de quedarse con el P75 que reportan la mayoría de herramientas y ocultar la larga cola de usuarios que sí sufren la página lenta.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Cubre los tres Core Web Vitals definidos por Google:

Largest Contentful Paint (LCP): tiempo de carga del contenido principal.
Interaction to Next Paint (INP): capacidad de respuesta a la interacción.
Cumulative Layout Shift (CLS): estabilidad visual.

Sobre esa base, BEACON añade subpartes. En LCP separa TTFB del documento, Load Delay, Load Duration y Render Delay. En INP, Input Delay, Processing Time y Presentation Delay. Cada una tiene umbrales "Good / Needs Improvement / Poor" publicados como consultas reutilizables en BigQuery.

El hallazgo que contradice a tu equipo de frontend

Uno de los datos más disruptivos del análisis de Cloudflare es que la descarga del recurso (imagen, fuente, video) suele ser la que menos pesa en la lentitud percibida. Para la mayoría de page views que rompen el umbral "Good", las oportunidades reales están en dos sitios: descubrir antes al candidato a LCP y desbloquear su render.

Lo confirma la tabla de subpartes de LCP:

Document TTFB: 598 ms (Good) / 1.891 ms (Poor)
Load Delay: 76 ms (Good) / 1.485 ms (Poor)
Load Duration: 119 ms (Good) / 119 ms (Poor) — la descarga casi no varía
Render Delay: 157 ms (Good) / 2.002 ms (Poor)

Implicación para founders: antes de seguir comprando CDNs o comprimiendo imágenes, audita el camino crítico hasta que el navegador descubre tu LCP. Cloudflare Smart Hints ataca directamente este punto.

En INP, para las interacciones más lentas, el JavaScript execution time domina, pero aparece un actor que muchos subestiman: presentation delay, típicamente ligado a recálculos costosos de layout en CSS. Reducir el impacto del JS de terceros con herramientas como Zaraz aparece como recomendación explícita en el post.

Single Page Apps: rápidas después, lentas al inicio

BEACON también habilita la nueva Soft Navigations API de Chrome, que mide correctamente el LCP en navegaciones client-side, las que usan frameworks como React, Vue, Angular o Svelte.

Los números:

Hard Navigations P50/P75/P90/P95: 791 ms / 1.421 ms / 2.636 ms / 4.122 ms
Soft Navigations P50/P75/P90/P95: 274 ms / 582 ms / 1.169 ms / 1.816 ms

Las navegaciones suaves renderizan dos a tres veces más rápido en cada percentil. Pero la landing page pesa lo suyo: 1.370 ms en P50 y 8.940 ms en P95.

La conclusión que Cloudflare deja por escrito es directa: si tus usuarios rara vez pasan de la landing, el costo del primer render probablemente nunca se amortice con navegaciones internas más rápidas. Para una herramienta B2B donde la primera experiencia es la conversión, esto es una alerta seria.

WebKit gana en global, pero pierde en 46 países

Los navegadores con motor WebKit (es decir, todo Safari en iOS) tienen el mejor rendimiento agregado en los tres Core Web Vitals. Sin embargo, esa ventaja no es universal: en 46 países donde WebKit supera el 10% del tráfico, su LCP, INP o ambos son al menos 10% peores que los navegadores basados en Blink (Chrome, Edge, Opera).

El caso citado es Camboya: WebKit representa el 17,5% de las page views, pero su LCP es 50% peor que el de Blink. Si vendes en mercados emergentes o en Asia, ya no basta con optimizar para "Safari en un iPhone 15 sobre Wi-Fi".

Industrias y transferencia por país: dos hallazgos extra

BEACON cruza las mediciones con clasificaciones de industria del Cloudflare Intel API:

Mejor rendimiento: Gobierno y Política, Salud, Contenido apto para niños.
Peor rendimiento: Publicidad, Religión, Clima.

Al unir BEACON con el GDP per cápita del World Bank y con el Internet Quality Index (IQI) de Cloudflare Radar, el equipo encontró que África muestra un transfer size visiblemente menor, lo que sugiere que las empresas del continente adaptan sus sitios a las limitaciones de ancho de banda. La hipótesis inversa también aparece en el análisis: las redes rápidas suelen perdonar sitios mal optimizados, mientras que las redes lentas exacerban los cuellos de botella.

¿Qué significa esto para tu startup?

Para un founder hispano, BEACON cambia tres reglas del juego:

El percentil ya no es opcional. Un P75 "verde" en PageSpeed Insights puede esconder un P95 en rojo. Si tu modelo freemium convierte en P80, BEACON te permite auditar el percentil real donde está tu dinero.
Optimiza el camino hasta el LCP, no el LCP en sí. El cuello de botella típico no es el peso del recurso, sino el TTFB, el discovery delay y el render delay. Empieza por ahí antes de seguir tocando imágenes y fuentes.
Decide arquitectura con datos, no con hype. Si tu producto es una SPA y la mayoría de tus usuarios tocan solo la landing, el costo del bundle inicial puede superar cualquier ganancia de soft navigations. Mide el funnel antes de elegir framework.

Dos acciones concretas esta semana:

Ejecuta las consultas publicadas en BigQuery (Global LCP Sub-parts, Global INP Sub-parts, Blink Hard vs Soft) sobre los datos de tu propio producto usando el SDK de RUM de Cloudflare. Compara tus percentiles con los globales de BEACON.
Audita tu landing page con foco en document TTFB y render delay, no en peso total. Si render delay supera los 437 ms (umbral "Needs Improvement" de BEACON), tienes un target claro de optimización de CSS o hidratación.

Cloudflare construyó BEACON en su proyecto 1,111 intern, con las internes Chisara Duru y Tong Zhou. El dataset ya está disponible públicamente en BigQuery y la nueva sección de Web Performance en Cloudflare Radar lo conectará con IQI en las próximas semanas.