SEOArtigo
Core Web Vitals para loja virtual: o que medir e o que corrigir primeiro
Em resumo
LCP, INP e CLS medem carregamento, resposta e estabilidade da página e entram nos sistemas de classificação do Google. O ConnectWeek traz os limites de cada métrica, a diferença entre dado de campo e de laboratório, o que pesa no Google e nas vendas e a ordem de correção por modelo de página numa loja virtual.
Core Web Vitals são três medidas de experiência que o Google usa nos seus sistemas de classificação: LCP, o tempo até o maior elemento da tela aparecer (bom até 2,5 segundos); INP, o tempo de resposta a cliques, toques e teclas (bom até 200 milissegundos); e CLS, o quanto o layout se desloca durante a visita (bom até 0,1). A régua é o 75º percentil das visitas reais, com celular e computador medidos em separado. Numa loja virtual, a ordem que costuma render mais é começar pelos modelos de produto e categoria, atacar primeiro a imagem principal (LCP), depois os scripts de terceiros (INP) e, por fim, o espaço reservado para banners e fotos (CLS).
O que são as Core Web Vitals e quais são os limites?
A página do Google sobre Core Web Vitals e os resultados da Pesquisa define as três métricas e recomenda que os sites alcancem os valores bons. O relatório do Search Console usa estas faixas:
| Métrica | O que mede | Bom | Precisa melhorar | Ruim |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Carregamento do maior elemento visível | até 2,5 s | até 4 s | acima de 4 s |
| INP (Interaction to Next Paint) | Tempo entre a interação e a resposta na tela | até 200 ms | até 500 ms | acima de 500 ms |
| CLS (Cumulative Layout Shift) | Deslocamentos inesperados do layout | até 0,1 | até 0,25 | acima de 0,25 |
Segundo o guia de Web Vitals, uma página passa na avaliação quando as três métricas estão boas no 75º percentil das visitas. A INP é a mais nova: substituiu a FID em 12 de março de 2024, e mede a resposta a todas as interações da visita, não só à primeira.
Quanto elas pesam no Google e nas vendas?
O Google confirma, na página sobre experiência na página, que as Core Web Vitals são usadas pelos sistemas de classificação, mas faz duas ressalvas: resultado bom nos relatórios não garante as primeiras posições, e a busca sempre tenta mostrar o conteúdo mais relevante, mesmo que a experiência seja inferior. Em outras palavras, a experiência na página ajuda a desempatar entre páginas igualmente úteis; não compensa conteúdo fraco.
O efeito mais direto costuma estar na conversão. No caso da Vodafone publicado pelo web.dev, um teste A/B em que a versão otimizada tinha LCP 31% melhor gerou 8% mais vendas. É um caso de uma empresa, não uma regra, mas mostra por que a correção deve começar nas páginas que vendem.
Dado de campo ou de laboratório: qual olhar primeiro?
- Campo: vem de usuários reais do Chrome, pelo relatório CrUX. O PageSpeed Insights mostra os últimos 28 dias; quando a página não tem visitas suficientes, mostra o dado do site inteiro. O relatório de Core Web Vitals do Search Console agrupa páginas parecidas e dá a cada grupo o status da pior métrica.
- Laboratório: o Lighthouse simula um aparelho e uma conexão. Serve para achar a causa e testar a correção antes de publicar, mas nota alta no laboratório não garante boa experiência real.
A regra prática: a prioridade sai do dado de campo; o laboratório ajuda a descobrir o motivo. Depois de corrigir, a validação do relatório — “Iniciar rastreamento”, na ajuda do Search Console — abre um acompanhamento de 28 dias.
Por onde começar numa loja virtual?
Pense em modelos de página, não em endereços. Uma correção no modelo de produto conserta milhares de páginas de uma vez, e os grupos do Search Console costumam coincidir com esses modelos. Para decidir a ordem, veja no Google Analytics quais modelos recebem mais entradas orgânicas e mais receita.
| Modelo | Métrica que mais falha | Causa frequente | Correção |
|---|---|---|---|
| Produto | LCP | Foto principal pesada, grande demais ou carregada tarde | Imagem no tamanho exibido, formato moderno, sem carregamento lento e com prioridade alta |
| Categoria | CLS e LCP | Banner sem altura reservada e fotos da grade sem dimensões | Largura e altura declaradas nas imagens e espaço fixo para o banner |
| Busca e filtros | INP | Filtro que recalcula a página inteira a cada clique | Dividir o trabalho do JavaScript em partes menores e mostrar retorno visual imediato |
| Carrinho e checkout | INP | Scripts de chat, pixels e aplicativos carregados de uma vez | Manter só o necessário e adiar o que não é usado na etapa |
O que é verificação de pagamento e antifraude não se remove para ganhar velocidade; o equilíbrio entre segurança e atrito no checkout está no artigo sobre checkout que converte.
O que corrigir em cada métrica?
LCP: a imagem principal
O guia do web.dev para otimizar o LCP aponta dois erros comuns: marcar a foto principal com loading="lazy", o que atrasa o início do download, e não indicar prioridade. A recomendação é usar fetchpriority="high" na imagem que provavelmente será o maior elemento — em uma ou duas imagens no máximo, porque prioridade alta em muitas anula o efeito. Servir a foto no tamanho em que ela aparece e com resposta rápida do servidor completa o pacote.
INP: o JavaScript
Tarefas longas na linha principal do navegador atrasam a resposta ao clique. Em loja, os suspeitos habituais são aplicativos instalados na plataforma, chats, mapas de calor, pixels de anúncio e filtros pesados. Liste os scripts de terceiros, meça o efeito de cada um e remova o que ninguém usa.
CLS: espaço reservado
A documentação do CLS cita as causas mais comuns: imagens e vídeos sem dimensões, fontes que carregam maiores ou menores que a fonte provisória e anúncios ou widgets que mudam de tamanho. Barra de aviso de cookies e selo de frete grátis inseridos no topo depois do carregamento entram na mesma conta.
Exemplo de diagnóstico
Um caso ilustrativo, com números hipotéticos, mostra como a leitura funciona na prática:
| Etapa | O que se viu | Decisão |
|---|---|---|
| Search Console, celular | Grupo de 1.800 páginas de produto com LCP de 3,8 s | Prioridade 1: é o modelo com mais entradas orgânicas |
| PageSpeed Insights | O maior elemento é a foto principal, de 1,2 MB, marcada com carregamento lento | Tirar o carregamento lento e servir a foto no tamanho exibido |
| Lighthouse, depois da correção | Foto com 180 KB e prioridade alta | Publicar e pedir a validação no Search Console |
| Campo, 28 dias depois | LCP de 2,3 s no 75º percentil | Grupo passa para “Bom”; próximo alvo: INP da página de categoria |
O dado de campo demora a mudar porque a janela é de 28 dias: comparar antes desse prazo mistura visitas anteriores e posteriores à correção.
Rotina de acompanhamento
- Uma vez por mês, abra o relatório de Core Web Vitals do Search Console no celular e no computador e anote os grupos em “Ruim” e “Precisa melhorar”.
- Rode o PageSpeed Insights em uma página de cada modelo: início, categoria, produto e carrinho. As outras ferramentas sem custo estão em ferramentas de SEO gratuitas.
- A cada novo aplicativo, tema ou banner, teste a página de produto antes e depois da instalação.
- Registre a data de cada mudança, para relacionar ganho ou perda à causa.
Velocidade é um dos itens da checagem técnica; os bloqueios que impedem a indexação vêm antes e estão no artigo sobre SEO técnico. A escolha da plataforma também pesa no desempenho, como mostra a comparação de plataformas de e-commerce.
Onde a experiência na página entra entre os outros fatores de SEO está em o que é SEO.
Fonte: Google Search Central — Core Web Vitals e os resultados da Pesquisa Google
Perguntas frequentes
Quais são os valores bons das Core Web Vitals?
LCP de até 2,5 segundos, INP de até 200 milissegundos e CLS de até 0,1, medidos no 75º percentil das visitas reais, com celular e computador avaliados em separado. Acima de 4 segundos, 500 milissegundos e 0,25, respectivamente, o status é ruim.
Core Web Vitals melhoram a posição no Google?
Elas são usadas pelos sistemas de classificação, mas o Google avisa que bons resultados não garantem as primeiras posições e que a busca sempre tenta mostrar o conteúdo mais relevante, mesmo com experiência inferior. Pesam mais entre páginas igualmente úteis.
Qual a diferença entre dado de campo e de laboratório?
O dado de campo vem de usuários reais do Chrome, nos últimos 28 dias, e é o que define o status. O de laboratório, do Lighthouse, simula um aparelho e uma conexão e serve para achar a causa e testar a correção antes de publicar.
O que substituiu a FID nas Core Web Vitals?
A INP, Interaction to Next Paint, que substituiu a FID em 12 de março de 2024. Ela mede a resposta a todas as interações da visita, e não só à primeira, com valor bom de até 200 milissegundos.
Por onde começar a melhorar a velocidade de uma loja virtual?
Pelos modelos de página que recebem mais entradas orgânicas e receita, normalmente produto e categoria. Comece pela imagem principal, sem carregamento lento e com prioridade alta, depois reduza scripts de terceiros e reserve espaço para banners e fotos.
