BEACON de Cloudflare: lo que 10.000 sitios de datos reales dicen sobre dónde se va tu LCP y tu INP

El 28 de septiembre de 2026 Cloudflare publicó BEACON: miles de millones de mediciones anónimas de usuarios reales de los 10.000 sitios más grandes de su red, gratis en Google BigQuery. Y sus tablas de sub-partes dicen algo incómodo para la mayoría de auditorías de rendimiento: en la banda "Poor", la descarga del recurso promedia 119ms — exactamente lo mismo que en la banda "Good" — mientras el render delay llega a 2.002ms y el main thread se come 284ms de cada interacción fallida. Tu imagen comprimida nunca fue el cuello de botella.

Llevamos años empezando las auditorías por el mismo sitio: "comprime las imágenes". BEACON es probablemente el dataset de campo más grande jamás abierto al público, y la fila más plana de sus tablas es justo la que más optimizamos.

Qué es BEACON (y por qué no es CrUX con otro nombre)

BEACON son las siglas de Browser Experience Across Cloudflare's Observed Network. Es un dataset anónimo construido con miles de millones de mediciones reales de rendimiento en los 10.000 sitios más grandes de la red de Cloudflare, cubre los tres grandes motores de navegador, se actualiza diariamente en Google BigQuery y sigue el estándar del RUM Archive, una base de datos comunitaria de Real User Monitoring que BEACON amplía unas 100 veces. El anuncio completo está en el blog de Cloudflare del 28 de septiembre de 2026.

La diferencia práctica con CrUX no es menor:

Un detalle que ya cambia conversaciones: BEACON publica histogramas completos, no solo el p75 de siempre. Cuando puedes mirar el p90 y el p95, descubres que en varias industrias la cola larga se desploma — sobre todo en estabilidad visual (CLS) — y esa información estaba oculta detrás de un solo número.

La tabla de LCP que debería reordenar tu auditoría

BEACON descompone el LCP en cuatro etapas y las agrega en las tres bandas de Google. Así queda:

La fila que debería molestar a cualquier agencia es la tercera: la descarga en la banda "Poor" (119ms) es idéntica a la de la banda "Good" (119ms) y menor que la de "Needs improvement" (199ms). Las páginas más lentas de la web no descargan más lento; descargan igual. Lo que las separa es que tardan 2.002ms en pintar su contenido principal y 1.485ms en siquiera descubrir qué elemento pintar.

Cloudflare lo dice sin rodeos: descargar el recurso — imagen, fuente o video — suele ser la contribución más pequeña al tiempo percibido. Las oportunidades grandes están en descubrir el candidato de LCP y desbloquear su render.

Nuestra lectura es más dura: comprimir imágenes es la tarea de rendimiento con mejor relación esfuerzo-comunicación y peor relación esfuerzo-impacto que existe. Se hace en una tarde, se demuestra en un Lighthouse, y en el campo mueve una fila que ya estaba en verde. El trabajo real — precarga, fetchpriority, quitar render-blocking, reducir TTFB con cache en el edge — es menos fotogénico y es donde están los 2.002ms.

INP: casi nunca estás esperando; estás trabajando y pintando mal

La descomposición de INP cuenta la misma historia desde el otro lado:

El input delay — la cola del main thread — apenas crece (18ms → 84ms). Lo que se dispara es procesar la interacción (284ms) y pintar el resultado (217ms). En las interacciones más lentas, la ejecución de JavaScript domina, pero Cloudflare destaca el salto de la presentation delay, típicamente dominada por recálculos de layout CSS complejos: DOM profundo, selectores caros, estilos que cambian geometría en el momento del click.

Aquí es donde nuestro artículo de debuggeo de INP con LoAF y scheduler.yield() se vuelve la capa diagnóstica natural: BEACON te dice qué etapa falla a escala de industria, LoAF te dice qué script la bloquea en tu página.

El tradeoff de las SPAs, por fin con números

BEACON también soporta la nueva API de Soft Navigations de Chrome, y los números del debate SPA vs MPA ya no son opinión:

Las navegaciones suaves son de dos a tres veces más rápidas en todos los percentiles. También: la página de aterrizaje que las hace posibles cuesta 2.681ms en p75 — casi cinco veces la navegación suave que viene después. La conclusión de Cloudflare es la que sostuvimos en nuestro análisis de las métricas de ICP y soft-navigation: si el usuario rara vez pasa de la landing, esa carga inicial más pesada nunca se paga sola. El framework híbrido — el de nuestro sitio y el de los proyectos que construimos con Astro en producción — sigue ganando esta discusión porque obtiene lo mejor de ambos lados sin forzar el debate.

Qué cambió en nuestro checklist (y el que te proponemos)

Hace ocho meses publicamos un análisis de las métricas de carga de anuncios que Chrome agregó a CrUX y ya decíamos algo parecido: el dato de campo se está abriendo capa por capa. BEACON es la capa más grande hasta ahora. Nuestro orden de auditoría quedó así:

No es que los bytes dejen de importar: en proyectos con video y galerías pesadas seguimos aplicando presupuestos estrictos de peso de página. Es que dejarlos en primer lugar era una decisión de comodidad, no de datos. Con BEACON, la conversación con el cliente cambia de "cambiemos el formato de 40 imágenes" a "tu candidato de LCP tarda 1,4 segundos en descubrirse porque depende de JavaScript".

Dónde BEACON te va a engañar si no tienes cuidado

Tres límites que tenemos presentes antes de citarlo en una reunión:

• No es tu sitio. Son los 10.000 más grandes de la red de Cloudflare, con infraestructura de nivel enterprise. Tu cliente PyME casi con seguridad no está en la muestra, y las bandas agregadas no distinguen CMS ni tecnología.
• Es un benchmark, no tu RUM. Úsalo para priorizar — si tus sub-partes de campo se parecen a la banda Poor, ya sabes dónde atacar — pero la única respuesta a "¿pasamos los Core Web Vitals?" sigue viniendo de tus propios usuarios medidos con web-vitals o tu dashboard de RUM.
• Hay interés de vendor detrás. El propio anuncio recomienda Smart Hints para el descubrimiento de recursos y Zaraz para el JavaScript de terceros. Los datos son abiertos y verificables; las soluciones que sugiere son suyas. Lee ambos con la misma calma.

Qué hacer esta semana con BEACON

Abre el dataset en BigQuery (Cloudflare incluye las consultas de todos los artículos de esta serie como plantillas), corre las tablas de sub-partes de LCP e INP, y compáralas con tus propios percentiles de campo. Si tu página parece la banda "Good" de BEACON, déjala como está y dedica el tiempo a lo que sí falla. Si se parece a la "Poor", ya tienes el orden de ataque: descubrimiento, render, main thread — y los bytes, al final.

La pregunta ya no es si tu web es rápida en tu laptop. Es si los datos abiertos de 10.000 sitios dicen que lo es para todo el mundo.