Otimização Core Web Vitals: LCP, FID e CLS para sites de comércio eletrônico

Sites com bons Core Web Vitals apresentam taxas de abandono 24% mais baixas, de acordo com a pesquisa do Google. Para o comércio eletrônico, onde cada ponto percentual da taxa de conversão se traduz em receita, o desempenho da web não é um item técnico interessante: é um multiplicador de negócios. Core Web Vitals também são um fator confirmado de classificação do Google, o que significa que pontuações baixas empurram as páginas de seus produtos para baixo nos resultados de pesquisa exatamente quando os clientes em potencial desejam comprar.

Principais conclusões

• O maior Contentful Paint (LCP) em menos de 2,5 segundos requer a otimização do tempo de resposta do servidor e do carregamento de recursos críticos
• Interação com o Next Paint (INP) abaixo de 200 ms significa interromper longas tarefas JavaScript e adiar a execução não crítica
• A mudança cumulativa de layout (CLS) abaixo de 0,1 requer dimensões explícitas em todas as imagens, incorporações e conteúdo injetado dinamicamente
• Os sites de comércio eletrônico enfrentam desafios únicos de CWV: imagens pesadas de produtos, scripts de terceiros (análises, chat, anúncios) e elementos dinâmicos de preços

---

Compreendendo os principais sinais vitais da Web

Core Web Vitals são três métricas de desempenho centradas no usuário que o Google usa como sinais de classificação. Eles medem a velocidade de carregamento, a interatividade e a estabilidade visual – os três aspectos da experiência da página que os usuários mais notam.

Nota: FID (First Input Delay) foi substituído por INP (Interaction to Next Paint) em março de 2024 como a métrica oficial de capacidade de resposta. O INP mede todas as interações ao longo do ciclo de vida da página, não apenas a primeira.

Por que os sites de comércio eletrônico têm dificuldades

Os sites de comércio eletrônico enfrentam desafios de desempenho únicos que os sites de conteúdo não enfrentam:

• Imagens pesadas de produtos: fotos de produtos em alta resolução são essenciais para a conversão, mas demoram para carregar
• Scripts de terceiros – análises (Google Analytics, Meta Pixel), widgets de bate-papo (Intercom, Zendesk), mecanismos de personalização e ferramentas de teste A/B competem pelo tempo do thread principal
• Conteúdo dinâmico: alterações de preços, indicadores de estoque, banners promocionais e recomendações personalizadas mudam o layout e a renderização de blocos
• Fluxos de checkout complexos – scripts de processamento de pagamento, validação de endereço e detecção de fraude adicionam peso ao JavaScript

---

Otimizando pintura com maior conteúdo (LCP)

O LCP mede quando o maior elemento visível termina a renderização. Para páginas de produtos, normalmente é a imagem principal do produto. Para páginas de categoria, pode ser a primeira imagem do cartão do produto ou um banner promocional.

Tempo de resposta do servidor (TTFB)

O LCP não pode ser mais rápido que o tempo de resposta do servidor. O Time to First Byte (TTFB) mede quanto tempo o navegador espera pelo primeiro byte de HTML. Alvo TTFB abaixo de 600 ms, idealmente abaixo de 200 ms.

Técnicas de otimização:

• Renderização no lado do servidor (SSR) - renderiza HTML no servidor em vez de enviar um shell vazio que requer JavaScript para ser preenchido. Next.js App Router com React Server Components fornece isso por padrão.
• Computação de borda – implemente renderização no lado do servidor em locais de borda próximos aos usuários usando plataformas como Vercel Edge Functions ou Cloudflare Workers
• Otimização do banco de dados – consultas lentas ao banco de dados nas páginas dos produtos aumentam diretamente o TTFB. Consulte nosso guia sobre otimização de consulta de banco de dados
• Cache – armazena em cache páginas renderizadas para usuários anônimos. Uma página de produto armazenada em cache CDN é veiculada em 20 ms versus 200 ms da origem. Consulte estratégias de armazenamento em cache

Carregamento de recursos críticos

Após a chegada do HTML, o navegador deve carregar CSS, fontes e imagens antes de renderizar o elemento LCP.

Otimização de imagem para LCP:

• Use <img> com fetchpriority="high" para a imagem LCP para informar ao navegador para priorizá-la
• Use formatos modernos: WebP (30% menor que JPEG) ou AVIF (50% menor que JPEG)
• Veicule imagens responsivas com srcset e sizes para evitar o carregamento de uma imagem de 2.000 pixels em uma tela móvel de 400 pixels
• Pré-carregue a imagem LCP no documento <head> com <link rel="preload" as="image">
• Evite o carregamento lento da imagem LCP - o carregamento lento adia quando você deseja que ela seja carregada imediatamente

Otimização CSS:

• CSS crítico embutido no HTML <head> para evitar solicitações CSS de bloqueio de renderização
• Adie CSS não crítico (animações, estilos abaixo da dobra) com media="print" e troque para media="all" no carregamento
• Remova CSS não utilizado – ferramentas como PurgeCSS eliminam regras mortas

Otimização de fonte:

• Use font-display: swap para mostrar o texto imediatamente com uma fonte substituta enquanto a fonte personalizada é carregada
• Pré-carregue o arquivo de fonte principal com <link rel="preload" as="font" crossorigin>
• Subconjunto de fontes para incluir apenas os caracteres que você usa (subconjunto latino em vez de Unicode completo)
• Considere pilhas de fontes do sistema para o corpo do texto - elas carregam instantaneamente sem nenhuma solicitação de rede

---

Otimizando a interação com a próxima pintura (INP)

O INP mede o atraso entre uma interação do usuário (clique, toque, pressionamento de tecla) e a próxima atualização visual. Ele captura todas as interações durante a sessão da página, relatando a pior (no percentil 98). Um INP ruim significa que a página parece lenta e sem resposta.

Quebrando tarefas longas

O thread principal do navegador lida com a execução de JavaScript, cálculos de layout, pintura e processamento de entrada do usuário. Uma longa tarefa JavaScript (mais de 50 ms) bloqueia tudo isso, criando um atraso visível quando os usuários interagem.

Técnicas para reduzir o bloqueio do thread principal:

• Divisão de código – carrega apenas o JavaScript necessário para a página atual. Next.js faz isso automaticamente por rota, mas as importações dinâmicas dentro de uma página fornecem um controle mais preciso
• Adiar JavaScript não crítico – análises, widgets de bate-papo e incorporações de mídia social não precisam ser carregados antes que a página seja interativa. Use atributos defer ou async ou carregue-os após interação do usuário
• Web Workers – move cálculos pesados (cálculos de preços, filtragem de grandes listas de produtos, indexação de pesquisa) para um thread do Web Worker que não bloqueia o thread principal
• requestIdleCallback – agenda trabalho de baixa prioridade (pré-carregamento de páginas futuras, pré-renderização de componentes fora da tela) durante períodos ociosos

Otimização da Hidratação

Os aplicativos React renderizados pelo servidor devem "hidratar-se" - anexando ouvintes de eventos e reconciliando o HTML renderizado pelo servidor com o estado do lado do cliente. Para páginas grandes com muitos componentes interativos, a hidratação pode levar 500 ms ou mais.

Estratégias de hidratação:

• Hidratação seletiva -- O React 18 com limites Suspense permite que partes da página sejam hidratadas de forma independente. A prioridade vai para os componentes com os quais o usuário está interagindo
• Hidratação progressiva - hidrate primeiro os componentes acima da dobra, adie a hidratação abaixo da dobra até que o usuário role
• Componentes do React Server - Next.js App Router renderiza componentes no servidor sem enviar seu JavaScript ao cliente. Somente componentes interativos precisam de JavaScript do lado do cliente

Gerenciamento de scripts de terceiros

Scripts de terceiros são os maiores culpados do INP em sites de comércio eletrônico. Uma loja Shopify típica carrega de 15 a 25 scripts de terceiros que adicionam coletivamente de 1 a 3 MB de JavaScript e competem pelo tempo do thread principal.

---

Prevenção de mudança cumulativa de layout (CLS)

O CLS mede mudanças inesperadas de layout durante o ciclo de vida da página. Uma mudança de layout ocorre quando um elemento visível muda sua posição sem interação do usuário. Os usuários acham isso chocante: clicar em um botão que se move exatamente quando você o alcança ou ler um texto que salta para baixo quando um anúncio é carregado acima dele.

Causas e correções comuns do CLS

Imagens sem dimensões: Cada elemento <img> deve ter atributos width e height explícitos ou CSS aspect-ratio. Sem dimensões, o navegador não aloca espaço para a imagem e depois muda o conteúdo quando a imagem é carregada e ocupa espaço.

Conteúdo injetado dinamicamente: Banners promocionais, barras de consentimento de cookies e brindes de notificação que injetam conteúdo acima do existente causam mudanças. Reserve espaço para esses elementos ou injete-os de forma que não empurre o conteúdo para baixo (posicionamento fixo, sobreposições).

Fontes da Web causando refluxo de texto: Quando uma fonte personalizada é carregada e substitui a fonte substituta, o texto pode refluir devido a diferentes larguras de caracteres. Use font-display: optional (se você aceitar exibição substituta ocasional) ou font-display: swap com métricas de fonte substituta cuidadosamente combinadas.

Anúncios e incorporações de carregamento tardio: Reserve espaço para espaços de anúncios e incorporações usando CSS min-height ou aspect-ratio. Mesmo que o servidor de anúncios seja lento, o layout permanece estável.

Orçamento CLS por tipo de página

---

Medindo e Monitorando CWV

Ferramentas de laboratório (teste sintético)

• Lighthouse – integrado ao Chrome DevTools, fornece pontuações CWV com sugestões de otimização
• WebPageTest – análise detalhada em cascata com visualização de tira de filme mostrando exatamente quando cada elemento é renderizado
• PageSpeed Insights – combina dados de laboratório (Lighthouse) com dados de campo (CrUX) para obter uma imagem completa

Dados de campo (monitoramento de usuário real)

Teste de ferramentas de laboratório sob condições controladas. Os dados de campo capturam a experiência real do usuário em diferentes dispositivos, redes e condições.

• Relatório de experiência do usuário do Chrome (CrUX) – dados CWV agregados de usuários reais do Chrome, disponíveis no PageSpeed Insights e BigQuery
• biblioteca web-vitals – biblioteca JavaScript que mede o CWV na produção e gera relatórios para suas análises
• Provedores de RUM -- Datadog RUM, SpeedCurve e Sentry Performance capturam CWV juntamente com métricas de negócios

Monitoramento Contínuo

Configure o monitoramento CWV automatizado que alerta quando as pontuações diminuem:

1. Execute o Lighthouse CI em seu pipeline de CI/CD para capturar regressões antes da implantação
2. Monitore os dados CrUX mensalmente em busca de tendências em suas páginas mais importantes
3. Use RUM para correlacionar pontuações CWV com métricas de negócios (taxa de conversão, taxa de rejeição, receita por sessão)
4. Mudanças no desempenho do teste A/B para medir diretamente o impacto nos negócios

Para uma configuração de monitoramento abrangente, consulte nosso guia de observabilidade e APM.

---

Lista de verificação de otimização específica para comércio eletrônico

Use esta lista de verificação para melhorar sistematicamente o CWV em seu site de comércio eletrônico:

---

Perguntas frequentes

O Core Web Vitals realmente afeta as classificações do Google?

Sim. O Google confirmou Core Web Vitals como um sinal de classificação na atualização do Page Experience. Embora a relevância do conteúdo continue sendo o fator dominante, o CWV atua como um desempate entre páginas com qualidade de conteúdo semelhante. Para palavras-chave competitivas de comércio eletrônico, boas pontuações de CWV fornecem uma vantagem de classificação mensurável.

Como faço para corrigir o CWV no Shopify sem acesso à configuração do servidor?

Concentre-se no que você pode controlar: otimize imagens (use a otimização de imagens integrada do Shopify ou aplicativos como Crush.pics), minimize os aplicativos instalados (cada um adiciona JavaScript), use um tema leve, adie scripts de terceiros com carregamento lento e adicione dimensões explícitas a todas as imagens. Para otimização avançada, consulte nossos serviços de otimização de velocidade do Shopify.

Devo priorizar LCP, INP ou CLS?

Priorize primeiro a métrica com a pior pontuação. Se tudo estiver ruim, comece com LCP porque ele tem o impacto mais direto na percepção do usuário e na taxa de rejeição. Melhorias no LCP (otimização de servidor, otimização de imagem) geralmente também melhoram o INP, reduzindo o peso geral da página.

Quanto tempo leva para que as melhorias no CWV afetem o SEO?

O Google usa dados CrUX contínuos de 28 dias para sinais de classificação. Após a implantação das melhorias, espere de 4 a 6 semanas antes que as alterações sejam refletidas nos dados CrUX e potencialmente mais tempo antes que as alterações de classificação sejam visíveis. Monitore os dados do CrUX no Search Console para acompanhar o progresso.

Quais pontuações CWV devo atingir para comércio eletrônico competitivo?

Almeje todas as três métricas na faixa "Bom": LCP abaixo de 2,5 segundos, INP abaixo de 200 ms, CLS abaixo de 0,1. Para categorias competitivas, busque desempenho de alto nível: LCP abaixo de 1,5 segundos, INP abaixo de 100 ms, CLS abaixo de 0,05. Essas pontuações colocam você à frente de 80-90% dos sites de comércio eletrônico.

---

O que vem a seguir

Comece medindo seus Core Web Vitals atuais com PageSpeed ​​​​Insights em suas páginas de maior tráfego. Identifique a métrica de pior pontuação e trabalhe com as técnicas de otimização deste guia. Pequenas melhorias compostas - uma melhoria de LCP de 500 ms combinada com uma redução de INP de 100 ms e uma melhoria de 0,05 CLS pode melhorar mensuravelmente as classificações e a taxa de conversão.

Para obter uma visão completa da engenharia de desempenho, consulte nosso guia de pilares sobre escalando sua plataforma de negócios. Para se preparar para picos de tráfego que prejudicam suas pontuações de CWV, leia nosso guia de testes de carga para Black Friday.

ECOSIRE fornece otimização de velocidade do Shopify e auditorias Core Web Vitals para plataformas de comércio eletrônico. Entre em contato com nossa equipe de desempenho para uma análise abrangente de CWV.

---

Publicado por ECOSIRE — ajudando empresas a escalar com soluções baseadas em IA em Odoo ERP, Shopify eCommerce e OpenClaw AI.