Relatório de Core Web Vitals

O relatório das Core Web Vitals mostra o desempenho das suas páginas com base em dados de uso reais, também chamados de dados de campo.

ABRIR RELATÓRIO

Entender o relatório

O relatório de Core Web Vitals mostra o desempenho de URLs agregado por status ("Ruim", "Melhorias necessárias", "Bom"), tipo de métrica (CLS, INP, LCP) e grupos de URLs (grupos de páginas da Web semelhantes).

O relatório é baseado em três métricas conforme a avaliação dos dados reais do usuário: LCP, INP e CLS. Quando um grupo de URLs atinge o limite de dados para LCP e CLS, o status dele é a métrica com pior desempenho. Por exemplo, se um grupo de URLs tiver CLS ruim, mas INP bom, o status do URL vai ser "Ruim".

Se um grupo de URLs não tiver uma quantidade mínima de dados sobre LCP e CLS, o URL vai ser omitido do relatório.

Somente os URLs indexados aparecem nesse relatório. Os dados são atribuídos ao URL real, e não ao canônico como ocorre na maioria dos outros relatórios.

Os dados são combinados para todas as solicitações de todos os locais. Se você tiver uma grande quantidade de tráfego em um país com conexões de Internet lentas, por exemplo, seu desempenho geral vai diminuir. Detalhe o desempenho por país usando o BigQuery se suspeitar que isso pode ser a causa da baixa performance.

Como navegar no relatório

Para cada plataforma (dispositivo móvel ou computador), o relatório mostra uma tabela de URLs com status "Ruim" ou "Melhorias necessárias" (Por que os URLs não foram considerados bons) e outra tabela de URLs com LCP, INP e CLS bons (Ver dados sobre URLs adequados).

1. Veja um gráfico de tendências gerais para todas as plataformas na página de destino.
2. Veja os detalhes por plataforma (dispositivo móvel ou computador) clicando em Abrir relatório ao lado de um dos gráficos.
3. Para ver o desempenho dos URLs do seu site com base nos dados históricos do usuário, alterne entre as guias "Ruim", "Melhorias necessárias" ou "Bom" no gráfico de desempenho.
4. Veja a lista de problemas de desempenho na tabela Por que os URLs não foram considerados bons. Cada URL exibido é um representante de um grupo de URLs diferente.
5. Clique em um URL na tabela Exemplos da página de detalhes do problema para ver mais informações sobre esse grupo de URLs.

Origens de dados do relatório

Os dados do relatório de Core Web Vitals são provenientes do relatório CrUX. O relatório CrUX coleta métricas anônimas sobre os tempos de desempenho de página de usuários reais (chamados de dados de campo). Esse banco de dados coleta informações sobre URLs mesmo que eles não sejam parte de uma propriedade do Search Console.

Status do grupo: Ruim, Melhorias necessárias, Bom

Os rótulos Ruim, Melhorias necessárias e Bom são aplicados a um grupo de URLs em um tipo de dispositivo específico. Um grupo de URLs sem dados de limite para LCP e CLS não vai estar no relatório. Por exemplo, se o URL tiver dados de limite apenas para LCP, mas não para CLS, ele não será exibido.

Por padrão, o status de um grupo de URLs é o mais lento atribuído a esse tipo de dispositivo. Por exemplo: 

• um URL em dispositivos móveis com CLS Ruim, mas com LCP Melhorias necessárias, é rotulado como Ruim nesse ambiente;
• um URL em dispositivos móveis com LCP Melhorias necessárias, mas com CLS Bom, é rotulado como Melhorias necessárias nesse ambiente;
• um URL com LCP, INP e CLS Bom em dispositivos móveis e LCP, INP e CLS Melhorias necessárias no computador é Bom em dispositivos móveis e Melhorias necessárias no computador.

Definições de status

Veja os intervalos de desempenho de cada status:

• LCP (maior exibição de conteúdo): é a quantidade de tempo para renderizar o maior elemento de conteúdo visível na janela de visualização, desde a solicitação do URL pelo usuário. O elemento maior normalmente é uma imagem ou um vídeo, ou talvez um elemento de texto grande no nível do bloco. Essa métrica é importante porque indica a rapidez com que um visitante vê que o URL está sendo carregado.
  • A LCP agregada mostrada no relatório é o tempo que leva para que 75% das visitas a um URL do grupo cheguem ao estado da LCP.
• INP (Interaction to Next Paint): uma métrica que avalia a capacidade de resposta geral de uma página em relação às interações do usuário, observando o tempo que leva para a página para responder a todas as interações de clique, toque e teclado que ocorrem durante a vida útil da visita de um usuário a uma página. O valor final da INP é a interação mais longa observada, ignorando os valores atípicos. 
  • A INP agregada mostrada no relatório significa que 75% das visitas a um URL do grupo atingiram um valor igual ou superior.
• CLS (Cumulative Layout Shift): a CLS mede a soma total de todas as pontuações de mudanças de layout individuais para cada alteração inesperada ocorrida durante toda a vida útil da página. A pontuação é zero para qualquer número positivo, em que zero significa ausência de deslocamento. Além disso, números maiores indicam que mais movimentações de layout ocorreram na página. Isso é importante porque, quando os elementos das páginas mudam enquanto o usuário tenta interagir com eles, a experiência é prejudicada. Se você não conseguir descobrir o que pode ter gerado um valor alto, tente interagir com a página para ver como isso afeta a pontuação.
  • A CLS agregada mostrada no relatório é a mais comum em 75% das visitas a um URL no grupo.

Veja recomendações para corrigir esses problemas com um teste externo.

Grupos de URLs

Os URLs no relatório são agrupados em páginas que têm uma experiência do usuário semelhante. Os status de LCP, INP e CLS se aplicam a todo o grupo. Alguns URLs discrepantes talvez tenham valores melhores ou piores em algumas visitas, mas 75% das visitas a todos os URLs do grupo tiveram o status mostrado. Podemos presumir que esses grupos têm uma estrutura comum, e um comportamento ruim do grupo é provavelmente causado pelos mesmos motivos.

Para respeitar a privacidade do usuário, um grupo de URLs precisa ter uma quantidade mínima de dados para aparecer no relatório. Se um grupo de URLs não tiver informações suficientes para exibir no relatório, o Search Console vai criar um grupo de origem de nível superior com dados e URLs suficientes para mostrar no relatório. Esse grupo de origem contém dados de todos os URLs no mesmo grupo de protocolo://host:porta. Por exemplo, se o URL https://m.example.com/a/b/c.html fizer parte de um grupo que não tenha dados suficientes para exibir, o Search Console vai criar o grupo de origem https://m.example.com. Esse grupo de origem contém dados de todos os URLs em https://m.example.com, mesmo se o URL também pertencer a um grupo com dados suficientes.

Algumas observações:

• A definição do grupo de origem inclui o protocolo. Ou seja, http://m.il.example.com e https://m.il.example.com são grupos de origens diferentes.
• O grupo de origem contém dados de todos os URLs com a mesma origem, não importa se o URL faz parte ou não de outro grupo mostrado no relatório.
• Se o grupo de origem não tiver dados suficientes, ele não vai ser exibido. Como consequência disso, o site não terá dados suficientes para o relatório, a menos que haja vários grupos de origem.
• Você vai poder ver os dados do grupo de origem, mesmo que ele não esteja na propriedade atual. No entanto, só é possível ver URLs de exemplo que estão na propriedade atual.
• O Search Console lista os membros do grupo classificados por impressões e em ordem decrescente.

Corrigir os problemas

O status do meu site mudou, mas não alterei nada nele

Se você não mudou nada no site, mas vê uma grande diferença no status de várias páginas, é possível que o status de muitas delas estivesse no limite e que algum evento em todo o site tenha feito com que elas ultrapassassem o nível. Por exemplo, o tráfego do site aumentou drasticamente, ou houve uma variação na latência do serviço que exibe os arquivos de imagem, o que pode deixar o site mais lento. Ainda que pequena, uma mudança em todo o site pode ser suficiente para mudar o status de várias páginas limítrofes de "Bom" para "Melhorias necessárias" ou de "Melhorias necessárias" para "Ruim".

Outra razão possível, embora menos provável, é uma mudança em grande escala nos clientes. Por exemplo, talvez haja uma atualização de versão do navegador amplamente adotada ou um afluxo de usuários em uma rede mais lenta. O desempenho é medido pelos dados de uso reais. Confira seus registros para ver se alguma mudança de navegador, dispositivo ou local coincide com as variações de status do site.

Consulte os dados de tráfego do site durante esse período para ver se há grandes oscilações. Além disso, analise os problemas específicos e os valores agregados de LCP/FCP/INP das páginas afetadas. Se esses números estiverem no limite de Ruim/Melhorias necessárias/Bom, talvez uma pequena mudança os tenha levado a um novo status.

Validar correções

Depois de corrigir um problema específico em todos os URLs, confirme se o erro foi totalmente resolvido. Clique em Iniciar rastreamento e abra uma sessão de monitoramento de 28 dias para conferir se há instâncias desse problema no seu site. Se o problema não estiver presente em nenhum URL do seu site durante o período de 28 dias, ele vai ser considerado como corrigido. A presença desse problema em qualquer URL é suficiente para marcá-lo como não corrigido. No entanto, o status dos URLs individuais continuará sendo avaliado durante os 28 dias, independentemente do status do problema.

• Para ver os detalhes de validação de uma solicitação em andamento ou com falha, faça o seguinte:
  • Clique em Ver detalhes na seção de status de validação da página de detalhes do problema.
• Para reiniciar o período de rastreamento de validação a qualquer momento, faça o seguinte:
  • Abra a página de detalhes de validação e clique em Iniciar nova validação.
• Se houver falha na validação, faça o seguinte:
  1. Tente corrigir os problemas novamente.
  2. Abra a página de detalhes de validação e clique em Iniciar nova validação para reiniciar o período de rastreamento.

Status de validação do problema

Esse é o status da solicitação de validação completa exibido para cada problema na página de resumo, bem como na página de detalhes.

Os seguintes status de validação são possíveis:

• Não foi iniciado: há um ou mais URLs com uma instância desse problema que nunca estiveram em uma solicitação de validação.
• Iniciado: você iniciou uma tentativa de validação e ainda não foram encontradas as instâncias remanescentes do problema.
• Tudo certo até agora: você iniciou uma tentativa de validação, e todas as instâncias do problema detectadas até agora foram corrigidas.
• Aprovado: todos os URLs estão no estado "Aprovado". Provavelmente, você clicou em Validar a correção para chegar a esse estado. Se as instâncias tivessem desaparecido sem que você tivesse solicitado a validação, o estado teria mudado para "N/D".
• N/D: o Google descobriu que o problema foi corrigido em todos os URLs, mesmo que você nunca tenha iniciado uma tentativa de validação.
• Falha: um ou mais URLs estão no estado "Falha" após uma tentativa de validação.

Status de validação do URL

Este é o status de cada URL na página de andamento da validação. Os estados "Pendente", "Aprovado" e "Falha" ficam visíveis durante um período de validação ativo. "Falha" é o único status visível após o término do período. Os itens corrigidos são removidos da lista após a validação.

• Pendente: o Google está aguardando dados suficientes para determinar se esse URL ainda está sendo afetado ou não.
• Aprovado: parece que o URL não é mais afetado pelo problema.
• Falha: o URL ainda é afetado pelo problema listado.

Os status de URL Aprovado e Falha só podem ser atingidos durante um período de rastreamento de validação. Se o problema aparecer e desaparecer do URL fora de uma solicitação de validação, o URL vai ser removido da lista sem um status.

Todos os URLs que foram removidos da Web e não têm dados nos últimos 28 dias não aparecerão mais no histórico de validação nem no relatório.