--- title: "Admin WooCommerce lento: como resolver" id: "589" type: "post" slug: "admin-woocommerce-lento" published_at: "2026-10-06T20:00:50+00:00" modified_at: "2026-10-06T20:00:50+00:00" url: "https://danielpazwp.com/pt/admin-woocommerce-lento/" markdown_url: "https://danielpazwp.com/pt/admin-woocommerce-lento.md" excerpt: "Por que o painel do WooCommerce fica lento e como resolver: Query Monitor, HPOS, autoload, Action Scheduler, cron no servidor e cache de objetos." taxonomy_category: - "Performance" --- [Performance](https://danielpazwp.com/pt/category/performance-pt/) 7 min de leitura # Admin WooCommerce lento: como resolver Por que o painel do WooCommerce fica lento e como resolver: Query Monitor, HPOS, autoload, Action Scheduler, cron no servidor e cache de objetos. Publicado **06/10/2026**7 min de leitura [Escrito porDaniel Paz](https://danielpazwp.com/pt/author/daniel-paz/) Um admin WooCommerce lento quase sempre vem de trabalho que roda em toda requisição do painel e nunca passa pelo cache de página: opções autoload grandes, consultas de pedido numa tabela `wp_postmeta` inchada, fila acumulada no Action Scheduler, importações do Analytics e extensões que chamam API externa ou verificam licença a cada tela. Para resolver, analise uma tela lenta com o Query Monitor, migre os pedidos para o High-Performance Order Storage, limpe o autoload e as ações agendadas, rode o WP-Cron pelo servidor, ative um cache de objetos persistente e garanta que a hospedagem dê PHP workers e memória suficientes para o painel. O front-end da loja recebe toda a atenção porque é ele que o Google mede. O painel é onde a equipe trabalha o dia inteiro, e uma tela que leva vários segundos para abrir custa horas de verdade toda semana. Abaixo está como eu trato isso nas auditorias. Para a vitrine, veja o guia de [otimização de velocidade do WooCommerce](https://danielpazwp.com/pt/otimizacao-velocidade-woocommerce/) ; os dois fazem parte do guia de [como acelerar o WordPress](https://danielpazwp.com/pt/como-acelerar-wordpress/) . ## Por que o painel do WooCommerce é lento se a loja é rápida? Porque o cache de página esconde a maior parte dos problemas do visitante e nenhum do administrador. Toda requisição do painel é logada e sem cache. O WordPress carrega todos os plugins ativos, todas as opções autoload, os menus que cada plugin registra e o que cada plugin decidiu rodar no `admin_init`. Se o front-end só é rápido por causa do cache, o painel mostra a velocidade real do site. ## Como descobrir o que deixa uma tela lenta? Chutar aqui é perda de tempo. Instalo o [Query Monitor](https://wordpress.org/plugins/query-monitor/) em staging, ou em produção só para o meu usuário, e abro a tela mais lenta. Ele mostra: - tempo total de geração da página e pico de memória - consultas ao banco agrupadas pelo plugin ou componente do tema que rodou cada uma, com as lentas e as duplicadas destacadas - chamadas HTTP externas feitas durante a requisição, com o tempo de cada uma - erros e avisos de PHP, que pesam quando são milhares Duas ou três telas costumam contar a história toda: a lista de pedidos, a edição de produto e a página inicial do WooCommerce ou do Analytics. Anote os números antes de mudar qualquer coisa, para conseguir provar a correção depois. ## Causas comuns de admin WooCommerce lento e o que fazer | Sintoma no Query Monitor | Causa provável | Correção | | --- | --- | --- | | Consultas lentas em wp_postmeta ao listar ou buscar pedidos | Pedidos guardados como posts numa loja grande | Migrar para o High-Performance Order Storage | | Muito tempo antes da primeira consulta, memória alta | Opções autoload grandes | Achar e limpar as linhas autoload pesadas | | Chamadas HTTP externas de um segundo ou mais | Extensões verificando licença, atualização, feed ou painel remoto | Atualizar, configurar ou trocar a extensão; cachear a resposta | | Muitas consultas nas tabelas wp_actionscheduler_* | Fila acumulada no Action Scheduler ou tabelas de log enormes | Limpar ações concluídas e com falha; corrigir o job que falha | | Página inicial do WooCommerce ou Analytics demorando a mostrar dados | Importação do Analytics ou relatórios sobre um histórico grande de pedidos | Deixar a importação terminar; agendar fora do horário de pico | | Toda tela lenta, nada se destaca | Poucos PHP workers ou pouca memória, sem cache de objetos | Resolver a camada de hospedagem | ## Migre os pedidos para o High-Performance Order Storage Nas lojas mais antigas, os pedidos ficam em `wp_posts`, com todos os dados em `wp_postmeta`. Uma loja com anos de pedidos termina com uma tabela postmeta gigante, e a lista de pedidos, a busca e os relatórios precisam consultá-la. O HPOS leva os pedidos para tabelas feitas para eles. A opção fica em WooCommerce > Configurações > Avançado > Recursos. Confira a compatibilidade das extensões, ligue a sincronização, espere terminar, troque em staging, teste e só então troque em produção. Quando estiver seguro, desligue o modo de compatibilidade, porque sincronizar os dois armazenamentos a cada pedido é trabalho extra. A sequência completa está no [guia de velocidade do WooCommerce](https://danielpazwp.com/pt/otimizacao-velocidade-woocommerce/) . ## Limpe autoload, transients e ações agendadas Opções autoload são carregadas em toda requisição, no front-end e no painel. Plugins antigos deixam linhas grandes para trás, e alguns plugins ativos guardam log ou cache como opção autoload. O WordPress 6.6 trouxe uma verificação na Saúde do Site que avisa quando os dados autoload estão grandes demais. Para achar as linhas pesadas, ordene a `wp_options` pelo tamanho de `option_value` nas entradas autoload, descubra a qual plugin cada uma pertence e desligue o autoload ou apague as linhas de plugins que você já removeu. Faça backup antes. As consultas e o raciocínio estão no guia de [otimização do banco de dados do WordPress](https://danielpazwp.com/pt/otimizacao-banco-de-dados-wordpress/) . O Action Scheduler é a fila de tarefas que o WooCommerce e muitas extensões usam. Ele aparece em WooCommerce > Status > Ações agendadas. Procure milhares de ações com falha no mesmo hook, sinal de um job que falha e tenta de novo sem parar, e um volume grande de ações concluídas e logs. Corrija primeiro o job que falha; limpar a tabela sem resolver a causa só ganha algumas semanas. ## Rode o WP-Cron pelo servidor Por padrão o WP-Cron roda quando alguém visita o site, administradores inclusive. Numa loja movimentada, isso faz tarefa agendada rodar de vez em quando no meio do carregamento de uma tela do painel. Eu desligo o disparo por visita com `define( 'DISABLE_WP_CRON', true );` no `wp-config.php` e rodo `wp cron event run --due-now` por um cron do sistema a cada minuto ou a cada poucos minutos, conforme a loja. O Action Scheduler também processa a fila pelo WP-Cron e por requisições assíncronas, então um cron confiável no servidor evita que a fila acumule. ## Desligue o que ninguém usa no painel Parte do custo do painel são recursos que a equipe nunca abre: - Widgets do painel inicial que consultam pedidos ou chamam API remota a cada visita - Painéis de marketing e recomendação que carregam conteúdo remoto - Extensões instaladas para uma campanha e nunca removidas Desative em staging e meça. Se o plugin é necessário mas pesa no painel, procure nas configurações dele uma opção de processamento em segundo plano ou de cache antes de trocá-lo. ## Resolva a camada de hospedagem Quando toda tela é lenta e nenhuma consulta ou chamada HTTP se destaca, o gargalo é o servidor. O que eu confiro: - versão de PHP suportada e atual, com OPcache ligado e com espaço sobrando - PHP workers suficientes para quem trabalha no painel ao mesmo tempo, somados ao tráfego do front-end - limite de memória do PHP que aguente importações e exportações grandes - cache de objetos persistente (Redis ou Memcached), que ajuda muito o painel porque nada ali passa pelo cache de página - banco de dados em armazenamento rápido e perto do servidor web Os guias de [ajuste de PHP-FPM e OPcache](https://danielpazwp.com/pt/php-fpm-opcache-wordpress-pt/) e de [Redis object cache](https://danielpazwp.com/pt/redis-object-cache-wordpress/) trazem os detalhes. ## E a Heartbeat API? A Heartbeat API do WordPress manda requisições AJAX periódicas a partir das abas abertas do painel, para bloqueio de edição e salvamento automático, entre outras coisas. Com muita gente deixando telas de pedido e produto abertas o dia todo, essas requisições se acumulam no servidor. Diminuir a frequência fora do editor é razoável. Desligar de vez quebra o bloqueio de edição e o salvamento automático, então não recomendo. ## Perguntas frequentes ### Plugin de cache acelera o painel do WooCommerce? O cache de página não, porque as telas do painel nunca são cacheadas. O cache de objetos persistente ajuda, porque guarda opções e resultados de consulta em memória também para requisições logadas. ### É seguro apagar entradas antigas do Action Scheduler? Ações concluídas e canceladas são histórico, e o próprio WooCommerce já limpa as antigas de tempos em tempos. Ações pendentes são trabalho que ainda vai rodar, então não apague essas. Faça backup das tabelas antes de qualquer limpeza manual. ### O HPOS deixa o painel mais rápido na hora? A lista e a busca de pedidos costumam melhorar quando os pedidos passam a ser lidos das tabelas novas. Telas lentas por outros motivos, como autoload pesado ou chamadas a API externa, só mudam quando você resolve essas causas. Se a sua equipe perde tempo todo dia num painel WooCommerce lento e você quer a causa encontrada e priorizada, faço esse diagnóstico como [consultor WooCommerce](https://danielpazwp.com/pt/consultor-woocommerce/) . Para uma revisão completa da loja, painel incluído, veja a minha [auditoria de performance WordPress](https://danielpazwp.com/pt/auditoria-performance-wordpress/) . [Trabalhe com o Daniel](https://danielpazwp.com/pt/#book) [Mais em Performance](https://danielpazwp.com/pt/category/performance-pt/) [Sobre o autorPágina do autor](https://danielpazwp.com/pt/author/daniel-paz/) ## Artigos relacionados [Todos os artigos](https://danielpazwp.com/pt/artigos/) [Performance out 2026Core Web Vitals: dados de campo vs laboratório](https://danielpazwp.com/pt/core-web-vitals-dados-de-campo-vs-laboratorio/) [Performance out 2026Page cache vs object cache vs edge cache: qual você precisa](https://danielpazwp.com/pt/page-cache-object-cache-edge-cache-qual-voce-precisa/) [Performance out 2026WordPress lento: os motivos estruturais e a ordem para corrigir](https://danielpazwp.com/pt/por-que-seu-wordpress-e-lento-motivos-estruturais/)