--- title: "Cloudflare BEACON: dados reais de velocidade da web" description: "A Cloudflare abriu o BEACON, dataset com bilhões de medições reais de Core Web Vitals no BigQuery, e mostra que o gargalo do LCP está no atraso de carga e de renderização." date: 2026-10-05T00:00:00.000Z --- O BEACON é um dataset aberto da Cloudflare com bilhões de medições reais de desempenho de páginas, e o dado que mais muda a rotina de quem otimiza velocidade é este: nas páginas com LCP ruim, o que pesa é descobrir e liberar a renderização do elemento principal, não baixar a imagem. A Cloudflare publicou o conjunto em 28 de setembro de 2026, no [blog da empresa](https://blog.cloudflare.com/how-fast-is-the-web/), com dados diários no Google BigQuery. Pra quem decide SEO, o ganho é ter, pela primeira vez em escala pública, os Core Web Vitals (as métricas de carga, estabilidade e resposta que o Google mede) em histograma completo, e não só o P75 que o relatório do Search Console mostra. ## O que é o Cloudflare BEACON? BEACON significa Browser Experience Across Cloudflare's Observed Network. É um conjunto anonimizado de medições de Real User Monitoring (RUM) de 10.000 dos maiores sites da rede da Cloudflare, cobrindo todos os grandes motores de navegador. Ele segue o padrão do [RUM Archive](https://rumarchive.com/), uma base pública de RUM, e a Cloudflare diz que amplia a escala desse projeto em 100 vezes. Os três Core Web Vitals estão lá: LCP (tempo de carga), CLS (estabilidade visual) e INP (resposta a interação). A diferença é que vêm como histogramas. Dá pra calcular P90 ou P95 e olhar a cauda longa, onde estão os usuários que a média esconde. Sobre privacidade, a Cloudflare remove domínio e caminho de URL, agrega registros por país, sistema, navegador e protocolo, e descarta qualquer agregado com menos de cinco registros. ## Quem enfrenta a web mais lenta? O iOS, que hoje só roda o motor WebKit, tem o melhor desempenho geral nos Core Web Vitals, mas a vantagem não é universal. Em 46 países onde o WebKit passa de 10% do tráfego, o LCP, o INP ou os dois ficam pelo menos 10% piores que os de navegadores baseados em Blink, como Chrome, Edge e Opera. No Camboja, o WebKit responde por 17,5% das visualizações de página e tem LCP 50% pior que o do Blink. Por setor, a Cloudflare usa a classificação de domínios da sua Intel API. Governo e Política, Saúde e Conteúdo Seguro pra Crianças aparecem entre os melhores. Anúncios, Religião e Clima ficam entre os piores. Nos percentis mais altos, a estabilidade visual (CLS) despenca em vários setores, algo que o P75 sozinho não mostra. ## O que deixa uma página lenta de verdade? O atraso de descoberta e o atraso de renderização do LCP pesam mais que o download do arquivo. A Cloudflare quebrou o LCP em quatro etapas e mostrou os valores por faixa de classificação: | Etapa do LCP | Good | Needs Improvement | Poor | | --- | --- | --- | --- | | Document TTFB (HTML chega) | 598 ms | 1015 ms | 1891 ms | | Load Delay (descoberta do elemento) | 76 ms | 1049 ms | 1485 ms | | Load Duration (download) | 119 ms | 199 ms | 119 ms | | Render Delay (bloqueio de renderização) | 157 ms | 437 ms | 2002 ms | ![Barras empilhadas com as quatro etapas do LCP nas faixas Good, Needs Improvement e Poor, com Load Delay e Render Delay crescendo mais](/images/cloudflare-beacon-velocidade-real-web/lcp-sub-partes.svg) A leitura da própria Cloudflare é que baixar imagem, fonte ou vídeo costuma ser a parte que menos contribui. Na faixa Poor, o Render Delay chega a 2002 ms e o Load Delay a 1485 ms, contra 119 ms de Load Duration. Pra INP vale o mesmo raciocínio, com três etapas: | Etapa do INP | Good | Needs Improvement | Poor | | --- | --- | --- | --- | | Input Delay (main thread ocupada) | 18 ms | 32 ms | 84 ms | | Processing Time (JavaScript da interação) | 55 ms | 112 ms | 284 ms | | Presentation Delay (pintar a atualização) | 56 ms | 111 ms | 217 ms | Nas interações mais lentas, a execução de JavaScript ocupa o maior intervalo, mas o tempo de apresentação também sobe bastante, em geral por recálculo de layout de CSS complexo. Na prática, isso muda a ordem da checklist. Antes de comprimir mais uma imagem, descubra se o elemento do LCP está sendo encontrado cedo (dependência de JavaScript atrasa isso) e se algo bloqueia a renderização dele. Quem usa a Cloudflare pode atacar parte do atraso de descoberta com o Smart Hints, e o Zaraz ajuda a reduzir o peso do JavaScript de terceiros, segundo a empresa. ## Navegação em SPA é mesmo mais rápida? Quase sempre, depois da primeira página. Com o suporte à Soft Navigations API do Chrome, a Cloudflare passou a medir LCP em navegações do lado do cliente, comuns em apps React, Vue, Angular e Svelte. Os valores no Blink: | Percentil do LCP | P50 | P75 | P90 | P95 | | --- | --- | --- | --- | --- | | Navegação dura (hard) | 791 ms | 1.421 ms | 2.636 ms | 4.122 ms | | Navegação suave (soft) | 274 ms | 582 ms | 1.169 ms | 1.816 ms | | Página de entrada (landing) | 1.370 ms | 2.681 ms | 5.397 ms | 8.940 ms | Navegação suave renderiza de duas a três vezes mais rápido que a dura em todos os percentis. Só que a página de entrada, que costuma ser bem mais pesada, tem P95 de 8.940 ms. Se o visitante raramente passa da primeira página, como acontece em muito blog e site de serviço local, uma carga inicial pesada pode nunca se pagar. Quem vem de busca orgânica quase sempre pousa numa página de entrada, então esse é o número que o SEO sente primeiro. Eu trabalho com SEO desde 2014 e já vi muito projeto trocar de framework pra "ganhar velocidade" e piorar justamente a primeira visita. Mede a landing antes de decidir. ## O que o BEACON mostra sobre rede e economia dos países? A Cloudflare cruzou o BEACON com o PIB per capita do Banco Mundial e com o Internet Quality Index (IQI) do Cloudflare Radar. O padrão geral é esperado: banda maior, LCP melhor. A surpresa veio do tamanho de transferência. Na África, os usuários baixam menos dados por página, o que sugere que os sites são adaptados à rede limitada, embora a Cloudflare avise que não dá pra afirmar a causa. Uma rede boa também pode perdoar um site mal otimizado, e uma rede lenta amplifica os gargalos. A empresa vai lançar uma seção de Web Performance no Radar com essas correlações. ## Como usar o BEACON no seu trabalho de SEO? O dataset está no [Google BigQuery](https://console.cloud.google.com/bigquery?ws=!1m4!1m3!3m2!1scf-open-web-performance!2srumarchive), e a Cloudflare guardou lá as consultas de todas as tabelas do post, com nomes como "Global LCP Sub-parts", "Global INP Sub-parts" e "CWVs by Industry". Dá pra adaptar cada uma. O que fazer na segunda-feira: 1. Abra o relatório de Core Web Vitals do Search Console e separe as URLs em Poor e Needs Improvement. 2. Em cada uma, descubra a etapa dominante do LCP: HTML lento, elemento descoberto tarde, ou renderização bloqueada. 3. Compare o seu P75 com a faixa do seu setor nas consultas do BEACON, em vez de comparar com a média global. 4. Em site de SPA, meça a landing separada das navegações internas. ## Resumo: o que levar do BEACON - O BEACON é público, diário e tem histogramas completos de LCP, CLS e INP, não só P75. - Nas páginas com LCP ruim, Load Delay e Render Delay somam bem mais tempo que o download do recurso. - No INP lento, JavaScript pesa mais, mas o tempo de apresentação também sobe. - Navegação suave em SPA é de duas a três vezes mais rápida, mas a página de entrada chega a 8.940 ms no P95. - O WebKit é o melhor no geral, mas em 46 países fica pelo menos 10% atrás do Blink em LCP, INP ou ambos. Pra entender como esses números entram no ranqueamento, leia o [guia dos Core Web Vitals no SEO](/blog/o-impacto-dos-core-web-vitals-no-seo-um-guia-completo/). Se a sua dúvida é o outro lado da Cloudflare, veja [como bloquear treinamento de IA sem sumir do Google](/blog/como-bloquear-treinamento-de-ia-sem-sumir-do-google-a-mudanca-que-a-cloudflare-fez-em-julho-de-2026/). E pra imagens que atrasam a página, o texto sobre [imagens para SEO e carregamento do site](/blog/como-trabalhar-com-imagens-para-seo-e-melhorar-o-carregamento-do-site/) continua valendo.