Saltar para o conteúdo 
A API Heartbeat do WordPress causa lentidão em hospedagens partilhadas devido a pings AJAX frequentes através do admin-ajax.php. Carga do servidor e isso causa um atraso perceptível no backend. Vou mostrar como domar a frequência do heartbeat com segurança, reduzir a carga do servidor wordpress e manter funções importantes, como o autosave.
Pontos centrais
- frequência cardíaca Prolongar de forma direcionada em vez de desativar completamente.
- Autosave Guardar no editor, parar pings desnecessários.
- Recursos partilhados Proteger: CPU, RAM, E/S sob controlo.
- Monitorização antes/depois da otimização para efeitos claros.
- Holística Otimização: cache, banco de dados, CDN, versão PHP.
Entender o Heartbeat: função útil com custos
A API Heartbeat envia pedidos AJAX periódicos, normalmente a cada 15 segundos no painel, para manter sessões e guardar rascunhos; estes Frequência tem o seu preço. Cada ping atinge o admin-ajax.php e desencadeia processos PHP, acessos à base de dados e, se necessário, plugins hooks. Se o navegador permanecer minimizado, a comunicação geralmente continua e gera picos de carga. As guias abertas multiplicam as solicitações e reduzem o tempo de resposta do editor. Em sistemas altamente compartilhados, isso leva a processos lentos, autoguardamentos atrasados e um trabalho subjetivamente „pesado“.
Por que o alojamento partilhado é particularmente afetado
Na hospedagem partilhada, partilho CPU, RAM e I/O com sites vizinhos, pelo que pedidos adicionais podem Capacidade esgotar mais rapidamente. Se vários utilizadores se juntarem ou se o painel de controlo permanecer aberto durante horas, os pings acumulam-se e bloqueiam os PHP-Workers. Em seguida, o TTFB e os tempos de espera no administrador aumentam, e a carga do servidor wordpress atinge picos curtos. Com cargas simultâneas de sites vizinhos, ocorre uma reação em cadeia: os cache hits diminuem, os bloqueios do banco de dados aumentam e o editor fica lento. Assim, transformo involuntariamente uma função de conforto numa fonte de carga.
Reconhecer os sintomas atempadamente
Se eu notar cliques lentos no backend, um número anormalmente elevado de pedidos POST no DevTools e entradas instáveis no editor, tudo indica que os pings de heartbeat são a causa. Condutores Avisos do host devido a picos de CPU ou limites de memória também se encaixam neste quadro. Core Web Vitals mais fracos no contexto administrativo e pontuações de PageSpeed em queda também podem ser sinais indiretos. Nos registos, vejo acumulações de acessos admin-ajax.php com ação „heartbeat“. Se esses efeitos ocorrerem durante o processamento inativo, as guias em segundo plano desperdiçam recursos valiosos.
Quantas solicitações realmente são geradas? Um cálculo rápido
Um intervalo padrão de 15 segundos gera quatro pings por minuto por separador. Três separadores de administração abertos significam, portanto, 12 pedidos de heartbeat por minuto – por editor. Se duas pessoas estiverem a trabalhar em paralelo, são já 24 por minuto, ou seja, 1440 por hora. Se eu definir o intervalo na administração para 60 segundos, reduzo a mesma carga para três pings por minuto e por pessoa. No exemplo acima, o número diminui de 24 para 6 por minuto: uma redução de 75 %. Este cálculo simples explica por que o tempo de resposta percebido melhora significativamente após uma redução.
Assumir o controlo: plugins ou código
Primeiro, defendo uma regra clara: aumentar a frequência em vez de agir cegamente. desligar. Com ferramentas como Heartbeat Control, WP Rocket ou LiteSpeed Cache, defino 30-60 segundos no Admin, 120-180 segundos no Frontend e desativo pings em páginas sem interação. Quem preferir código pode desacelerar a API seletivamente. Exemplo: definir intervalos de 60 segundos e deixar apenas o autosave no editor. Assim, reduzo a carga sem perder a segurança do conteúdo.
// Ajustar intervalos add_filter('heartbeat_settings', function($settings) { $settings['interval'] = 60; // Segundos return $settings; });
// Desativar o Heartbeat, por exemplo, no frontend add_action('init', function() { if ( ! is_admin() ) wp_deregister_script('heartbeat'); }, 1);
Editor de blocos vs. Clássico: o que o Heartbeat realmente faz no editor
No Editor Clássico, o Autosave baseia-se diretamente no Heartbeat. No Editor de Blocos (Gutenberg), o Autosave funciona principalmente através da API REST, mas o Heartbeat continua a realizar tarefas importantes, como bloqueio de publicações e verificações de sessão. Conclusão prática: um prolongamento moderado (30-60 s) não interrompe o Autosave no editor de blocos, mas pode atrasar a atualização de bloqueios e mensagens de estado. Por isso, escolho intervalos mais curtos no editor do que no resto do Admin e testo com rascunhos reais se os bloqueios e avisos funcionam conforme o esperado.
Restrição seletiva por ecrã e função
Para obter o máximo controlo, regulo o Heartbeat dependendo do ecrã (Screen) e, se necessário, das funções do utilizador. Assim, o editor permanece rápido, enquanto as áreas administrativas tranquilas praticamente não geram pings.
// 1) Intervalos diferentes dependendo do ecrã add_filter('heartbeat_settings', function($settings) { if ( function_exists('get_current_screen') ) { $screen = get_current_screen();
if ( $screen && in_array($screen->id, ['post','page','product']) ) { $settings['interval'] = 30; // Editor: mais frequente para autosave/bloqueio
} else { $settings['interval'] = 60; // restante Admin } } return $settings; }); // 2) Carregar Heartbeat no Admin apenas onde necessário add_action('admin_enqueue_scripts', function($hook) {
$allowed = ['post.php', 'post-new.php', 'site-editor.php']; // Contextos do editor if ( ! in_array($hook, $allowed, true) ) { wp_deregister_script('heartbeat'); } }, 1);
// 3) Tratar o frontend de forma diferenciada (por exemplo, para utilizadores conectados) add_action('wp_enqueue_scripts', function() { if ( ! is_user_logged_in() ) { wp_deregister_script('heartbeat'); // Visitantes: não é necessário Heartbeat } }, 1);
// Opcional: harmonizar o intervalo de autoguarda add_filter('autosave_interval', function() { return 60; });Com esta configuração, as funções ao vivo permanecem ativas onde são úteis e desaparecem em áreas sem interação. No contexto da loja ou do checkout, mantenho o Heartbeat ativo e breve, enquanto no restante do frontend ele permanece desativado.
Intervalos razoáveis e exceções
Mantenho o editor funcional enquanto elimino pings desnecessários em páginas tranquilas, porque Autosave continua a ser essencial. 60 segundos no Admin costuma ser o ponto ideal entre segurança e carga. No frontend, geralmente não preciso do Heartbeat, com exceção dos componentes ao vivo. Para lojas ou interfaces de utilizador dinâmicas, planeio ciclos mais curtos apenas onde há entradas. Assim, a página permanece rápida e estável, sem comprometer o conteúdo.
| Contexto | Intervalo recomendado | Nota |
|---|---|---|
| Painel geral | 60 s | Carga diminui significativamente, as sessões permanecem ativas. |
| Pós-editor | 30–60 s | Autosave e bloqueio continuam disponíveis. |
| Front-end estático | Desativar | Sem interação, portanto, sem necessidade de pings. |
| Front-end interativo (por exemplo, checkout) | 15–30 s | Apenas nos casos afetados Páginas ativar. |
| Separadores de administração abertos por muito tempo | 90–120 s | Poupe recursos mantendo o separador em segundo plano. |
Otimizar a carga útil do Heartbeat: menos dados por ping
Além da frequência, a quantidade de dados transmitidos também é importante. Alguns plugins anexam informações adicionais ao Heartbeat. Através de filtros, posso reduzir ainda mais a carga do servidor, cortando cargas inúteis ou simplificando respostas.
// Serverantwort für Heartbeat-Anfragen optimieren
add_filter('heartbeat_send', function($response, $data, $screen_id) {
// Beispiel: große, selten benötigte Blöcke entfernen
unset($response['irrelevante_status']);
// Eigene, zu große Daten nicht mitschicken
if ( isset($data['my_plugin_heavy']) ) {
unset($data['my_plugin_heavy']);
}
return $response;
}, 10, 3);
// Auf eingehende Heartbeat-Daten reagieren (z.B. Logging vermeiden)
add_action('heartbeat_received', function($response, $data, $screen_id) {
// Teure Vorgänge nur auf relevanten Screens ausführen
if ( $screen_id !== 'post' ) {
// ggf. Frühabbruch in eigenen Hooks
}
}, 10, 3);Em seguida, verifico o tamanho das respostas de heartbeat nas DevTools. Se a carga útil diminuir, isso alivia a carga do banco de dados e do PHP, especialmente em horários de pico.
Otimização integral: cache, banco de dados, mídia, PHP
O Heartbeat é uma peça do quebra-cabeça, mas consigo um efeito real quando combino cache, manutenção de banco de dados e otimização de mídia para Carga continuar a reduzir. O cache de páginas e objetos reduz as consultas ao banco de dados no fluxo administrativo. Reduzo consistentemente as imagens e ativo o carregamento lento. Limpo regularmente revisões, transientes e sessões. Além disso, verifico a versão do PHP e removo add-ons desnecessários; aprofundo-me mais neste guia sobre Antipadrões de plugins.
Na base de dados, presto atenção às opções carregadas automaticamente, revisões inflacionadas e transientes desatualizados. Um limite máximo para revisões evita o crescimento descontrolado, sem comprometer a segurança. O cache de objetos (por exemplo, Redis) ajuda significativamente na área administrativa, pois as consultas recorrentes encontram os seus dados mais rapidamente. Além disso, menos plugins ativados significam menos hooks que cada chamada de heartbeat pode acionar.
WP-Cron e Heartbeat em conjunto
Muitas instalações utilizam o Heartbeat indiretamente, enquanto o WP-Cron aciona tarefas em paralelo, o que, em horários de pico, pode sobrecarregar o servidor. Trabalhador adicionalmente. Por isso, verifico as tarefas cron, resumo as frequências e evito eventos desnecessários. Em caso de carga contínua, mudo para o cron do sistema real e desativo as chamadas wp-cron.php dos visitantes. Isso estabiliza os tempos de resposta e protege a interface administrativa. Quem quiser aprofundar o assunto encontrará passos práticos no meu artigo sobre Otimizar o WP-Cron.
PHP Worker, Concurrency e Filas AJAX
As solicitações AJAX competem com as visualizações de páginas, razão pela qual um número reduzido de trabalhadores PHP pode tempo de espera aumenta significativamente. Quando as chamadas Heartbeat se acumulam, o backend parece congelar, embora o servidor continue acessível. Por isso, procuro fazer menos pings, mas mais significativos, e usar caches que aliviem a carga do PHP. Quando os projetos crescem, verifico se é necessário aumentar o contingente de trabalhadores ou mudo de tarifa. Quem quiser entender essa interação pode ler o meu guia sobre Equilíbrio do PHP Worker.
Comportamento do navegador e de utilização: separadores em segundo plano e limitação do temporizador
Os navegadores modernos reduzem os temporizadores nas abas em segundo plano, mas as chamadas de heartbeat não desaparecem completamente – apenas se tornam mais raras. O fator decisivo é quantas janelas, perfis e dispositivos estão abertos em paralelo. Eu sensibilizo os editores: fechar separadores de administração desnecessários, evitar longos períodos de inatividade e, em caso de dúvida, guardar rascunhos antes de sair do local de trabalho. A limitação técnica por código complementa estas regras de comportamento de forma ideal.
Resolução de problemas: conflitos típicos e testes seguros
Se ocorrerem problemas após uma redução, verifico primeiro: o pós-bloqueio está a funcionar? Os tempos limite da sessão ainda são comunicados? O checkout em formulários em tempo real está a funcionar de forma estável? Desativo temporariamente etapas de otimização individuais, testo com diferentes funções e alterno entre o editor clássico e o editor de blocos. No DevTools, filtro a rede por „action=heartbeat“ e observo o intervalo, a duração e o tamanho. No lado do servidor, os registos PHP e de erros fornecem informações caso os hooks dos plugins Heartbeat causem lentidão não planeada.
Monitorização e plano de teste: como medir o efeito
Começo com um perfil anterior: número de solicitações admin-ajax.php por minuto, percentagem de CPU, RAM e tempo de resposta do editor, para Base Depois disso, defino novos intervalos e repito as medições com a mesma utilização. No DevTools do navegador, verifico se os pings são menos frequentes e mais rápidos. No painel de alojamento, observo se os picos de carga diminuem. Só quando os resultados estão estáveis é que transfiro as configurações para os sistemas ativos.
Valores-alvo e avaliação
Como objetivo, pretendo alcançar no Admin: intervalo de 60 s em ecrãs gerais, 30–60 s no editor, menos de 300 ms TTFB para respostas de heartbeat e um tamanho médio de resposta inferior a 10 KB – dependendo dos plugins. Sob carga (vários utilizadores, várias guias), não devem ocorrer filas longas; a utilização do trabalhador permanece suave, em vez de cair em dentes de serra. Se eu conseguir isso, a equipa editorial sentirá a diferença imediatamente.
Quando faz sentido fazer uma atualização de alojamento
Mesmo com uma configuração limpa, um projeto pode utilizar os recursos comuns de uma tarifa. explodir. Mais editores simultâneos, checkout da loja, pesquisa ou widgets de chat aumentam a carga do AJAX. Nesses casos, calculo os custos: perda de tempo na equipa vs. custo adicional por mais trabalhadores, RAM e CPU. Muitas vezes, vale a pena fazer uma atualização assim que os editores ficam bloqueados diariamente. Começo com o próximo plano e testo se a edição continua fluida.
Brevemente resumido
A API Heartbeat fornece funções valiosas em tempo real, mas sobrecarrega o alojamento partilhado se eu não definir intervalos e contextos. controlo. Com ciclos mais longos no administrador, frontend desativado e autosave ativo no editor, reduzo significativamente as solicitações. Cache, organização do banco de dados, plugins enxutos e uma versão atualizada do PHP proporcionam estabilidade adicional. Em combinação com um WP-Cron limpo e trabalhadores PHP suficientes, os cliques lentos no backend desaparecem. Assim, mantenho o conforto e a segurança e, ao mesmo tempo, reduzo a carga no meu alojamento.
