Utilizamos cookies para melhorar a sua experiência, analisar o tráfego do site e personalizar conteúdos. Pode aceitar todos os cookies ou escolher quais categorias permitir. Saber mais
Métricas Web Essenciais para Ecommerce 2026: Correções de LCP, INP, CLS | Ordiko
Guia
Métricas Web Essenciais para Ecommerce 2026: Correções de LCP, INP, CLS
Guia prático de 2026 para Métricas Web Essenciais no ecommerce — limiares de LCP/INP/CLS, causas do mundo real e as correções que fazem a diferença no PDP e PLP.
PT1H
TL;DR. Os Core Web Vitals em 2026 são LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1 no p75. Em sites de ecommerce, o LCP é corrigido através do pré-carregamento da imagem principal, o INP através do adiamento do JS e do uso de recursos concorrentes do React 18+, e o CLS através da reserva de espaço para imagens e regiões dinâmicas. O Google pontua no p75 ao longo de uma janela de 28 dias; as correções levam semanas para refletir.
Limiares de 2026
Métrica
Boa
Precisa de melhoria
Ruim
LCP
≤ 2.5s
2.5s – 4.0s
> 4.0s
INP
≤ 200ms
200ms – 500ms
> 500ms
CLS
≤ 0.1
0.1 – 0.25
> 0.25
TTFB
≤ 800ms
800ms – 1.8s
> 1.8s
Fonte: . O INP substituiu o FID como um Core Web Vital em março de 2024 e permanece como a métrica para 2026.
Perguntas frequentes
As Métricas Web Essenciais afetam os rankings?
Sim, desde 2021 — mas como um desempate em vez de um sinal primário. Duas páginas de qualidade de conteúdo igual classificarão na ordem de CWV. Corrigir CWV em uma página mal classificada não fará com que ela classifique melhor se o conteúdo for fraco.
Por que o INP é mais difícil de corrigir do que o LCP?
O LCP é principalmente um problema de CDN e otimização de imagem com correções bem compreendidas. O INP é um problema de execução de JavaScript que requer análise componente por componente. Cada evento de interação pode ter um gargalo diferente (clique em filtro vs. adicionar ao carrinho vs. troca de variante).
Qual é uma boa meta de INP para PDP?
Abaixo de 200ms p75 é 'bom'. Abaixo de 100ms é alcançável em PDPs modernos com disciplina (RSC, sem scripts pesados de terceiros, entradas debounced). Acima de 500ms é 'ruim' e provavelmente impacta os rankings.
Como a Ordiko lida com CWV por padrão?
A Ordiko envia Next.js 16 Cache Components + PPR, que transmite uma estrutura estática com a imagem LCP já pré-carregada e limites de Suspense para conteúdo dinâmico. O INP padrão fica abaixo de 200ms em PDPs típicos sem otimização personalizada.
O Google usa CWV como um sinal de experiência de página na classificação. Dados de usuários reais mostram que páginas com CWV totalmente verdes superam páginas comparáveis com CWV fraco em nichos competitivos.
Além das classificações, o CWV afeta diretamente a conversão. Estudos de 2024–2025 mostram consistentemente:
Melhoria de 1 segundo no LCP: aumento de 5–15% na conversão em PDP.
INP abaixo de 200ms: redução de 10–20% na desistência do carrinho.
CLS abaixo de 0.1: aumento perceptível na qualidade da experiência do usuário.
Medindo da maneira certa
Duas fontes de dados são importantes:
CrUX (Relatório de Experiência do Usuário do Chrome): dados de usuários reais que o Google usa para classificá-lo. Janela de 28 dias, p75. Apresentado no PageSpeed Insights e no Search Console.
Seu próprio RUM: dados de usuários reais que você coleta através da biblioteca web-vitals ou do seu CDN. Mostra dados mais recentes, permitindo segmentar por tipo de página, dispositivo, país.
Ferramentas sintéticas (Lighthouse, WebPageTest) são úteis para diagnóstico, mas não para pontuação.
Correções de LCP (maior pintura de conteúdo)
Em ecommerce, o LCP é quase sempre:
A imagem principal na página inicial, PLP e PDP.
O H1 + primeiro parágrafo em páginas de blog/artigo.
As grandes vitórias:
Pré-carregue a imagem LCP com <link rel="preload" as="image" fetchpriority="high">:
Retire literais regex dos manipuladores de eventos — recriar regex em um caminho crítico custa um INP mensurável.
Adie scripts de terceiros não críticos. Pixels de marketing, widgets de chat, SDKs de teste A/B: carregue-os com strategy="afterInteractive" ou lazyOnload.
Correções de CLS (mudança de layout cumulativa)
As grandes vitórias:
Sempre defina largura/altura em imagens. Os navegadores reservam o espaço correto.
Reserve espaço para conteúdo incorporado. iframes, anúncios, players de vídeo precisam de dimensões explícitas ou contêineres de proporção.
Evite `font-display: swap` sem CSS de fallback de fonte. O swap reflowa o texto. Use size-adjust para corresponder às métricas ou aceite font-display: optional.
Não injete conteúdo acima do conteúdo existente. Notificações de banner, consentimento de cookies, banners de venda — renderize-os em uma posição que não desloque a página.
Carregadores de esqueleto devem corresponder às dimensões do conteúdo real. Um esqueleto menor que o conteúdo carregado desloca a página.
Notas específicas por tipo de página
Página inicial
A imagem principal é LCP. Pré-carregue-a.
Carrosséis são minas terrestres de CLS. Use apenas CSS ou pré-renderize o primeiro slide.
PLP (lista de produtos / categoria)
O LCP é geralmente a imagem do primeiro cartão de produto.
O INP são cliques em filtros e paginação. Use startTransition de forma agressiva.
O CLS é o reflow da grade de produtos quando os filtros são aplicados. Reserve a altura da grade.
PDP
O LCP é a imagem principal do produto.
O INP é a troca de variantes e adicionar ao carrinho. UI otimista é obrigatória.
O CLS são as miniaturas da galeria de produtos carregando após a imagem principal.
Carrinho / Checkout
O INP é crítico aqui. Um botão "fazer pedido" lento custa pedidos.
CLS do carregamento de iframes de pagamento (Stripe Elements, etc.). Reserve espaço.
Ferramentas
Ferramenta
Para que é boa
PageSpeed Insights
Diagnóstico de URL única com sobreposição de usuários reais (CrUX)
Lighthouse
Medição sintética para fluxos de trabalho de desenvolvimento
WebPageTest
Medição com limitação de rede, em múltiplas localizações
Search Console → CWV
Nível de domínio p75 ao longo de 28 dias
Seu próprio RUM (web-vitals)
Dados de campo em tempo real segmentados por página, dispositivo, país
Renderização em edge de shells estáticos (TTFB ≤ 100ms).
Imagem LCP pré-carregada por padrão em PDP, PLP, página inicial.
Limites de Suspense em torno de ilhas dinâmicas (carrinho, recentemente visualizados, herói personalizado).
startTransition + useOptimistic em controles de filtro e variante.
Pesquisa com debounce de 200ms com AbortController.
O típico p75 de usuários reais em um PDP padrão da Ordiko: LCP 1.0–1.8s, INP 80–160ms, CLS < 0.05.
FAQ
Os Core Web Vitals afetam as classificações? Sim, desde 2021 — mas como um desempate em vez de um sinal primário. Duas páginas de qualidade de conteúdo igual serão classificadas na ordem do CWV. Corrigir o CWV em uma página mal classificada não fará com que ela suba de classificação se o conteúdo for fraco.
Por que o INP é mais difícil de corrigir do que o LCP? O LCP é principalmente um problema de CDN e otimização de imagem com correções bem compreendidas. O INP é um problema de execução de JavaScript que requer análise componente por componente. Cada evento de interação pode ter um gargalo diferente (clique em filtro vs. adicionar ao carrinho vs. troca de variante).
Qual é uma boa meta de INP para PDP? Abaixo de 200ms p75 é 'bom'. Abaixo de 100ms é alcançável em PDPs modernos com disciplina (RSC, sem scripts pesados de terceiros, inputs com debounce). Acima de 500ms é 'ruim' e provavelmente impacta as classificações.
Como a Ordiko lida com CWV por padrão? A Ordiko envia Next.js 16 Cache Components + PPR, que transmite um shell estático com a imagem LCP já pré-carregada e limites de Suspense para conteúdo dinâmico. O INP padrão fica abaixo de 200ms em PDPs típicos sem otimização personalizada.