WordPress lento no painel é uma reclamação diferente daquela sobre o site lento para o visitante: a página pública carrega rápido, o PageSpeed aparece verde, mas quem publica conteúdo, responde a pedidos ou atualiza plugins fica esperando vários segundos a cada clique. A explicação é simples. O visitante quase sempre recebe uma página vinda do cache; o painel, nunca. Cada tela do wp-admin roda PHP, consulta o banco de dados e baixa dezenas de scripts e folhas de estilo.
Este artigo ensina a rastrear para onde o tempo está indo e apresenta uma alteração que a equipe de performance do core começou a liberar nesta semana: o mecanismo pelo qual o painel carrega seus scripts — o mesmo usado há mais de quinze anos — está sendo trocado.
Primeiro passo: localizar a origem da lentidão
“O painel está lento” pode significar três problemas distintos, cada qual com sua solução específica. Abra as ferramentas de desenvolvedor do navegador (aba Rede), recarregue uma tela do painel e examine a primeira linha, o documento HTML:
- Espera longa no documento (TTFB): o servidor está demorando para construir a página. O problema está no PHP, no banco de dados ou em chamadas externas.
- Documento rápido, mas muitos arquivos demorando: o gargalo está no carregamento de scripts e estilos, ou na ausência de cache deles no navegador.
- Tudo rápido, mas requisições a
admin-ajax.phpse acumulando: trata-se da Heartbeat API ou de algum plugin executando consultas em segundo plano.
Sem esse diagnóstico prévio, o caminho usual é instalar um plugin de otimização que mexe em tudo e não conserta nada.
As origens mais frequentes de WordPress lento no painel
Opções com autoload em excesso
Toda requisição ao WordPress, seja pública seja administrativa, carrega de uma só vez as opções marcadas como autoload na tabela wp_options. Plugins antigos, mal escritos ou já removidos deixam nesse lugar dados que ninguém mais utiliza. Desde o WordPress 6.6, a Saúde do Site sinaliza um problema crítico quando esse conjunto ultrapassa 800 KB, e opções acima de 150.000 bytes pararam de ser carregadas automaticamente por padrão.
Para listar as maiores, via WP-CLI:
wp db query "SELECT option_name, LENGTH(option_value) AS bytes
FROM $(wp db prefix)options
WHERE autoload IN ('yes','on','auto','auto-on')
ORDER BY bytes DESC LIMIT 20"
Antes de alterar qualquer opção, descubra a qual plugin ela pertence e faça backup do banco. O pacote wp doctor, mantido pela própria equipe do WP-CLI, traz uma checagem pronta (autoload-options-size) que alerta acima de 900 KB, além de outras verificações úteis: mais de 50 tarefas agendadas no cron, mais de 80 plugins ativos.
Plugins que chamam serviços externos a cada tela
Validação de licença, feed de novidades, estatísticas, avisos de promoção: muitos plugins disparam requisições HTTP para servidores de terceiros durante o carregamento do painel. Se o servidor remoto estiver lento, o seu painel acompanha a lentidão.
A ferramenta para visualizar isso é o plugin Query Monitor. Ele exibe as consultas ao banco por componente, as consultas duplicadas, as chamadas à HTTP API com duração e o plugin responsável, além dos hooks executados. Use em staging ou por tempo limitado em produção, e desative ao finalizar.
Heartbeat API com muitas abas abertas
A Heartbeat API mantém o navegador em diálogo com o servidor: é ela que realiza o salvamento automático e evita que duas pessoas editem o mesmo post simultaneamente. O custo é uma requisição POST a admin-ajax.php a cada 15 a 60 segundos, por aba aberta. Nenhuma dessas requisições pode ser entregue via cache, e cada uma consome um processo PHP. Uma equipe de cinco pessoas com três abas cada já representa carga constante num plano de hospedagem modesto.
Desligar a Heartbeat por completo quebra o salvamento automático. O ajuste sensato é ampliar o intervalo:
add_filter( 'heartbeat_settings', function ( $settings ) {
$settings['interval'] = 60;
return $settings;
} );
Servidor sem margem
O painel não aproveita o cache de página, por isso depende diretamente de três fatores: versão do PHP com OPcache ativo, quantidade de processos PHP disponíveis e cache de objetos persistente (Redis ou Memcached), que evita repetir consultas ao banco. Se o diagnóstico indicar TTFB alto mesmo com poucos plugins, o assunto é com a hospedagem. Já publicamos sobre como otimizar o TTFB e sobre quando desativar o WP-Cron, que também sobrecarrega sites com muitas tarefas agendadas.
O que muda no carregamento de scripts do wp-admin
Há mais de quinze anos, o painel agrupa os scripts e estilos do core em poucos arquivos grandes, montados na hora por dois endpoints PHP: load-scripts.php e load-styles.php. Na época, a abordagem fazia sentido, pois cada requisição HTTP era custosa. Hoje, a técnica tem custos conhecidos, documentados no ticket #57548 do Trac:
- cada tela recebe um pacote diferente, o que impede o navegador de reaproveitar o cache de uma tela para outra;
- montar o pacote consome memória do servidor; um provedor de hospedagem registrou picos de 1,9 GB, e há relatos de erro 503 no editor em servidores com menos de 1,5 GB;
- os dois endpoints representam uma superfície de ataque que plugins de segurança frequentemente restringem;
- ambos silenciam erros de PHP, o que complica a depuração.
O contraponto, anotado no mesmo ticket, é que agrupar arquivos ainda tende a ser mais rápido na primeira visita, quando o navegador não possui nada em cache. Apenas desativar a concatenação tornaria o primeiro acesso mais lento.
A solução: prefetch dos arquivos da próxima tela
No resumo do chat de performance de 6 de outubro de 2026, Weston Ruter anunciou que o prefetch foi incorporado ao core (changeset 64120). A nova função wp_prefetch_admin_assets(), marcada para a versão 7.2, imprime tags <link rel="prefetch"> com os arquivos da tela que o usuário provavelmente abrirá em seguida. Ela atua em dois pontos: na tela de login, antecipando o painel, e no painel inicial e nas listagens de posts, antecipando os estilos do editor.
Os números divulgados no pull request (Chrome, ambiente local, mediana de 10 execuções) explicam por que as duas mudanças caminham juntas:
| Cenário | LCP em 4G rápido | LCP em 4G lento |
|---|---|---|
| Concatenação ligada (padrão atual) | 1.134 ms | 3.494 ms |
| Concatenação desligada, sem prefetch | 1.412 ms | 3.806 ms |
| Concatenação desligada, com prefetch | 840 ms | 1.872 ms |
São medições do autor em um único navegador, com rede simulada. Funcionam como indicação de direção, não como promessa para o seu servidor.
O próximo passo anunciado é desativar a concatenação por padrão fora de ambientes de desenvolvimento e, depois, eliminar os dois endpoints. Até a data deste artigo, essa parte ainda estava em revisão. O Beta 1 do WordPress 7.2 está previsto para 20 de outubro e a versão final para 8 de dezembro; o que não entrar até o beta fica para o ciclo seguinte.
O detalhe que depende do seu servidor
O mesmo pull request inclui um teste que merece atenção. Sem cabeçalhos de cache explícitos, após 241 segundos apenas 6 de 24 arquivos pré-carregados foram reaproveitados; os demais foram revalidados. Com Cache-Control: max-age=31536000, todos foram reaproveitados.
Ou seja: o benefício do novo modelo depende de o servidor enviar cabeçalhos de cache longos para os arquivos estáticos de /wp-admin/ e /wp-includes/. Vale verificar agora:
curl -sI https://seusite.com.br/wp-includes/css/dashicons.min.css | grep -i cache-control
Se não vier nada, ou vier um prazo curto, o ajuste fica na configuração do servidor web ou da CDN.
Dá para testar antes do 7.2?
Sim. A concatenação já pode ser desativada com uma constante que existe há muitos anos:
// wp-config.php
define( 'CONCATENATE_SCRIPTS', false );
É um teste de diagnóstico clássico quando o painel aparece sem estilo ou retorna erro 503 em load-scripts.php. Em staging, ela revela como o seu painel se comporta com arquivos separados: se os cabeçalhos de cache estão corretos, se o servidor usa HTTP/2 e se algum plugin depende do comportamento antigo. Sem o prefetch do 7.2, o primeiro acesso tende a ficar um pouco mais lento, como indica a tabela.
E os agentes de IA nesse cenário?
Um agente que opera o site via REST API ou MCP não carrega scripts do painel, mas disputa os mesmos processos PHP, o mesmo banco e as mesmas opções em autoload. Um backend que mal dá conta de cinco editores não vai atender bem cinco editores e um agente disparando dezenas de chamadas por minuto. Organizar o painel é também preparar o terreno para automação.
Conclusão
Painel lento raramente tem uma causa única, e quase nunca se resolve com mais um plugin. O caminho é medir: separar tempo de servidor de tempo de carregamento, examinar opções em autoload, chamadas externas e Heartbeat, e só então agir. A mudança no carregamento de scripts que começa a chegar com o 7.2 ajuda, desde que o servidor esteja configurado para aproveitar o cache.
Se o painel do seu WordPress está atrapalhando a rotina da equipe, a Amicatek faz esse levantamento para você. Peça um diagnóstico do seu site e receba a lista do que está pesando e do que corrigir primeiro, ou conheça o nosso plano de manutenção WordPress, que inclui esse acompanhamento de forma contínua.
Fontes
- Performance Chat Summary: 6 October 2026 — Make WordPress Core
- Ticket #57548: Stop concatenating scripts and stylesheets in wp-admin — WordPress Trac
- Pull request #13084: Script Loader: Prefetch assets for the next admin screen — wordpress-develop
- WordPress 7.2: cronograma de lançamento — Make WordPress Core
- Options API: Disabling autoload for large options — Make WordPress Core
- Default doctor diagnostic checks — WP-CLI Handbook
- Taming the Heartbeat API — Delicious Brains
- Query Monitor — WordPress VIP Documentation