Por que o atraso de 28 dias do Core Web Vitals é um mito

Desmistificando o mito do atraso de 28 dias do Core Web Vitals

Ouço isso o tempo todo: "Lançamos a correção, agora temos que esperar 28 dias para ver se funcionou." Isso está errado. Os dados não têm 28 dias. Eles têm cerca de dois dias. A confusão vem de como o Google calcula os números e, uma vez que você entende isso, o pânico dos 28 dias desaparece.

Última revisão por Arjen Karel em março de 2026

Os dados do CrUX têm dois dias, não 28

O Chrome User Experience Report (CrUX) é atualizado diariamente por volta das 04:00 UTC. Quando você consulta a CrUX API, a resposta inclui um campo collectionPeriod que mostra o intervalo de datas exato. A data de término geralmente é ontem ou anteontem. Desde dezembro de 2024, o PageSpeed Insights também exibe essas datas, então você mesmo pode conferir.

Então de onde vêm os 28 dias?

O que você vê no PageSpeed Insights é o 75º percentil calculado sobre os últimos 28 dias de dados de usuários reais. O Google usa uma janela móvel de 28 dias não porque quer atrasar seus dados, mas porque isso suaviza o ruído. Um único dia ruim não afunda sua pontuação. Um único dia bom não a salva. A janela fornece uma imagem estável e representativa de como usuários reais experimentam seu site.

Todo dia, os dados do dia mais antigo saem e os dados do dia mais novo são adicionados. Não há atraso. A janela simplesmente avança, um dia de cada vez.

Uma coisa que muitas pessoas erram: este é um 75º percentil, não uma média. Vários guias populares (incluindo o da Vercel) o chamam incorretamente de média. A distinção importa. Um p75 significa que 75% das experiências do usuário estão neste valor ou abaixo dele. É mais resistente a mudanças do que uma média porque outliers no lado mais rápido não o puxam para baixo tão rapidamente.

Por que as melhorias parecem lentas

Quando você lança uma correção de performance, seus novos dados se misturam com até 27 dias de dados antigos. O 75º percentil muda gradualmente, não da noite para o dia.

Pense assim: você tem uma caixa com 28 bolas de gude vermelhas. Todo dia você tira uma bola de gude vermelha velha e a substitui por uma bola de gude verde nova. Levará 28 dias inteiros para renovar totalmente a caixa, mas nunca houve nenhum atraso!

A rapidez com que a caixa se torna predominantemente verde (o 75º percentil muda) depende de quantas bolas de gude vermelhas já estavam nela. Se o seu site era consistentemente lento, há muitas bolas de gude vermelhas para substituir. Se estava no limite, a caixa fica verde muito mais rápido.

O que esperar após lançar uma correção

Aqui está uma linha do tempo realista do que acontece após você lançar uma melhoria de performance:

• Dia 0: Você lança a correção. Nada muda no CrUX ainda.
• Dias 2-3: Os primeiros pontos de dados melhorados entram na janela de 28 dias. Se você monitorar de perto, pequenas mudanças podem aparecer.
• Dia 7: Cerca de um quarto da janela contém dados pós-correção. Tendências começam a ficar visíveis no CrUX History.
• Dia 14: Metade da janela são dados novos. Se sua correção foi significativa (digamos, o LCP caindo de 4s para 2s), o p75 terá se movido notavelmente.
• Dia 28: A janela está totalmente renovada. O CrUX agora reflete sua performance atual.

O quão dramática é a mudança depende de três coisas: o tamanho da melhoria, quanto tráfego o seu site recebe (mais tráfego significa mais pontos de dados novos por dia) e quão consistente é a correção em todos os carregamentos de página.

Três lugares, três velocidades de atualização

Nem todos os dados do CrUX são atualizados no mesmo ritmo. Esta é outra fonte de confusão:

• CrUX API e PageSpeed Insights: atualizados diariamente (atraso de ~2 dias). É o que a maioria das pessoas usa.
• CrUX History API: atualizada semanalmente às segundas-feiras, com dados até o sábado anterior. Alimenta a ferramenta CrUX History e os gráficos de tendências.
• CrUX BigQuery: atualizado mensalmente, na segunda terça-feira após o fim do período de coleta. Se você só checar o BigQuery, realmente pode parecer um atraso de um mês.

Se você está esperando impacientemente seus números mudarem, cheque o PageSpeed Insights (diariamente), não o BigQuery (mensalmente).

Não espere 28 dias. Use RUM.

Os dados do CrUX são do Google. Eles dizem como o Google vê o seu site. Mas você não precisa sentar e esperar por isso. Com o Real User Monitoring você pode rastrear os Core Web Vitals por dia ou até por carregamento de página. Você saberá em horas se a sua correção está funcionando, não em dias.

O CrUX atualmente rastreia 18,56 milhões de origens com uma taxa de aprovação no Core Web Vitals de 55,8%. Se o seu site está entre os 44% que ainda não passam, não deixe o mito do "atraso de 28 dias" impedir você de fazer mudanças. Os dados são quase em tempo real. A janela apenas os suaviza.