Para resolver um WooCommerce lento, parta de um fato: a loja tem dois tipos de página. As de catálogo (home, categorias, produtos) podem sair do cache de página como qualquer página WordPress. Carrinho, checkout e minha conta não podem, porque mudam para cada cliente. A otimização de velocidade do WooCommerce, então, é cachear o catálogo com força, excluir carrinho, checkout e minha conta desse cache e deixar rápida a parte sem cache, com cache de objetos persistente, banco de dados enxuto, High-Performance Order Storage (HPOS) e o mínimo possível de requisições de cart fragments. Depois vêm imagens, scripts e tags de terceiros nas páginas de produto.
A maioria das lojas lentas que eu audito é lenta por estrutura, não por causa de um plugin ruim. Este guia segue a ordem em que eu trabalho numa loja WooCommerce e faz parte do guia de como acelerar o WordPress. Se o problema é o relatório de Core Web Vitals reprovado no Search Console, leia também Core Web Vitals no WooCommerce, que vai métrica por métrica.
O que deixa o WooCommerce lento?
Um blog entrega o mesmo HTML para quase todo mundo. Uma loja tem sessão, carrinho, preço que muda com regra de imposto e moeda, estoque e cliente logado. Cada um desses itens dificulta o cache. Quando a requisição não acha cache, o WordPress carrega o WooCommerce, consulta produtos e seus metadados, confere a sessão e monta a página em PHP. Numa loja com muitos produtos, variações e extensões, esse caminho é longo.
O segundo motivo são os plugins. Loja costuma acumular extensão de frete, pagamento, avaliações, lista de desejos, filtros, upsell e tags de marketing, e cada uma pode somar consultas ao banco, scripts e requisições externas.
O que o cache de página deve incluir e excluir?
Acerte isto primeiro, porque é o que decide quantas requisições chegam ao PHP.
| Página ou requisição | Cachear? | Por quê |
|---|---|---|
| Home, categorias e produtos para visitante com carrinho vazio | Sim | Mesmo HTML para todos |
| Carrinho, checkout e minha conta | Não | Conteúdo pessoal e fluxo de pagamento |
Qualquer requisição com os cookies de carrinho ou sessão (woocommerce_items_in_cart, woocommerce_cart_hash, wp_woocommerce_session_*) | Em geral não, ou servir a página em cache sem as partes pessoais | O visitante tem carrinho |
Requisições com add-to-cart na query string | Não | Elas mudam estado |
Endpoints ?wc-ajax= | Não | São dinâmicos por natureza |
| Cliente logado | Depende da camada de cache | Muitas configurações pulam o cache para eles |
A maioria dos plugins de cache que conhecem o WooCommerce e das hospedagens gerenciadas já configura essas exceções. Confira mesmo assim, principalmente depois de mudar a URL do carrinho ou do checkout ou de adicionar um segundo idioma, porque a exceção costuma estar presa à página, e não à função dela. Se as campanhas colocam UTM em todo link, garanta que o cache ignore esses parâmetros em vez de criar uma entrada nova ou pular o cache. Para entender como cache de página, de objetos e de borda se encaixam, leia page cache, object cache e edge cache.
O que são cart fragments e vale desativar?
Cart fragments é o mecanismo clássico do WooCommerce para manter atualizado o mini carrinho do cabeçalho em páginas cacheadas. O script wc-cart-fragments faz uma requisição AJAX para ?wc-ajax=get_refreshed_fragments depois que a página carrega, e essa requisição nunca é cacheada. Resultado: WordPress e WooCommerce rodam a cada visualização de página.
As versões recentes do WooCommerce deixaram de carregar esse script em todas as páginas por padrão; ele entra onde o widget legado de carrinho precisa. Na prática ainda encontro o script em todo lugar, porque tema e plugin fazem o enqueue por conta própria. Meu jeito de tratar:
- Procurar na aba de rede requisições
get_refreshed_fragmentsem páginas que não mostram carrinho. - Se o carrinho do cabeçalho do tema depende dele, manter, mas tirar das páginas em que o cabeçalho não mostra contador, ou trocar pelo bloco de mini carrinho, que funciona de outro jeito.
- Se ninguém precisa, remover o script. Depois testar o adicionar ao carrinho numa página cacheada e confirmar que o contador ainda atualiza onde aparece.
Essa é uma das mudanças que também meço do lado do servidor, porque tirar uma requisição sem cache de cada visualização de página baixa a carga de PHP nos picos de tráfego.
O WooCommerce precisa de cache de objetos persistente?
Para loja com tráfego de verdade, precisa. Sem cache de objetos persistente, o WordPress guarda resultado de consulta só durante uma requisição. Com Redis ou Memcached, opções, dados de produto, consultas de termos e transients ficam em memória entre requisições, e toda requisição sem cache fica mais curta: carrinho, checkout, minha conta e painel. Dois cuidados que aprendi em auditoria: o cache de objetos só ajuda se a hospedagem der memória suficiente para ele, e as sessões de cliente do WooCommerce ficam numa tabela própria no banco, então o cache de objetos não substitui um banco saudável. Configuração e testes estão no guia de Redis object cache no WordPress.
Vale migrar para o High-Performance Order Storage?
O HPOS guarda os pedidos em tabelas dedicadas, em vez de espalhá-los por wp_posts e wp_postmeta. As consultas de pedido ficam mais simples e as tabelas de posts e postmeta ficam menores, o que ajuda tanto a gravação no checkout quanto as telas de pedido do painel. Lojas novas já usam HPOS por padrão nas versões recentes; lojas antigas precisam migrar.
A opção fica em WooCommerce > Configurações > Avançado > Recursos. Minha rotina de migração:
- Confirmar que todas as extensões ativas declaram compatibilidade com HPOS. O WooCommerce mostra um aviso quando alguma não declara.
- Ligar o modo de compatibilidade para os pedidos sincronizarem nos dois armazenamentos e esperar a sincronização terminar.
- Trocar o armazenamento principal para HPOS em staging e testar checkout, reembolso, e-mails de pedido e qualquer integração que leia pedidos (ERP, nota fiscal, frete).
- Repetir em produção, acompanhar por um tempo e então desligar o modo de compatibilidade. Deixar a sincronização ligada para sempre significa gravar cada pedido duas vezes.
O que mais deixa lenta a parte sem cache?
Depois de cache e HPOS, é nas requisições sem cache que a loja perde tempo. As causas de sempre:
- Opções autoload grandes em
wp_options, carregadas em toda requisição. O WordPress 6.6 trouxe uma verificação de tamanho de autoload na Saúde do Site. O guia de otimização do banco de dados do WordPress mostra como achar as linhas pesadas. - Transients expirados e uma tabela
wp_actionscheduler_actionscom anos de ações concluídas. - Filtros de produto que rodam meta queries sem índice em catálogos grandes.
- Extensões chamando API externa (cálculo de frete, serviço de imposto, verificação de licença) durante a requisição.
- Poucos PHP workers para o tráfego do checkout, e as requisições fazem fila no servidor.
O Query Monitor, em staging ou só para um usuário administrador, mostra as consultas lentas e as chamadas HTTP externas de cada requisição. É por ali que começo quando o TTFB do checkout está alto.
Como acelerar as páginas de produto e de categoria?
São as páginas que o Google mais mede, e quase tudo que vale para qualquer página WordPress vale aqui. O que é específico de loja:
- Galeria de produto. A imagem principal costuma ser o elemento LCP. Não aplique lazy load nela, entregue no tamanho em que aparece e em WebP ou AVIF, e confira se o script da galeria não troca a imagem depois do carregamento.
- Seletores de variação e zoom da galeria acrescentam JavaScript que roda na interação. Teste o INP num produto com muitas variações, não num produto simples.
- Páginas de categoria com filtros. Plugin de filtro costuma carregar script e CSS completos em todas as páginas. Restrinja à loja e às categorias.
- Tags de terceiros. Pixel de anúncio, widget de avaliações e chat muitas vezes somam mais JavaScript que o próprio WooCommerce. Revise com o time de marketing e tire as que ninguém consulta.
O detalhe por métrica está em Core Web Vitals no WooCommerce e no guia de como corrigir o INP no WordPress.
O que medir na otimização de velocidade do WooCommerce?
Meça catálogo e checkout separados, porque eles falham por motivos diferentes:
- LCP, INP e CLS de campo para os templates de produto e categoria, no Search Console ou no CrUX
- TTFB numa página de produto em cache e numa requisição sem cache de carrinho ou checkout
- quantidade de requisições
wc-ajaxsem cache por visualização de página - consultas lentas e chamadas HTTP externas no checkout, pelo Query Monitor
- tempo de carregamento da lista de pedidos no painel, antes e depois do HPOS
Se o que dói é o painel, escrevi um guia separado sobre admin do WooCommerce lento.
Perguntas frequentes
Dá para cachear o checkout do WooCommerce?
Não. O checkout precisa ser gerado para cada cliente. O caminho é deixar rápida a requisição sem cache, com cache de objetos, banco enxuto, PHP workers suficientes e poucas chamadas externas.
Preciso de uma hospedagem específica para WooCommerce?
Você precisa de uma hospedagem que entenda as exceções de cache acima, ofereça Redis ou Memcached e tenha PHP workers suficientes para os picos. Algumas vendem isso como hospedagem WooCommerce; confira os recursos, não o rótulo.
Desativar cart fragments é seguro?
É seguro quando nenhum elemento visível depende deles. Depois de remover, teste o fluxo de adicionar ao carrinho e o carrinho do cabeçalho numa página cacheada.
Se a sua loja perde tempo no checkout ou reprova nos Core Web Vitals nas páginas de produto e você quer alguém para achar a causa, é exatamente esse o meu trabalho como consultor WooCommerce: diagnostico a loja, priorizo as correções e confiro tudo com dados de campo. Quando o plano precisa de mão na massa, a equipe da WebOption faz a implementação.