Core Web Vitals no WooCommerce: onde as lojas reprovam e como corrigir

O Core Web Vitals do WooCommerce reprova por motivos que um site institucional não tem. A sessão do carrinho dificulta o cache, galerias e sliders de produto disputam o lugar de elemento LCP, filtros e seletores de variação rodam JavaScript a cada clique, e a loja acumula scripts de marketing, avaliações e pagamento. Minha ordem de correção na maioria das lojas: manter alto o acerto de cache para quem navega sem login, fazer a imagem principal do produto ou da categoria carregar primeiro, reduzir o JavaScript nos templates de produto e categoria e reservar espaço para tudo que chega atrasado. As metas, no p75 dos dados de campo: LCP até 2,5 s, INP até 200 ms e CLS até 0,1.

Aqui eu fico nas três métricas. Para velocidade da loja em geral, incluindo servidor e banco de dados, veja otimização de velocidade no WooCommerce. Para entender como o Core Web Vitals funciona no WordPress como um todo, leia o guia completo de Core Web Vitals no WordPress.

Por que o WooCommerce é mais difícil que um WordPress comum?

Um blog entrega o mesmo HTML em cache para quase todo mundo. Uma loja não consegue, e isso muda tudo no LCP.

• Carrinho, checkout e minha conta ficam fora do cache de página, como deve ser.
• Quando o cliente coloca algo no carrinho, o WooCommerce grava cookies como woocommerce_items_in_cart. Dependendo de como o seu cache está configurado, esse visitante pode passar a pular o cache em todas as páginas até o fim da sessão.
• Links de adicionar ao carrinho, ordenação e parâmetros de filtro criam variações de URL com query string, e muita configuração de cache trata cada uma como miss.
• Cada template tem seu próprio elemento LCP e seus próprios scripts. Home, categoria, produto e checkout reprovam por motivos diferentes.
• Lojas acumulam scripts de terceiros: analytics, pixels de anúncio, chat, avaliações, mensagens de parcelamento. Cada um soma trabalho na thread principal.

Por isso eu nunca olho o Core Web Vitals de uma loja como um número só. Olho por template e depois por aparelho.

Como descobrir quais templates da loja reprovam?

Comece pelo relatório de Core Web Vitals do Search Console. Numa loja, os grupos de URL costumam corresponder a páginas de produto, de categoria e de conteúdo. URLs de produto isoladas raramente têm tráfego suficiente para o CrUX reportar sozinhas, então você vai ver muito dado de origem ou de grupo.

É o principal motivo para eu colocar monitoramento de usuários reais em lojas. Com a biblioteca web-vitals você manda o nome do template junto com cada métrica, por exemplo checando is_product() ou is_product_category() no PHP e imprimindo o resultado na página. Aí você afirma “as páginas de produto reprovam em INP no celular” com dado seu, sem chute. O guia de ferramentas de Core Web Vitals mostra onde cada ferramenta entra.

Como corrigir o LCP nas páginas de produto e de categoria?

Na página de produto, o elemento LCP quase sempre é a imagem principal da galeria. Na de categoria, é um banner ou uma das primeiras miniaturas.

• Garanta que a imagem principal do produto não tenha lazy load. Desde o WordPress 6.3, o core coloca fetchpriority="high" na imagem que ele julga mais importante, mas temas e plugins de galeria mudam o HTML. Confira o HTML final em vez de supor.
• Não faça a primeira imagem esperar JavaScript. Zoom, lightbox e slider da galeria do WooCommerce são recursos opcionais do tema (wc-product-gallery-zoom, wc-product-gallery-lightbox, wc-product-gallery-slider). Seja qual for a combinação que o seu tema ativa, a primeira imagem tem que aparecer sem eles.
• Entregue o tamanho certo de arquivo. É comum subir foto de produto em resolução de impressão. Um srcset e um sizes corretos evitam que o celular baixe a imagem do desktop.
• Não use lazy load na primeira linha de produtos das páginas de categoria.
• Resolva a resposta do servidor nas páginas sem cache. Categoria com muitos filtros e meta queries demora para gerar. Um cache de objetos persistente como o Redis object cache e um banco limpo ajudam em toda requisição que escapa do cache de página.

A decomposição completa do LCP, com as quatro partes da linha do tempo, está em LCP no WordPress: causas e correções.

Por que lojas WooCommerce reprovam em INP?

O INP mede quanto a página demora para responder a cliques, toques e teclas. Loja tem muito disso, e quase tudo dispara JavaScript.

• Plugins de filtro que redesenham a grade de produtos a cada checkbox.
• Formulários de variação, em que escolher tamanho ou cor atualiza preço, estoque e imagem por JavaScript. Plugins de swatches de variação somam mais trabalho.
• Botões de adicionar ao carrinho que atualizam o mini carrinho, abrem uma gaveta e disparam eventos de rastreamento na mesma tarefa.
• DOM grande em categorias com muitos produtos, cada card com selos, estrelas e marcação escondida de visualização rápida.
• Scripts de terceiros rodando tarefas longas justo quando o cliente toca em algo.

A correção quase sempre é fazer menos em cada interação: liberar a thread principal antes das chamadas de rastreamento, carregar widgets de avaliação e chat depois, mostrar menos produtos por página e tirar plugins que duplicam funções. As técnicas estão em INP no WordPress: como corrigir interações lentas.

E os cart fragments?

O script clássico de cart fragments faz uma requisição wc-ajax=get_refreshed_fragments para atualizar o mini carrinho. Essa requisição não passa pelo cache de página, então em loja movimentada ela soma carga no servidor em toda visualização em que roda. Versões recentes do WooCommerce limitam onde o script carrega, mas temas e plugins continuam enfileirando. Abra a aba de rede numa página de produto e veja se ela dispara. Se o seu tema não mostra mini carrinho ali, provavelmente você não precisa dela.

De onde vem o CLS numa loja?

• Imagens de produto sem largura e altura, ou galeria que muda de altura depois que o script do slider inicia.
• Preço que muda ao escolher a variação, principalmente quando uma faixa de preço vira um preço único mais longo.
• Estrelas de avaliação, mensagens de “parcele em até” e selos de estoque que um script insere depois da renderização.
• Barras de frete grátis, avisos de cupom e banners de consentimento empurrados acima do conteúdo.
• Fontes web que trocam tarde nos títulos e preços dos produtos.

Reserve o espaço. Defina as dimensões das imagens, dê altura fixa ou mínima aos contêineres de widgets e coloque os avisos num lugar que já exista na primeira pintura. Mais detalhes em CLS no WordPress: como evitar deslocamentos de layout.

O que checar em cada template

E o checkout?

Carrinho e checkout quase nunca são páginas que ranqueiam, mas interação lenta ali custa venda. Gateways de pagamento carregam scripts e iframes próprios, que você controla só em parte. O WooCommerce hoje oferece os blocos de Carrinho e Checkout, feitos em React, ao lado do checkout clássico por shortcode. A arquitetura de front-end é diferente, então se for migrar de um para o outro, meça o INP do checkout antes e depois em vez de supor que algum deles é mais rápido.

A ordem de correção que uso em lojas

1. Confirmar que o cache de página funciona para visitantes sem login na home, nas categorias e nos produtos, e achar o que causa bypass.
2. Corrigir a imagem LCP nos templates de produto e categoria.
3. Remover ou adiar scripts de terceiros que não se pagam.
4. Reduzir o JavaScript de filtros, variações e adicionar ao carrinho.
5. Reservar espaço para todo elemento que aparece atrasado.
6. Acompanhar o dado de campo por template até a janela de 28 dias refletir a mudança.

Se a sua loja continua reprovando e você quer alguém para rastrear o problema template por template, é esse o trabalho que faço como especialista em Core Web Vitals.