Core Web Vitals: dados insuficientes no Search Console

O que significa "Dados de utilização insuficientes"

O relatório Core Web Vitals no Search Console mostra a experiência de utilizadores reais do Chrome nas suas páginas. Sempre que alguém carrega uma das suas páginas no Chrome com as definições certas, o LCP, o INP e o CLS dessa visita são enviados para a Google e vão parar a um conjunto de dados público chamado Chrome User Experience Report, ou CrUX para abreviar. O Search Console lê esse conjunto de dados e mostra-lho. Ao contrário do que a maioria pensa, o Search Console não mede o seu site visitando-o. Apenas recolhe dados de utilizadores reais.

Quando não há visitas suficientes para as suas páginas, não há nada para mostrar. É aí que surge "Dados de utilização insuficientes nos últimos 90 dias para este tipo de dispositivo" para telemóvel ou computador, por vezes em ambos.

Há quem veja isto como um mau sinal, mas a falta de dados não diz se o seu site é rápido ou lento. A Google não viu visitantes suficientes para dizer o que quer que seja.

Porque é que o CrUX não tem dados do seu site

A razão principal é o tráfego. O CrUX só apresenta relatórios de uma página ou de uma origem (protocolo mais domínio, ou seja, https://www.example.com) quando esta é "suficientemente popular". O que isso significa exatamente, a Google não diz. A página da metodologia diz apenas que o limiar é suficientemente alto para garantir confiança na distribuição.

Para começar, apenas uma pequena parte dos visitantes conta para esse limiar. O CrUX recolhe dados de quem usa o Chrome com as estatísticas de utilização ativadas, sincroniza o histórico de navegação e não tem uma frase de acesso de sincronização. Isto resume-se ao Chrome no computador e ao Chrome em Android. O Chrome no iPhone não é contabilizado (por baixo é WebKit, tal como o Safari), e o próprio Safari, o Firefox, o Edge e o browser na app do Instagram também não contam. Num site com muito tráfego de iPhone, a maioria dos visitantes nunca chega a entrar no conjunto de dados. O telemóvel e o computador também são contabilizados em separado, pelo que pode ter dados no computador e não ter no telemóvel, ou o contrário. O dispositivo com menos tráfego do Chrome fica sem dados primeiro.

Depois, a própria página tem de ser elegível. Tudo o que devolva um código diferente de 200 após os redirecionamentos é ignorado. Páginas com uma meta tag noindex ou com o cabeçalho X-Robots-Tag: noindex também são ignoradas. Além disso, o Search Console impõe uma regra própria: apenas os URL efetivamente indexados aparecem no relatório.

E se acabou de adicionar a propriedade ao Search Console, não verá nada durante algum tempo. Isso resolve-se sozinho assim que a Google a processar.

Páginas sem dados herdam a pontuação da origem

O Search Console também não apresenta relatórios de páginas individuais: agrupa URL semelhantes. Quando um grupo não tem dados próprios suficientes, o Search Console faz fallback para a origem — ou seja, todos os URL no mesmo protocolo, host e porta. Assim, uma página que o CrUX nunca viu pode aparecer no relatório como Boa ou Fraca, porque vai buscar o valor ao resto do site.

Na prática, a homepage e o blog recebem a maior parte do tráfego, por isso decidem esse valor da origem. As páginas de produto ou o checkout podem ser muito mais lentos e nunca verá isso no Search Console. É também por este motivo que nunca uso o valor global do CrUX como meta: é ponderado pelo tráfego, pelo que as páginas com mais visitas decidem o resultado — e essas não são necessariamente as páginas que mais lhe interessam.

O Lighthouse não ajuda aqui

O conselho habitual em todo o lado é correr o PageSpeed Insights ou o Lighthouse até surgirem dados no CrUX. Percebo a sugestão, mas não lhe dá o que precisa. Um teste no Lighthouse carrega a página uma única vez, num telemóvel simulado, com uma ligação limitada e a cache vazia. É útil para encontrar problemas na própria página, mas não diz nada sobre o que os visitantes recebem.

O INP, por exemplo, precisa de utilizadores reais a clicar e a tocar no ecrã em dispositivos reais; o Lighthouse não clica em nada. No caso do CLS, o Lighthouse deixa de analisar assim que a página termina de carregar. Um anúncio tardio a empurrar o conteúdo para baixo ou algo que salta quando o visitante faz scroll nunca chega ao relatório. E o LCP depende do telemóvel, da ligação e da distância do visitante à CDN — um único teste só tem um de cada.

Ficar à espera só funciona se o tráfego estiver a crescer. O CrUX analisa os últimos 28 dias de visitas (o atraso é muito menor do que se pensa, já agora; veja porque é que o atraso de 28 dias é um mito). Se não teve visitas elegíveis suficientes no Chrome este mês, provavelmente também não as terá no próximo.

Meça os seus próprios visitantes com RUM

A alternativa é fazer a medição diretamente. O Real user monitoring, ou RUM, corre um pequeno script no browser de cada visitante, mede os Core Web Vitals dessa visita e envia-lhe os números a si em vez de à Google. É o mesmo tipo de field data do CrUX, mas sem qualquer limiar a atingir e sem se limitar a utilizadores do Chrome.

Uma página com 50 visitas por mês passa a ter dados. Os visitantes em iPhone também: o Safari mede o LCP e o INP desde o Safari 26.2 (dezembro de 2025), pelo que passam a surgir no RUM enquanto o CrUX continua a deixá-los de fora. Também vê que elemento causou um mau resultado: a imagem que foi o LCP ou o botão que demorou a responder. Após um deploy, vê o efeito em minutos, em vez de o procurar algures numa média de 28 dias.

O Core/Dash é a ferramenta de RUM que criei para isto. Uma tag de script, ou o plugin para WordPress, e os dados começam a entrar logo na primeira pageview. Não define cookies nem recolhe dados pessoais, pelo que não precisa de banner de consentimento. Num site pequeno isso importa: um script de RUM condicionado por um banner de consentimento só mede as pessoas que clicam em aceitar, e aí volta a ter apenas uma fração dos visitantes. Os planos começam nos 16 $ por mês com faturação anual e o teste de 14 dias não exige cartão de crédito.

Mantenha-o ativo mesmo depois de o CrUX começar a detetar o seu site. O Search Console só mostra grupos de URL; nunca lhe dirá que página ou elemento tornou um grupo lento.

Veja o que o CrUX tem sobre o seu site neste momento

Antes de alterar o que quer que seja, confirme se o CrUX tem sequer a sua origem. A ferramenta CrUX History no corewebvitals.io mostra o histórico do CrUX para qualquer site. Se aí não houver dados para telemóvel, o Search Console também estará vazio.

Consulte também: a instalação do Core/Dash, a dimensão de browser para os visitantes que o CrUX deixa de fora, e a dimensão de tipo de dispositivo para separar telemóvel e computador.

Fontes: Ajuda do Search Console: relatório Core Web Vitals, metodologia do CrUX, Safari 26.2 adiciona LCP e INP.