Skip to content
Especialista LV
WooCommerce12 min de leitura

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.

Laptop aberto com ambiente de desenvolvimento web
WooCommerce é ótimo até a loja crescer. Quando passa de 5 mil produtos ou 100+ pedidos/dia, os gargalos clássicos aparecem juntos.Unsplash
O que você vai aprender
  • 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.

~28%
share de WooCommerce no mercado mundial de e-commerce
w3techs / BuiltWith 2024
~6 mi
sites no mundo rodam WooCommerce, segundo o BuiltWith
BuiltWith
5–11
plugins é a faixa onde a maioria das lojas começa a ter problema de performance
WP Engine / Kinsta analyses
~70%
do TTFB ruim em WooCommerce está no banco (queries de plugin) — não no PHP em si
Query Monitor — relatórios setoriais

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:

  1. Olhe o log do Nginx/Apache de hoje.
  2. Conte requests por endpoint: awk '{print $7}' access.log | sort | uniq -c | sort -rn | head
  3. Se admin-ajax.php está 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.

Mãos sobre teclado de MacBook em mesa de trabalho
admin-ajax.php sozinho responde por metade da carga de PHP em WooCommerce com muito plugin. Plugin de 'live visitor count' adora esse endpoint.Unsplash

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.

Action Scheduler is the most under-monitored piece of WooCommerce infrastructure.— Patrick Rauland, ex-engineer WooCommerce

Os 3 problemas clássicos do Action Scheduler:

  • Tabelas inchando. wp_actionscheduler_actions chega facilmente a milhões de linhas em loja média sem rotina de purge. Toda query no admin do WooCommerce passa por essa tabela. Use WC_Action_Queue::cancel_all_actions e 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:

TabelaPor que costuma estar inchadaMitigação
wp_optionsPlugins 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_postmetaCada produto tem dezenas de metas; plugin de catálogo dobra esse númeroÍndices custom; arquivar postmeta de produtos descontinuados
wp_actionscheduler_actionsMilhões de actions completed sem purgeSetting de retenção (Settings → Status → Tools)
wp_woocommerce_sessionsSessões anônimas de bots não expiramWC_Session::cleanup_sessions() agendado diário
wp_commentsSpam não moderado e reviews antigasAkismet + purge automático de spam > 30 dias
📌 HPOS (High-Performance Order Storage): desde o WooCommerce 8.2, dá pra migrar pedidos pra tabela própria (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_options a 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.
Checklist em prancheta com itens marcados
HPOS desde a 8.2, cron Unix em vez de WP-Cron, Action Scheduler com retenção de 30 dias, Redis ativo — o checklist básico do WooCommerce grande.Unsplash

Stack de cache que funciona

Para WooCommerce médio (até ~50 mil produtos, ~100 mil pedidos/ano), essa stack funciona:

  1. 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 cookie woocommerce_items_in_cart está setado.
  2. Redis para object cache do WordPress (wp_options transient cache, queries memoizadas).
  3. OPcache PHP com opcache.max_accelerated_files=20000. WooCommerce e plugins facilmente têm 10 mil arquivos PHP.
  4. Cloudflare na frente para estático + Argo Smart Routing se você tem clientes internacionais.

Checklist rápido

  1. HPOS habilitado se loja tem > 50 mil pedidos.
  2. WP-Cron substituído por cron do sistema.
  3. Retenção do Action Scheduler em 30 dias ou menos.
  4. wp_options com autoload < 1 MB.
  5. Object cache (Redis) ativo.
  6. Nginx fastcgi cache configurado com bypass certo.
  7. Query Monitor instalado em staging para identificar plugin culpado.
  8. 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).

✓ Próximo passo: instale o plugin Query Monitor em staging por 24h, navegue pelas páginas mais acessadas (home, categoria, top-5 produtos), e olhe o ranking de "Slowest queries" e "Component time". Em 99% dos casos, o gargalo aparece em um único plugin que você nem sabia que estava lá.

Referências

  1. w3techs / BuiltWith. Usage statistics of e-commerce technologies. w3techs.com · trends.builtwith.com
  2. Automattic / WooCommerce. Action Scheduler — Background Processing for WordPress. actionscheduler.org
  3. WooCommerce. High-Performance Order Storage (HPOS) — Adoption Guide. developer.woocommerce.com/docs/hpos
  4. Query Monitor (John Blackbourn). Plugin official site. querymonitor.com
  5. Kinsta. WooCommerce Performance — Definitive Guide. kinsta.com/blog
  6. 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.

Criar conta grátisVer planos