WooCommerce lento: as causas reais e o que fazer (em 10 minutos)
WooCommerce é ótimo até a loja crescer. Quando passa de 5 mil produtos ou ~100 pedidos/dia, começam os gargalos clássicos. Este guia mostra os culpados habituais e como diagnosticar em 10 minutos.
- Por que WooCommerce escalado vira lento — não é o WordPress, é o admin-ajax.
- Como descobrir em 10 minutos qual plugin está destruindo TTFB.
- O drama do Action Scheduler e como o pedido fica perdido nele.
- Stack de cache que funciona pra WooCommerce real (não a do post genérico).
WooCommerce é a plataforma de e-commerce mais usada do mundo — cerca de 28% dos sites de e-commerce rodam em WooCommerce.[1] Funciona muito bem para loja pequena/média e começa a ranger quando cresce — catálogo passa de uns 5 mil produtos, tráfego passa de algumas centenas de visitas simultâneas, integrações se multiplicam. Este guia é o conjunto de gargalos que aparece quase sempre nesse momento.
O primeiro gargalo: admin-ajax.php
WordPress (e WooCommerce) tem um endpoint mágico chamado admin-ajax.php. Plugins usam esse endpoint para qualquer chamada assíncrona — analytics, sliders, contadores de visitante online, popups. Cada request vai pro endpoint que carrega o WordPress inteiro, com todos os plugins e tema, só para responder "ok".
Em loja com muito plugin e alto tráfego, admin-ajax.php sozinho responde por metade da carga de PHP. Diagnóstico:
- Olhe o log do Nginx/Apache de hoje.
- Conte requests por endpoint:
awk '{print $7}' access.log | sort | uniq -c | sort -rn | head - Se
admin-ajax.phpestá no top 3 e você não tem feature ajax visível de cliente usando, tem plugin "fazendo barulho à toa".
Solução: identificar o plugin (via Query Monitor ou New Relic) e ou trocar por alternativa que use REST API, ou cachear a resposta com nginx fastcgi cache.
Action Scheduler: a fila silenciosa
WooCommerce 3.4+ usa o Action Scheduler — uma biblioteca de cron baseada no próprio banco do WordPress. [2] Tudo que é "executar depois" passa por lá: enviar email, atualizar estoque, marcar pedido como concluído, sincronizar com ERP.
Os 3 problemas clássicos do Action Scheduler:
- Tabelas inchando.
wp_actionscheduler_actionschega facilmente a milhões de linhas em loja média sem rotina de purge. Toda query no admin do WooCommerce passa por essa tabela. UseWC_Action_Queue::cancel_all_actionse configure retenção de 30 dias. - Action que sempre falha bloqueia a fila. Se uma action lança exception não tratada, ela trava em "in-progress" e o agendador respeita o slot. Outras actions ficam esperando.
- WP-Cron não roda no horário esperado. WP-Cron padrão depende de tráfego no site para disparar. Em loja sem tráfego nos finais de semana, actions se acumulam. Mude para cron real do sistema operacional:
* * * * * php wp-cron.php.
Banco MySQL: as tabelas que matam
A queries lentas em WooCommerce caem quase sempre nas mesmas 5 tabelas:
| Tabela | Por que costuma estar inchada | Mitigação |
|---|---|---|
wp_options | Plugins gravam transients sem expirar e options "autoload yes" | Auditoria mensal: SELECT option_name FROM wp_options WHERE autoload = 'yes' ORDER BY LENGTH(option_value) DESC LIMIT 50 |
wp_postmeta | Cada produto tem dezenas de metas; plugin de catálogo dobra esse número | Índices custom; arquivar postmeta de produtos descontinuados |
wp_actionscheduler_actions | Milhões de actions completed sem purge | Setting de retenção (Settings → Status → Tools) |
wp_woocommerce_sessions | Sessões anônimas de bots não expiram | WC_Session::cleanup_sessions() agendado diário |
wp_comments | Spam não moderado e reviews antigas | Akismet + purge automático de spam > 30 dias |
wc_orders em vez de wp_posts). Em loja com mais de 50 mil pedidos, a diferença é radical. Habilite em WooCommerce → Status → Tools → Custom Order Tables.[3]Plugins que entram na "lista vermelha"
Lista não-científica baseada em análise de centenas de WooCommerces lentos — plugins que quase sempre aparecem nos top consumidores quando você ativa Query Monitor:
- Plugins de "live visitor count" — escrevem em
wp_optionsa cada visita. - Plugins de "wishlist" sem cleanup — acumulam meta com nome de produto desativado.
- Slider/carrossel com queries no front — buscam produto recomendado em runtime, sem cache.
- Page Builder pesado (Elementor com Pro, Divi) em página de produto — DOM enorme, JS pesado, INP destruído.
- Plugin de "estoque baixo" que verifica estoque em cada page view em vez de em update de pedido.
Stack de cache que funciona
Para WooCommerce médio (até ~50 mil produtos, ~100 mil pedidos/ano), essa stack funciona:
- Nginx fastcgi cache para HTML de páginas públicas (home, categoria, produto, blog). Bypass automático em rotas
/cart,/checkout,/my-account,/wp-admin, e quando cookiewoocommerce_items_in_cartestá setado. - Redis para object cache do WordPress (
wp_optionstransient cache, queries memoizadas). - OPcache PHP com
opcache.max_accelerated_files=20000. WooCommerce e plugins facilmente têm 10 mil arquivos PHP. - Cloudflare na frente para estático + Argo Smart Routing se você tem clientes internacionais.
Checklist rápido
- HPOS habilitado se loja tem > 50 mil pedidos.
- WP-Cron substituído por cron do sistema.
- Retenção do Action Scheduler em 30 dias ou menos.
wp_optionscom autoload < 1 MB.- Object cache (Redis) ativo.
- Nginx fastcgi cache configurado com bypass certo.
- Query Monitor instalado em staging para identificar plugin culpado.
- Action Scheduler monitorado (alerta se > 1000 actions pending por > 1h).
Veja também Core Web Vitals para loja virtual para a parte de front-end e como detectar pedidos travados (a lógica do Magento se aplica direto ao Action Scheduler do WooCommerce).
Referências
- w3techs / BuiltWith. Usage statistics of e-commerce technologies. w3techs.com · trends.builtwith.com
- Automattic / WooCommerce. Action Scheduler — Background Processing for WordPress. actionscheduler.org
- WooCommerce. High-Performance Order Storage (HPOS) — Adoption Guide. developer.woocommerce.com/docs/hpos
- Query Monitor (John Blackbourn). Plugin official site. querymonitor.com
- Kinsta. WooCommerce Performance — Definitive Guide. kinsta.com/blog
- WP Engine. WooCommerce Site Speed Best Practices. wpengine.com/resources
Perguntas frequentes
- HPOS resolve o problema de performance do WooCommerce?
- Para lojas com mais de 50 mil pedidos, sim — radicalmente. HPOS move os pedidos de wp_posts/wp_postmeta para tabelas próprias (wc_orders), eliminando o gargalo histórico. Para lojas menores, ajuda pouco.
- Quantos plugins é "muito" em WooCommerce?
- Não é número, é peso. 25 plugins leves podem ser melhor que 5 pesados. A faixa onde aparecem problemas é 5–11 plugins — onde alguns invariavelmente são "lista vermelha" (live visitor count, slider pesado, page builder de produto).
- Vale a pena trocar WP-Cron por cron do sistema?
- Sempre. WP-Cron padrão depende de tráfego pra disparar — em loja sem visita no fim de semana, actions acumulam. Mude para cron real (* * * * * php wp-cron.php) e desative WP-Cron no wp-config (define WP_CRON true como false).
Continue lendo
Monitore tudo isso automaticamente
A Especialista Loja Virtual roda navegação real no seu site a cada poucos minutos, alerta no Discord, Slack ou e-mail e mostra screenshot do incidente. Comece grátis.