A cliente abre a loja pelo celular, no ônibus, com o sinal oscilando. A foto do produto demora a aparecer. Ela toca em "tamanho M" e nada acontece. Toca de novo, e o botão de comprar, que estava ali, desce porque um banner de cupom entrou no topo da tela. Ela fecha a aba. Nenhum relatório de vendas vai registrar esse momento, mas ele acontece todos os dias em muitas lojas.
Core Web Vitals são as três métricas que o Google usa para medir exatamente esse tipo de experiência: LCP, para carregamento, INP, para resposta a toques e cliques, e CLS, para estabilidade visual. Para um e‑commerce, elas ajudam a explicar por que uma loja parece lenta, por que o botão de compra demora a reagir ou por que a página pula na hora do clique. Este checklist de 15 minutos mostra o que medir, onde medir e o que corrigir primeiro, sem precisar ser desenvolvedor para começar. No fim, mostramos os erros mais comuns e como transformar a revisão em rotina.
Core Web Vitals para e‑commerce: o que são e quais limites buscar
Cada métrica olha para um momento diferente da visita. Os limites abaixo são os publicados pelo Google como "bons", e a avaliação considera o 75º percentil das visitas reais, ou seja, pelo menos três em cada quatro visitas precisam ficar dentro do limite.
- LCP (Largest Contentful Paint): tempo até o maior elemento visível aparecer, geralmente a imagem principal do produto ou o banner da home. Bom: até 2,5 segundos.
- INP (Interaction to Next Paint): quanto a página demora para responder visualmente a cliques e toques, como escolher um tamanho, abrir o menu, aplicar um filtro ou adicionar ao carrinho. Bom: até 200 milissegundos. O INP substituiu o antigo FID como métrica oficial de resposta em 2024.
- CLS (Cumulative Layout Shift): quanto o conteúdo se desloca enquanto a página carrega. Bom: até 0,1.
Em uma loja, essas métricas não são abstrações técnicas. Elas fazem parte dos sinais de experiência de página considerados pelo Google, mas o efeito mais direto está na própria venda: uma vitrine que demora a aparecer, um filtro que trava ou um botão que muda de lugar no momento do toque são experiências que qualquer cliente reconhece, mesmo sem saber o nome delas. E, ao contrário de muitas otimizações de conversão, essas podem ser medidas com ferramentas públicas e gratuitas.
Minutos 0 a 5: onde medir os Core Web Vitals da loja
Existem dois tipos de dado, e é importante não confundi-los.
- Dados de campo vêm de visitas reais de usuários do Chrome, reunidos no relatório público CrUX (Chrome User Experience Report) em uma janela móvel de 28 dias. Eles mostram a experiência real dos seus clientes.
- Dados de laboratório vêm de uma simulação feita na hora, em condições controladas, pelo Lighthouse. Eles ajudam a encontrar a causa dos problemas e a confirmar uma correção.
O roteiro dos primeiros cinco minutos
- Abra o PageSpeed Insights e teste três páginas: a home, uma página de categoria com muitos produtos e uma página de produto que venda bem. Cada tipo de página tem problemas diferentes, e a de produto costuma ser a que mais importa para a venda.
- Olhe primeiro o bloco de dados de campo. Se ele aparecer, mostra como os seus clientes de verdade estão vivendo a página. Se não aparecer, a página não tem tráfego suficiente no relatório; use o dado agregado da origem (o site inteiro) e o laboratório como apoio.
- Confira o relatório de Core Web Vitals no Google Search Console. Ele agrupa URLs parecidas e mostra quais grupos estão bons, precisando de melhoria ou ruins, separados entre celular e computador. É a melhor visão do site como um todo.
- Comece pelo celular. É onde a maior parte das lojas tem os piores números e onde a paciência do cliente é menor.
- Anote tudo. Uma planilha simples com página, dispositivo, LCP, INP, CLS e data. Sem esse ponto de partida, não dá para saber se a correção funcionou.
Um detalhe importante: o laboratório não mede o INP diretamente, porque não há uma pessoa real clicando. Ele mostra o Total Blocking Time, que é um bom indicador do mesmo problema. Para INP real, o dado de campo é a referência.
Minutos 5 a 10: o diagnóstico de LCP, INP e CLS
Com os números em mãos, desça até as recomendações do PageSpeed Insights e procure as causas abaixo. Elas respondem pela maior parte dos problemas em lojas virtuais.
LCP: o que atrasa o conteúdo principal
- A imagem principal é pesada demais ou está em um formato antigo? Formatos como WebP e AVIF costumam reduzir bastante o peso sem perda visível.
- A imagem do banner ou do produto está com carregamento preguiçoso (lazy loading)? A imagem principal deve carregar logo, de preferência com prioridade alta, e não depois do resto.
- O banner da home é um carrossel com várias imagens grandes carregando ao mesmo tempo?
- O servidor demora a responder? O tempo até o primeiro byte entra na conta do LCP, e aqui a hospedagem, o cache e a CDN fazem diferença.
- Fontes, CSS e scripts bloqueiam a renderização no topo da página?
INP: o que deixa a página lenta para responder
- Quantos scripts de terceiros a loja carrega? Pixels de mídia, chats, avaliações, ferramentas de teste A/B, recomendação, pop-ups e tags de afiliados somam trabalho no navegador.
- Há tarefas longas de JavaScript na hora de abrir o menu, aplicar um filtro, trocar a variação do produto ou adicionar ao carrinho? O painel de desempenho do Chrome DevTools mostra isso.
- Algum script roda em todas as páginas, mesmo sendo necessário só em uma?
- Os filtros da categoria recarregam a página inteira, ou fazem muito processamento a cada clique?
CLS: o que faz a página pular
- Imagens e banners sem largura e altura definidas, ou sem proporção reservada.
- Barras de aviso, cupons, banners de cookies e pop-ups que entram empurrando o conteúdo.
- Vitrines, avaliações e recomendações que carregam depois e deslocam o que já estava na tela.
- Selos de frete ou de parcelamento que aparecem só quando o cálculo termina.
- Troca de fonte que muda o tamanho dos textos durante o carregamento.
O que costuma pesar em cada tipo de página
Na home, o vilão costuma ser o banner principal e o excesso de vitrines. Na categoria, a grade de produtos com muitas imagens e os filtros. Na página de produto, a galeria de fotos, as avaliações que carregam depois e os blocos de "compre junto". No carrinho e no checkout, os scripts de pagamento, antifraude e cálculo de frete. Olhar por tipo de página ajuda a corrigir o componente certo uma vez, em vez de corrigir página por página.
Minutos 10 a 15: o que corrigir primeiro
Com a lista de problemas em mãos, priorize pelo impacto na venda e pelo esforço de correção. Na nossa experiência, esta ordem costuma funcionar bem para lojas:
- Página de produto no celular. É onde a decisão de compra acontece. Comece pelo LCP da imagem principal e pelo CLS em volta do preço e do botão de compra.
- Imagens. Compressão, formatos modernos, tamanhos responsivos e proporção reservada resolvem boa parte do LCP e do CLS com pouco risco. Se o time de marketing sobe imagens direto da câmera, crie uma regra ou uma conversão automática.
- Scripts de terceiros. Faça um inventário, pergunte a cada área se ainda usa cada ferramenta, remova o que ninguém usa e adie o que não precisa carregar no início. Costuma ser a maior alavanca para o INP.
- Elementos que entram depois. Reserve espaço para barras promocionais, avaliações, selos e vitrines dinâmicas, para que eles apareçam sem empurrar nada.
- Servidor e cache. Se o tempo de resposta do servidor é alto em todas as páginas, nenhum ajuste de front-end resolve sozinho.
Depois de cada correção, use o laboratório para confirmar o efeito na hora. Como os dados de campo levam até 28 dias para refletir totalmente uma mudança, acompanhe o campo nas semanas seguintes e compare com a planilha do ponto de partida. No Search Console, é possível pedir a validação de um grupo de URLs depois de corrigido.
Erros comuns ao otimizar Core Web Vitals
- Perseguir a nota do Lighthouse. A nota de laboratório ajuda, mas o que importa é o dado de campo dos seus clientes reais. Uma loja pode ter nota mediana e boa experiência, ou o contrário.
- Testar só a home. Boa parte das vendas começa direto na página de produto ou de categoria, vindas de busca e de anúncios.
- Medir só no computador. O celular costuma ter números piores e concentrar a maior parte do tráfego.
- Corrigir e esquecer. Uma campanha nova, um aplicativo instalado ou um pixel de mídia podem desfazer o ganho em uma semana.
- Esconder conteúdo para melhorar a métrica. Tirar a imagem do produto do topo melhora o número e piora a venda. A métrica é um meio, não o fim.
- Adicionar scripts sem dono. Ferramentas instaladas para um teste pontual que continuam carregando meses depois.
- Ignorar a infraestrutura. Otimizar imagens em um servidor que demora a responder é como trocar o pneu de um carro sem motor.
Da correção à rotina: plataforma, hospedagem e governança
Parte dos problemas está no tema e nos componentes da loja; parte está na infraestrutura. Em plataformas SaaS, o fornecedor cuida do servidor, e o trabalho se concentra em imagens, scripts e componentes. Em lojas hospedadas por conta própria ou com front-end próprio, o servidor, o cache e a CDN também entram na lista. Se você está avaliando plataformas, vale medir lojas que já estão no ar em cada uma delas, como sugerimos no guia sobre Tray, VTEX ou Wake. E componentes padronizados ajudam a manter as métricas sob controle a cada nova campanha, como mostramos no artigo sobre design system para lojas.
Checklist mensal de Core Web Vitals
- Testar home, uma categoria e uma página de produto no PageSpeed Insights, no celular.
- Conferir o relatório de Core Web Vitals no Search Console e anotar mudanças de status.
- Revisar a lista de scripts de terceiros e remover o que não tem mais uso.
- Verificar se as imagens das campanhas do mês seguem as regras de peso e proporção.
- Repetir a revisão com antecedência antes de Black Friday, Natal e outras datas de pico.
Regras que evitam regressão
Defina um responsável pelas métricas, com autonomia para barrar o que piora a experiência. Exija que todo novo script de terceiro passe por uma avaliação de impacto antes de entrar na loja. E combine com o marketing um padrão para imagens e banners. Essas três regras simples evitam boa parte dos retrocessos.
Próximo passo: 15 minutos e três números
Separe 15 minutos hoje, teste uma página de produto no celular pelo PageSpeed Insights e anote o LCP, o INP e o CLS. Esse é o seu ponto de partida. Compare com os limites de 2,5 segundos, 200 milissegundos e 0,1, escolha a métrica mais distante do ideal e use o diagnóstico acima para encontrar a causa. Uma correção bem feita por mês já muda a experiência da loja em pouco tempo.
Quando o gargalo estiver no front-end da loja, o For:Commerce cuida da otimização contínua; quando estiver na infraestrutura, o For:Cloud oferece hospedagem gerenciada com cache, monitoramento e performance. Se quiser ajuda para interpretar os resultados da sua loja, escreva para contato@forhuman.com.br.