Se pesquisaste «avaliação das Core Web Vitals reprovada» depois de veres uma pontuação de velocidade verde, começa por verificar que dados descreve cada resultado. O PageSpeed Insights (PSI) combina dados de visitas reais com um teste controlado separado. Regista o endereço, dispositivo, âmbito dos dados e métrica que falha antes de comprares uma ferramenta ou pedires a alguém para refazer o site.
Começamos por esse registo porque «pôr a pontuação a verde» deixa demasiadas questões em aberto. Quem desenvolve o site precisa de saber que experiência exige atenção e que provas permitirão considerar útil a correção.
Avaliação das Core Web Vitals reprovada: o que mediu o relatório?
A avaliação descreve experiências registadas dos visitantes, enquanto a secção Lighthouse executa um teste de diagnóstico. A documentação do Google sobre o PageSpeed Insights explica que os dados de campo vêm do Chrome User Experience Report, ou CrUX, e abrangem um período móvel de recolha de 28 dias. Por isso, um diagnóstico acabado de executar e esse histórico podem apresentar resultados diferentes.
As condições do teste são diferentes. Uma execução controlada não consegue abranger todos os dispositivos, ligações e ações das visitas reais. Usa-a para investigar uma possível causa; mantém os dados dos visitantes ao lado ao decidir o que continua por resolver.
O resultado pode ter um âmbito mais alargado. Se houver poucos dados da página exata, o PSI pode recorrer à origem: em termos gerais, o endereço do site com o protocolo e o nome do anfitrião. Um resultado da origem combina visitas a várias páginas. Lê o âmbito indicado antes de o tratares como prova sobre uma página específica de produto ou serviço.
O período inclui visitas anteriores. Uma alteração feita hoje não reescreve as observações de ontem. Guarda a data de entrada em produção para distinguir a verificação imediata da correção dos dados posteriores sobre os visitantes.
Estas diferenças atribuem funções distintas aos relatórios: os dados dos visitantes identificam uma experiência a investigar; um teste controlado ajuda a reproduzi-la e examiná-la.
Que métrica precisa de atenção?
Analisa LCP, INP e CLS separadamente antes de escolheres uma correção. As orientações do Google sobre Web Vitals distinguem carregamento, capacidade de resposta e estabilidade visual. A tabela apresenta os limiares bons dessas orientações, avaliados no percentil 75 para a população do dispositivo em causa. O guia de limiares do Google explica esse percentil: pelo menos 75% das visualizações de página medidas têm de cumprir o limiar bom da métrica. Isto difere de uma média ou da pontuação global do Lighthouse.
| Métrica | O que descreve | Limiar bom | O que perguntar a quem mantém o site |
|---|---|---|---|
| LCP, Largest Contentful Paint | Quando aparece o maior elemento de conteúdo visível | No máximo 2,5 segundos | Que elemento se atrasa e em que fase da sequência de carregamento? |
| INP, Interaction to Next Paint | Com que rapidez a página responde às interações | No máximo 200 milissegundos | Que toque, clique ou ação de teclado é lenta nas condições afetadas? |
| CLS, Cumulative Layout Shift | Movimentos inesperados da disposição dos elementos | No máximo 0,1 | Que elemento se move e em que momento da visita? |
Quando todas estas métricas têm dados suficientes, o PSI exige valores bons no percentil 75 para passar na avaliação. Se os dados de INP forem insuficientes, LCP e CLS bons podem ainda permitir a aprovação. Se os dados de LCP ou CLS forem insuficientes, o PSI não consegue avaliar essa página ou origem.
Trata a falta de dados como incerteza. A metodologia CrUX do Google exige visitas elegíveis e popularidade suficiente; não publica um número mínimo universal de visitantes. A ausência de resultado não indica que ninguém visita o site, que a experiência é boa ou que uma correção falhou.
O que podes verificar antes de pagar pelo trabalho?
Guarda um relatório de referência e segue o mesmo percurso do cliente num telemóvel antes de escolheres uma ferramenta. Precisas de uma descrição clara do problema: a página, os dados por trás do aviso e o comportamento que consegues reproduzir. Se não o conseguires reproduzir, regista essa limitação em vez de preencheres a lacuna com uma suposição.
- Abre no PSI a página exata relevante para o negócio. Guarda o endereço e a data do relatório. Inclui a página de destino ou o modelo de página importante para o pedido de contacto ou a compra que estás a investigar.
- Regista a seleção de telemóvel ou computador e o âmbito dos dados. Copia se a secção de dados de campo representa o URL, a origem ou dados insuficientes. Usa a mesma seleção nas comparações posteriores.
- Identifica a métrica que precisa de atenção. Usa os resultados individuais das Core Web Vitals e lê depois a secção de diagnóstico à procura de pistas. Mantém visíveis as amostras em falta.
- Executa uma tarefa real num telemóvel. Abre o menu, usa o filtro relevante ou preenche o formulário em causa. Anota o que carrega tarde, responde lentamente ou se move de forma inesperada.
- Liga uma pista a um teste. Pede a quem mantém o site para reproduzir a ação afetada ou o atraso de carregamento e explicar o que o teste pode demonstrar.
Para verificações mais amplas de imagens, widgets, cache e alojamento, consulta o nosso guia sobre as causas comuns de um site lento. Mantém a tarefa atual centrada na avaliação reprovada e nas provas necessárias para rever a correção.
O que deve incluir a correção?
Escolhe a menor alteração sustentada pelo diagnóstico e combina como a vais verificar. Começa pelos relatórios e funcionalidades que já tens. É mais fácil rever o trabalho técnico quando quem mantém o site identifica a página ou o modelo afetado, explica o ponto de estrangulamento e mantém condições comparáveis antes e depois.
- Relaciona a proposta com a métrica. O guia de LCP do web.dev distingue os atrasos de resposta, descoberta, carregamento e apresentação do maior elemento. O guia de INP centra a investigação nas interações lentas. O de CLS inclui os movimentos que ocorrem após o carregamento inicial. Pede as provas relevantes em vez de uma promessa geral de melhorar a velocidade.
- Corrige a causa identificada e volta a testar o comportamento. Uma correção específica de um recurso ou modelo pode integrar o desenvolvimento e a manutenção de sites. Regista o que mudou e quando, e anota como reverter a alteração sempre que for viável.
- Verifica se a tarefa do cliente continua a funcionar. Testa a navegação, os formulários e os passos de compra relevantes para a página. Mantém os controlos de consentimento funcionais; investiga o seu comportamento e disposição, preservando um consentimento conforme à lei.
- Decide se são necessárias mais provas. Se os relatórios disponíveis não identificarem a interação ou página afetada, medições adicionais podem ajudar. Antes de adicionares um serviço pago, pergunta a que questão responde a monitorização proposta.
Se a prioridade técnica não for clara, o trabalho de SEO técnico pode começar com um diagnóstico e uma lista de tarefas que possas rever. Um novo design ou um pacote de otimização precisa de justificação própria.
Podes copiar esta ficha e deixar em branco os campos desconhecidos:
Página e tarefa de negócio:
Dispositivo e âmbito dos dados de campo:
Métrica que precisa de atenção:
Comportamento observado e condições de teste:
Causa e alteração propostas:
Data de entrada em produção:
Verificação comparável após a alteração:
Observação de campo posterior e incerteza restante:Como verificas se o trabalho ajudou?
Analisa primeiro o comportamento alterado e compara depois os dados de campo posteriores no mesmo âmbito. Segundo a documentação, o PSI atualiza os dados de campo diariamente, mantendo uma janela móvel de recolha. Guarda a data de entrada em produção no registo. Essa janela não é uma contagem decrescente garantida até à aprovação da avaliação.
Compara a métrica escolhida e a tarefa do cliente em condições de teste semelhantes. Se o sintoma persistir, retoma o diagnóstico. Se o teste melhorar, mas os dados de campo posteriores não sustentarem a alteração, volta a investigar as páginas e as condições dos visitantes afetados. A falta de dados de campo deve continuar a ser uma limitação explícita.
Como podemos ajudar
Começamos pelo relatório, pelas páginas importantes e por uma tarefa que consigamos reproduzir. Separamos a correção proposta, a sua verificação e os dados posteriores dos visitantes, para que cada decisão tenha uma base que possas analisar. Um brief de desempenho do site pode começar com a ficha acima; mantém visíveis os campos desconhecidos.
