Core Web Vitals para lojas virtuais: LCP, INP e CLS explicados

O que medem LCP, INP e CLS, os limites de bom e ruim no percentil 75, dados de laboratório e de campo e as correções comuns na Shopify e no WooCommerce.

Equipe editorial FixReports14 min de leitura

As Core Web Vitals são três métricas do Google que descrevem a experiência de visitantes reais em uma página: Largest Contentful Paint (LCP) para o carregamento, Interaction to Next Paint (INP) para a capacidade de resposta e Cumulative Layout Shift (CLS) para a estabilidade visual. Uma página é aprovada quando pelo menos 75% das visitas ficam na faixa “boa”: LCP de até 2,5 segundos, INP de até 200 milissegundos e CLS de 0,1 ou menos, medidos separadamente para celular e computador. Em lojas virtuais, notas ruins costumam vir de imagens de banner principal e de produto grandes ou com lazy loading, de scripts de apps e de rastreamento, de fontes da web e de barras ou widgets de avaliações que empurram o conteúdo para baixo depois que a página aparece.

Pontos principais

  • Bom, precisa de melhoria e ruim são avaliados no percentil 75 dos carregamentos de página: o LCP é ruim acima de 4 segundos, o INP é ruim acima de 500 ms e o CLS é ruim acima de 0,25 (web.dev (abre em uma nova aba)).
  • O INP substituiu o First Input Delay (FID) como Core Web Vital em 12 de março de 2024 (web.dev (abre em uma nova aba)).
  • Os dados de campo do Chrome UX Report são uma média móvel de 28 dias e não incluem o Chrome no iOS (Chrome for Developers (abre em uma nova aba)).
  • O filtro image_tag da Shopify carrega as imagens de forma imediata nas três primeiras seções de um template e com lazy loading a partir da quarta seção, a menos que você mude esse comportamento (Shopify (abre em uma nova aba)).
  • Desde o WordPress 6.3, o núcleo adiciona fetchpriority="high" à imagem que considera mais provável de ser o elemento LCP (Make WordPress Core (abre em uma nova aba)).

Quais são os limites das Core Web Vitals?

Uma página atende às Core Web Vitals quando o percentil 75 dos seus carregamentos fica na faixa boa nas três métricas.

MétricaO que medeBomPrecisa de melhoriaRuim
LCPTempo até a maior imagem, vídeo ou bloco de texto na área visível ser renderizado2,5 s ou menosAcima de 2,5 s até 4,0 sAcima de 4,0 s
INPTempo entre um clique, toque ou tecla pressionada e a pintura do quadro seguinte200 ms ou menosAcima de 200 ms até 500 msAcima de 500 ms
CLSQuanto o conteúdo visível se move de forma inesperada0,1 ou menosAcima de 0,1 até 0,25Acima de 0,25

Os limites vêm dos guias de LCP (abre em uma nova aba), INP (abre em uma nova aba) e CLS (abre em uma nova aba) do web.dev, conforme a versão de outubro de 2026.

O percentil 75 faz com que o resultado reflita a maioria dos visitantes, e não só os mais rápidos, e o Google separa celular e computador (abre em uma nova aba). O PageSpeed Insights aprova uma página quando as três métricas são boas; sem dados suficientes de INP, ele avalia apenas LCP e CLS (documentação do PageSpeed Insights (abre em uma nova aba)). O Google diz que as Core Web Vitals estáveis não mudam mais de uma vez por ano.

Em uma loja, o elemento LCP costuma ser o banner principal ou a imagem principal do produto, e é por isso que o tratamento das imagens faz tanta diferença.

Por que o INP substituiu o FID em março de 2024?

O INP substituiu o FID porque o FID media apenas a primeira interação e só parte do atraso dela, enquanto o INP considera as interações ao longo de toda a visita.

O Google anunciou em maio de 2023 que o INP se tornaria uma Core Web Vital, e a troca entrou em vigor em 12 de março de 2024 (abre em uma nova aba). O FID informava apenas a primeira interação, e só o atraso de entrada dela, sem contar o tempo gasto executando os manipuladores de eventos nem pintando o resultado. O INP observa cliques, toques e teclas pressionadas durante toda a visita e informa a interação mais longa, ignorando valores atípicos; rolar a página e passar o mouse não contam. Quem usava as APIs do CrUX e do PageSpeed Insights teve até 9 de setembro de 2024 para fazer a mudança (web.dev (abre em uma nova aba)).

Cada interação tem três partes: atraso de entrada (espera por scripts ocupados), duração do processamento (execução dos manipuladores) e atraso de apresentação (pintura do quadro seguinte) (web.dev (abre em uma nova aba)).

Em uma loja, essas interações são o seletor de variantes, os botões de quantidade, o botão de adicionar ao carrinho, o carrinho lateral, os filtros e os menus. Uma página podia passar no FID com um primeiro toque rápido e ainda parecer lenta quando alguém abria os filtros mais tarde.

Qual é a diferença entre dados de laboratório e dados de campo?

Os dados de laboratório vêm de um único teste em condições fixas, enquanto os dados de campo são coletados de visitantes reais ao longo do tempo, e o Google recomenda usar os dados de campo para decidir o que corrigir primeiro (web.dev (abre em uma nova aba)).

Dados de laboratórioDados de campo
OrigemUm carregamento de página simulado (Lighthouse, Chrome DevTools, a seção de laboratório do PageSpeed Insights)Visitantes reais do Chrome (Chrome UX Report) ou o seu próprio monitoramento de usuários reais
CondiçõesDispositivo e rede fixos. O teste padrão para celular do Lighthouse (abre em uma nova aba) usa “Slow 4G” (150 ms de ida e volta, 1,6 Mbps de download) e uma CPU 4x mais lentaOs dispositivos, as redes e os locais que os seus visitantes tiverem
INPNão é medido em um simples carregamento de página. O Total Blocking Time (TBT) é uma aproximação grosseiraMedido a partir de interações reais
Melhor paraDepurar e conferir uma mudança antes de publicá-laSaber o que os visitantes realmente recebem

O TBT soma a parte de cada tarefa da thread principal que passa de 50 ms; o web.dev sugere menos de 200 ms em hardware móvel médio, mas diz que ele não substitui o INP (web.dev (abre em uma nova aba)).

Três detalhes do Chrome UX Report (CrUX) importam para as lojas:

  • Ele é uma média móvel de 28 dias (abre em uma nova aba), atualizada diariamente.
  • Ele cobre o Chrome no computador e no Android para usuários que atendem às condições de envio de dados do Chrome. O Chrome no iOS fica de fora, então uma loja com compradores que usam principalmente iPhone vê dados de campo de apenas parte do seu público (metodologia (abre em uma nova aba)).
  • Páginas e origens só aparecem quando podem ser descobertas publicamente e são populares o bastante, então uma loja com pouco tráfego pode ter apenas dados no nível da origem, ou nenhum dado.

O painel de desempenho da web (abre em uma nova aba) da Shopify também informa LCP, INP e CLS de usuários reais no percentil 75, ao longo de 30 dias em vez de 28, então espere algumas diferenças em relação ao CrUX.

O que deixa o LCP lento nas páginas da loja?

O LCP costuma ser lento nas lojas porque a imagem principal é pesada demais, é descoberta tarde ou é atrasada de propósito por lazy loading ou por uma animação.

  • Lazy loading na imagem LCP. O web.dev diz para nunca fazer isso (web.dev (abre em uma nova aba)). A análise que ele fez de páginas WordPress encontrou um LCP no percentil 75 mais lento em sites que usavam o lazy loading nativo, e deixar de aplicar lazy loading às imagens acima da dobra eliminou a piora (web.dev (abre em uma nova aba)).
  • Uma imagem encontrada tarde. Um banner principal definido como background-image no CSS, ou inserido por um script de slider, não está no HTML que o navegador lê primeiro. A Shopify desaconselha fundos em CSS para o conteúdo principal e efeitos de fade-in na imagem LCP (Shopify (abre em uma nova aba)).
  • Prioridade baixa. As imagens carregam com prioridade baixa até o layout estar pronto, então a Shopify recomenda fetchpriority="high" na imagem LCP (Shopify (abre em uma nova aba)). O web.dev observa que usar esse atributo em mais de uma ou duas imagens reduz a utilidade dele (web.dev (abre em uma nova aba)).
  • CSS e scripts que bloqueiam a renderização. Folhas de estilo grandes e scripts síncronos no <head> atrasam a renderização mesmo depois que a imagem chega (web.dev (abre em uma nova aba)).
  • Tamanho dos arquivos e fontes. Use formatos modernos, srcset e sizes, e uma CDN. Para fontes da web, use um valor de font-display diferente de auto ou block.
<!-- Main product image: real src in the HTML, eager, high priority -->
<img src="/images/linen-shirt-1200.webp"
     srcset="/images/linen-shirt-600.webp 600w, /images/linen-shirt-1200.webp 1200w"
     sizes="(min-width: 990px) 50vw, 100vw"
     width="1200" height="1500"
     fetchpriority="high"
     alt="Natural linen shirt, front view">

<!-- Gallery images below the first screen: lazy -->
<img src="/images/linen-shirt-back-600.webp" loading="lazy"
     width="600" height="750" alt="Natural linen shirt, back view">

O que deixa o INP lento nas páginas da loja?

Um INP lento nas lojas geralmente significa JavaScript demais na thread principal, boa parte dele vindo de apps, tags de rastreamento e recursos do tema, de modo que os toques precisam esperar.

Se um comprador toca em “Adicionar ao carrinho” enquanto os scripts de avaliações, chat e analytics ainda estão rodando, o toque espera. Um seletor de variantes que renderiza de novo o formulário inteiro do produto aumenta o tempo de processamento. Megamenus enormes e grades de coleção com muitas amostras de cor aumentam o atraso de apresentação.

O web.dev recomenda dividir tarefas longas e ceder a vez à thread principal, atualizar a tela primeiro e adiar o resto, e manter o DOM menor (web.dev (abre em uma nova aba)). A Shopify acrescenta passos específicos para lojas: revisar cada app, pixel e script do tema, adiar o que não é essencial, carregar recursos apenas na interação e desativar os snippets antiflicker de testes A/B quando nenhum teste estiver rodando (Shopify (abre em uma nova aba)).

O que causa mudanças de layout nas páginas de produto e de coleção?

As mudanças de layout nas lojas vêm principalmente de conteúdo que aparece ou muda de tamanho depois da primeira renderização: imagens sem dimensões, barras de aviso e de cookies, widgets de avaliações, blocos de apps e troca de fontes.

O web.dev lista como causas comuns mídias com dimensões desconhecidas, conteúdo inserido acima do conteúdo existente, widgets de terceiros que mudam de tamanho sozinhos e fontes da web com tamanho diferente da fonte alternativa (web.dev (abre em uma nova aba)). Nas lojas, isso significa uma barra de frete grátis inserida no topo, estrelas de avaliação que carregam depois do título, mensagens de parcelamento abaixo do preço e carrosséis de recomendações. A Shopify observa que o conteúdo de pop-ups também pode causar mudanças de layout (Shopify (abre em uma nova aba)).

Mudanças que ocorrem até 500 ms depois de uma ação do usuário não contam, mas as que acontecem durante a rolagem contam, e as ferramentas de laboratório muitas vezes não as detectam (web.dev (abre em uma nova aba)). Defina width e height nas imagens ou um aspect-ratio no CSS, reserve espaço para os widgets, exiba os banners como sobreposições, reduza as mudanças causadas pela troca de fontes com size-adjust e faça animações com transform em vez de top ou left.

/* Reserve space for a reviews summary that loads after the page */
.product-reviews-summary { min-height: 24px; }

/* Keep product cards from jumping while images load */
.product-card img { width: 100%; height: auto; aspect-ratio: 4 / 5; }

Como melhorar as Core Web Vitals na Shopify?

Na Shopify, a maior parte dos ganhos vem de carregar a primeira imagem de forma imediata e com prioridade alta, enxugar os scripts de apps e conferir o resultado nos relatórios de desempenho da web do painel administrativo.

Confira os dados no seu painel administrativo

Um resumo aparece na página Loja virtual > Temas (Online Store > Themes), e os relatórios completos de LCP, INP e CLS ficam em Análises > Relatórios (Analytics > Reports). Os dados podem atrasar até 36 horas, e o modo privado precisa estar desativado (Central de Ajuda da Shopify (abre em uma nova aba)).

Controle o carregamento das imagens no Liquid

O filtro image_tag aplica lazy loading às imagens das seções mais abaixo na página, a menos que você defina preload (referência do image_tag (abre em uma nova aba)): carregamento imediato nas seções 1 a 3 e lazy loading a partir da seção 4. Como section.index é nil no editor de temas, teste com > 3 em vez de <= 3:

{%- if section.index == 1 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'eager', fetchpriority: 'high', widths: '600, 900, 1200, 1600', sizes: '100vw' }}
{%- elsif section.index > 3 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'lazy', sizes: '100vw' }}
{%- else -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: sizes: '100vw' }}
{%- endif -%}

Nas grades de produtos, a Shopify sugere carregar de forma imediata apenas os primeiros cards (por exemplo, forloop.index <= 4) (Shopify (abre em uma nova aba)). Use preload: true com moderação; a Shopify recomenda pré-carregar apenas um ou dois recursos descobertos tarde.

Remova o que os apps deixam para trás

Desative as incorporações de apps que você não usa em Loja virtual > Editar tema > Incorporações de app (Online Store > Edit theme > App embeds) (Central de Ajuda da Shopify (abre em uma nova aba)). Desinstalar um app remove os blocos dele, mas apps que editaram diretamente os arquivos do tema podem deixar um “código fantasma” que, segundo a Shopify, pode causar problemas de qualidade e de desempenho (Shopify (abre em uma nova aba)). A Shopify também diz que as script tags deixarão de funcionar em 1º de março de 2027. Para fontes, a Shopify recomenda a própria CDN ou fontes do sistema em vez de serviços externos de fontes (Shopify (abre em uma nova aba)).

Como melhorar as Core Web Vitals no WooCommerce?

No WooCommerce, garanta que os plugins não anulem a priorização de imagens do WordPress, faça cache de tudo menos do carrinho e do checkout e remova scripts que carregam em todas as páginas sem necessidade.

  • Mantenha o tratamento de imagens do núcleo. Desde o WordPress 6.3 (lançado em 8 de agosto de 2023), o núcleo adiciona fetchpriority="high" à provável imagem LCP (com pelo menos 50.000 pixels quadrados, por padrão) e não aplica lazy loading às três primeiras imagens do conteúdo (Make WordPress Core (abre em uma nova aba)). Se um plugin de otimização adiciona o próprio lazy loading, verifique se ele exclui o banner principal e a imagem principal do produto.
  • Faça cache das páginas, não dos carrinhos. O guia do WooCommerce recomenda cache de página no servidor ou por plugin e uma CDN, mantendo as páginas de carrinho e de checkout fora do cache (documentação para desenvolvedores do WooCommerce (abre em uma nova aba)).
  • Verifique os cart fragments. Desde o WooCommerce 7.8, o script de cart fragments só carrega onde há um widget de carrinho, mas alguns temas incluem esse widget fixo no código. O bloco Mini-Cart não usa cart fragments (blog para desenvolvedores do WooCommerce (abre em uma nova aba)).
  • Encontre os plugins pesados. O WooCommerce sugere o Query Monitor para encontrar plugins lentos e recomenda adiar o JavaScript não essencial.

Se o seu layout mostra mais de três imagens acima da dobra, você pode aumentar o limite do WordPress:

// functions.php: skip lazy loading for the first 4 content images (default is 3)
add_filter( 'wp_omit_loading_attr_threshold', function () {
    return 4;
} );

Quanto tempo leva para as correções aparecerem?

Os testes de laboratório mostram o efeito de uma correção na hora, mas os dados de campo levam até cerca de quatro semanas para refleti-la por completo, porque o CrUX calcula a média dos 28 dias anteriores.

Rode o teste de laboratório várias vezes antes e depois de uma mudança, porque cada execução varia, e depois acompanhe os números de campo no PageSpeed Insights, no relatório Core Web Vitals do Search Console ou nos relatórios da Shopify. Uma análise gratuita dá uma primeira leitura em cerca de um minuto. O Relatório de Desempenho roda um teste de laboratório em celular com limitação (4G lento, CPU 4x) e acrescenta os dados de campo do Chrome UX Report, incluindo o INP quando o Google tem dados suficientes da sua loja.

Perguntas frequentes

As Core Web Vitals afetam o ranqueamento no Google?

O Google diz que as Core Web Vitals são usadas pelos seus sistemas de classificação, mas que notas boas não garantem as primeiras posições e que ele continua mostrando o conteúdo mais relevante mesmo quando a experiência na página é ruim (Google Search Central (abre em uma nova aba)).

Por que o PageSpeed Insights não mostra dados de campo da minha loja?

O CrUX inclui apenas páginas e origens que podem ser descobertas publicamente e têm visitantes qualificados do Chrome em número suficiente. Uma loja com pouco tráfego pode ter apenas dados no nível da origem, ou nenhum dado; nesse caso, use os testes de laboratório e os relatórios da sua própria plataforma.

Preciso de nota 90 ou mais no Lighthouse para ser aprovado?

Não. A nota de desempenho do Lighthouse é um resultado de laboratório, enquanto a avaliação das Core Web Vitals usa dados de campo no percentil 75; assim, uma página pode ser aprovada com uma nota modesta no Lighthouse e reprovada com uma nota alta.

Devo aplicar lazy loading a todas as imagens de produto?

Não. Aplique lazy loading às imagens abaixo da primeira tela, mas carregue o banner principal e a imagem principal do produto de forma imediata, com fetchpriority="high" em uma delas.

Por que meus resultados no celular são piores que no computador?

O Google mede celular e computador separadamente, e os celulares têm processadores e redes mais lentos. O teste para celular do Lighthouse simula isso com um perfil Slow 4G e uma CPU 4x mais lenta.

Fontes

Todos os guias