Core Web Vitals: entenda LCP, INP e CLS antes de aplicar patches

Acessibilidade e desempenho na Web · 6 min de leitura

Antes de remediar seus Core Web Vitals, identifique o que cada métrica mede e de onde vêm os dados. LCP mede a aparência do conteúdo mais qualificado visível, INP capacidade de resposta às interações e CLS estabilidade visual. Um valor incorreto não indica automaticamente sua causa. O relatório deve estar vinculado a uma página, um dispositivo e um comportamento observável antes de escolher uma intervenção.

Pontos essenciais

• LCP, INP e CLS descrevem problemas diferentes.
• As medições dos visitantes e os testes laboratoriais complementam-se.
• Uma pontuação global não substitui a leitura de cada indicador.
• Corrija uma causa documentada e verifique também a jornada do usuário.

Compreendendo os três indicadores

LCP: quando o conteúdo principal aparece

O Largest Contentful Paint mede quando o maior item de conteúdo elegível se torna visível na área exibida. Pode ser uma imagem, um bloco de texto ou conteúdo de vídeo, dependendo do definição de web.dev. Este não é o primeiro elemento visível nem o fim do carregamento da página inteira.

Portanto, comece identificando o elemento medido no celular e no computador. Não presuma que a culpa é do banner: o candidato pode mudar de acordo com o layout.

INP: a resposta visual a uma interação

A Interação com o Próximo Paint observa a latência de cliques, pressionamentos e interações do teclado durante a visita. Mede o atraso até a próxima atualização visual e mantém uma das interações mais lentas, com processamento de valores extremos. O documentação INP especifica que não mede todos os efeitos subsequentes de uma ação, incluindo operações de rede assíncronas.

Um botão que exibe rapidamente um estado de espera pode, portanto, ser responsivo, enquanto o resultado do servidor chega mais tarde. Veja as ações que realmente ajudam: abrir um filtro, alterar uma variação ou adicionar ao carrinho.

CLS: viagens inesperadas

A mudança cumulativa de layout avalia movimentos inesperados de elementos visíveis. Sua pontuação, sem unidade de tempo, retém a sequência de movimentos mais importante de acordo com janelas de medição, conforme explicado web.dev em CLS. Não é um tempo de carregamento nem de adição de todos os movimentos possíveis.

Uma imagem sem espaço reservado, fonte ou módulo inserido tardiamente são caminhos a serem examinados, e não causas demonstradas apenas pela pontuação.

Ler limites sem transformá-los em uma promessa

O Referência de Web Vitals define os seguintes limites para uma experiência classificada como boa:

Esses limites são avaliados no percentil 75, separadamente em dispositivos móveis e computadores. Isto significa que três quartos das experiências medidas têm um valor inferior ou igual ao retido. Esta não é uma média. Os três indicadores devem respeitar os seus limiares para que a avaliação global seja boa. A ausência de INP, por exemplo, falta de interações medidas, não deve ser transformada em valor zero. Isso não garante vendas ou posição adicional nos resultados de pesquisa.

Distinguir dados reais e de laboratório

No PageSpeed ​​​​Insights, os dados reais do CrUX cobrem os últimos 28 dias. Caso faltem dados na página, o relatório poderá utilizar dados de origem, que agrupam páginas da mesma origem, ou seja, mesmo protocolo, nome de host e porta. Isso não agrupa automaticamente todos os subdomínios. Se também forem insuficientes, nenhuma medição real será exibida. O Documentação do PageSpeed Insights explica estes casos: verifique sempre o perímetro antes de interpretar um valor.

O laboratório examina uma página sob condições controladas. Ajuda a reproduzir um problema e testar uma correção. Uma carga do Lighthouse sem interação não mede INP; O Tempo Total de Bloqueio ajuda no diagnóstico, mas não o substitui. O guia para discrepâncias entre laboratório e campo lembra ainda que movimentos podem aparecer mais tarde na visita, fora do teste inicial.

Exemplo ilustrativo: não resolver o problema errado

Neste exemplo fictício, uma loja percebe que um INP deve ser melhorado no celular, enquanto sua imagem principal é exibida corretamente. Reduzir ainda mais esta imagem não é uma resposta suficiente. A equipe primeiro reproduz a abertura de um filtro após o carregamento, depois pede para examinar o trabalho executado no momento desse suporte.

Uma correção de componente é testada nas mesmas condições. O filtro deve permanecer utilizável e fornecer feedback visual compreensível. Nenhum ganho numérico é assumido: as novas observações e medições são usadas para verificar a hipótese.

Lista de verificação antes de qualquer correção

• Escolha páginas representativas: categoria, produto, cesta ou solicitação.
• Anote o dispositivo, URL, escopo de dados e indicador em questão.
• ​​​​Identifique o elemento ou ação LCP associado ao problema.
• Manter um relatório inicial e etapas de reprodução.
• Formule uma hipótese técnica para verificar com o desenvolvedor.
• Testar uma modificação isolada e depois as funções em questão.
• Em seguida, acompanhe os dados reais, quando disponíveis.

Limitações e erros comuns

Comparar testes realizados em diferentes dispositivos ou configurações pode confundir o diagnóstico. A edição simultânea de múltiplas extensões evita atribuir o efeito a uma causa. Por fim, estes indicadores não controlam a acessibilidade, nem a veracidade do cabaz, nem a clareza da informação. Uma melhoria técnica deve preservar o funcionamento do site.

Perguntas frequentes

Uma boa classificação do Farol é suficiente?

Não. Ela descreve um teste de laboratório. Observe as métricas reais disponíveis e experimente as interações importantes, em vez de apenas lembrar a classificação.

A ausência de dados significa que o site é rápido?

Não. Ela indica que o relatório não possui amostra suficiente. Os testes controlados permanecem úteis, sem serem apresentados como medições dos seus visitantes.

Por que os dados reais não mudam imediatamente?

A janela do dia 28 ainda contém visitas anteriores à correção. Primeiro verifique a mudança no laboratório e depois observe a evolução sem esperar por uma mudança imediata.

Próxima etapa

Prepare um cartão com um URL, um indicador problemático e uma ação repetível. Se você solicitar 4SYSTEM, anexe o relatório e suas condições de medição. Esta base permite-nos discutir uma correcção precisa e não um pedido vago de celeridade.

Fontes e recursos

• web.dev: Web Vitals e limites.
• web.dev: definição de LCP.
• web.dev: definição de INP.
• web.dev: definição de CLS.
• web.dev: laboratório e campo.
• Google: Leia o PageSpeed Insights.