Guias

Executa o Lighthouse, obtém 100, publica. Um mês depois o Search Console diz-lhe que esse mesmo URL não passa na avaliação de Core Web Vitals. Nada se partiu entretanto, e nenhuma das duas ferramentas mente. Respondem a perguntas diferentes.

A documentação do Google traça a linha sem ambiguidade. Os dados de laboratório são **«dados recolhidos num ambiente controlado, com definições de dispositivo e de rede predefinidas»**. Os dados de campo são **«dados recolhidos dos utilizadores reais que visitam o seu site»**, aquilo a que também se chama Real User Monitoring; para os Core Web Vitals provêm do Chrome User Experience Report.

Os dados de campo são uma distribuição, não um número

A consequência mais importante é estrutural, e é a que mais escapa: os dados de campo **não são um número único**. São uma distribuição. As ferramentas que publicam uma pontuação de campo dos Core Web Vitals tomam o **percentil 75** dos carregamentos reais numa janela móvel de **28 dias**. O seu teste em laboratório é um carregamento, num dispositivo, numa ligação. A sua pontuação de campo é o que três quartos dos seus visitantes viveram ou melhor, ao longo de um mês.

Só isso já explica a maior parte da diferença. Mas as causas variam consoante a métrica, e saber qual está a olhar indica onde procurar.

Porque divergem, métrica a métrica

No [Largest Contentful Paint](/pt/articles/o-que-e-o-largest-contentful-paint-lcp), o próprio elemento LCP pode não ser o mesmo. O tamanho da janela de visualização, o conteúdo personalizado, os testes A/B, os tipos de letra instalados e os fragmentos de URL podem todos alterar que elemento conta como o maior. O estado da cache também difere: um teste de laboratório arranca a frio, ao passo que quem regressa pode ter recursos em cache. E a restauração a partir da cache de avanço/retrocesso é quase instantânea para um utilizador real, algo que nenhum teste de laboratório reproduz.

• Laboratório: ambiente controlado, dispositivo e rede predefinidos, uma execução, reproduzível
• Campo: utilizadores reais, dispositivos reais, ligações reais, publicado no percentil 75 sobre 28 dias móveis
• Métricas apenas de laboratório: Speed Index, Total Blocking Time (diagnósticos, não Core Web Vitals)
• O estado da cache, a cache de avanço/retrocesso, a janela de visualização e a personalização diferem entre os dois
• Google: quando se dispõe de ambos, dar prioridade aos dados de campo

No [Interaction to Next Paint](/pt/articles/o-que-e-o-inp-interaction-to-next-paint) a razão é mais funda: um teste de laboratório **não pode saber quando um utilizador decidirá interagir**, nem com o quê. É por isso que existe o [Total Blocking Time](/pt/articles/o-que-e-o-total-blocking-time) como aproximação do lado do laboratório, e é também por isso que essa aproximação é imperfeita. O TBT não capta o atraso de 300 ms ao toque que ainda afeta as páginas sem uma janela de visualização otimizada para telemóvel.

No [Cumulative Layout Shift](/pt/articles/o-que-e-o-cls), o laboratório costuma observar apenas os deslocamentos acima da dobra e durante o carregamento. Os utilizadores reais deslocam a página. As imagens e iframes de carregamento diferido sem dimensões reservadas deslocam a página muito depois de o teste de laboratório ter deixado de olhar, e os anúncios tal como os blocos personalizados assentam de forma diferente para cada um.

Qual o Google publica realmente

Sobre qual agir, então? O Google responde com clareza: **se dispõe de ambos, são os dados de campo que devem orientar as suas prioridades.** São eles que a avaliação de Core Web Vitals reporta, e os Core Web Vitals fazem parte do sinal de experiência na página. Uma pontuação de laboratório a verde é uma hipótese. Os dados de campo são o veredicto.

O laboratório não é inútil, é diagnóstico

Isso não torna o laboratório inútil, e acreditá-lo é o erro simétrico. Os dados de campo dizem-lhe **que** existe um problema e para quem; não lhe dirão que script bloqueou a linha de execução principal. As ferramentas de laboratório são reproduzíveis e atribuíveis, que é exatamente o que é preciso assim que o campo apontou uma página. Algumas métricas, entre as quais o [Speed Index](/pt/articles/o-que-e-o-speed-index) e o Total Blocking Time, existem apenas em laboratório e são diagnósticas por construção.

O ponto cego: quando o CrUX não tem nada sobre si

Vale a pena conhecer um limite antes de se apoiar inteiramente no campo. O CrUX recolhe apenas a partir do Chrome, e não a partir do Chrome no iOS nem das WebView do Android. Conta apenas os utilizadores que ativaram o envio de estatísticas de utilização, sincronizam o histórico de navegação e não definiram uma frase-passe de sincronização. A página tem de ser publicamente detetável e tem de ultrapassar um número mínimo de visitantes que o Google deliberadamente não publica. Uma página abaixo desse limiar simplesmente não tem dados de campo, e um site jovem ou com pouco tráfego pode não os ter em lado nenhum. É essa a lacuna que o seu próprio Real User Monitoring preenche: as suas páginas, todos os navegadores, desde a primeira visita e não desde a milésima.

A ordem que funciona

A ordem prática é, portanto: ler o campo para decidir **onde** trabalhar, usar o laboratório para descobrir **o que** mudar, e voltar ao campo vinte e oito dias depois para confirmar que se mexeu mesmo. Tudo o resto é otimizar um número que ninguém vive. Para as alavancas concretas, assim que souber onde escavar, comece por [melhorar os seus Core Web Vitals](/pt/articles/melhorar-os-core-web-vitals).