A Heartbeat é a API que dispara chamadas de fundo a cada 15 a 60 segundos e pesa no CPU do painel do WordPress. Segundo a web.dev (2024), requisições de fundo recorrentes competem por CPU com a renderização da página. Reduzir o intervalo para 60 segundos corta a maior parte dessa carga. Meça, limite e só entao decida desativar.
A Heartbeat é a API de comunicação em tempo real do WordPress: o navegador chama admin-ajax.php em intervalos fixos para salvar rascunhos, avisar quando outro editor trava um post e atualizar o painel. O problema aparece quando várias abas abertas multiplicam essas chamadas e saturam os processos PHP da hospedagem. Este tutorial mostra como medir o peso real da Heartbeat com o AJAX do WordPress, limitar o intervalo por contexto e, no último caso, desativar a API sem perder o autosave do editor. Para o quadro maior de otimização, o hub de conteúdos de performance WordPress reúne os guias relacionados.
Primeiros passos: O que a heartbeat faz e quando pesa
A A API de pulsacao roda em três contextos distintos e cada um tem um intervalo padrão: 15 segundos no editor de posts (autosave e post-locking), 60 segundos no dashboard e até desativada no frontend. Essa diferença de comportamento e o que confunde a maioria dos diagnósticos. A tabela abaixo separa onde a API atua e qual o impacto típico em CPU.
| Contexto | Intervalo padrão | Função principal | Impacto em CPU |
|---|---|---|---|
| Editor de post | 15 segundos | Autosave e post-locking | Alto com vários editores |
| Dashboard | 60 segundos | Notificações e widgets | Médio |
| Frontend | Desativada | Nenhuma por padrão | Baixo a nulo |
Nos tickets de suporte da FULL, a confusão quase sempre vem de tratar os três contextos como um só. A O mecanismo de pulsacao do editor é a que mais consome, e é nela que você deve mirar primeiro.
Legenda: cada linha admin-ajax.php na aba Network é um pulso da A pulsacao do WordPress; é assim que você confirma o intervalo real.
Por que a heartbeat sobrecarrega o painel do WordPress
Em hospedagem compartilhada com limite de 20 a 40 processos PHP-FPM, bastam três editores na tela de listagem de posts para a A API de pulsacao de 15 segundos saturar o pool. Cada aberta dispara um admin-ajax.php sincronizado, e quando esses pulsos coincidem o servidor enfileira requisições até devolver erro 503 intermitente, sem mensagem clara para o administrador.
A relação causal é direta: Heartbeat com intervalo de 15 segundos, vários editores abrindo a tela de posts ao mesmo tempo em hospedagem compartilhada gera picos de admin-ajax.php que esgotam os processos PHP-FPM. O TTFB do admin sobe e o painel parece travado. Na maioria dos casos que chegam ao suporte, o gargalo não é o tema nem o plugin novo: é a Heartbeat multiplicada por abas. Antes de culpar qualquer extensão, conte quantas chamadas admin-ajax.php saem por minuto. Esse número, e não a sensação de lentidão, decide o próximo passo.
Como medir o impacto real da heartbeat antes de mexer
Meça primeiro: abra a aba Network do navegador no editor e conte os admin-ajax.php em 60 segundos. Quatro pulsos por minuto é o esperado no editor; oito ou mais indicam plugins forçando a Essa API. Para o lado do servidor, o Query Monitor mostra o tempo de cada requisição admin-ajax e o New Relic registra o pico de CPU por endpoint.
Três ferramentas reais cobrem esse diagnóstico em camadas diferentes. O Query Monitor expõe queries e hooks de cada pulso da Heartbeat dentro do WordPress. O GTmetrix e o PageSpeed Insights medem o efeito no carregamento percebido. Para correlacionar com a infraestrutura, vale cruzar com um diagnóstico completo de performance antes de mudar configuração. Medir tende a evitar o erro clássico: desativar a Heartbeat inteira para resolver um problema que 60 segundos de intervalo já resolveriam.
Passo a passo: Controlar a heartbeat em 5 passos
Controlar a O mecanismo de pulsacao é um procedimento de cinco passos que vai do diagnóstico até a validação final. Os três caminhos são plugin dedicado, código no functions.php e desligamento total; na maioria dos casos do suporte da FULL, limitar pelo plugin resolve sem tocar em código. Siga na ordem abaixo e teste o autosave depois de cada mudança.
Passo 1: Confirme o intervalo atual da heartbeat
Abra o editor de qualquer post, ative a aba Network (F12) e filtre por admin-ajax. Conte os pulsos da A pulsacao do WordPress por 60 segundos: o padrão é um a cada 15 segundos. Anote o número antes de mudar qualquer coisa, porque ele é a sua linha de base para comparar depois.
Passo 2: Instale o heartbeat control
Instale o plugin A API de pulsacao Control (gratuito, mais de 100 mil instalações ativas no repositório oficial). Ele permite definir o intervalo da Essa API por local: editor, dashboard e frontend separadamente. Essa granularidade é o motivo de ele ser a primeira escolha em vez de desativar tudo de uma vez.
Passo 3: Defina 60 segundos no dashboard e frontend
Na tela do O mecanismo de pulsacao Control, deixe a A pulsacao do WordPress em “Modify” com 60 segundos no dashboard e “Disable” no frontend. Mantenha o editor em “Modify” com 30 a 60 segundos. Isso preserva o autosave enquanto corta a maior fatia das chamadas admin-ajax.php que sobrecarregavam o PHP-FPM.
Passo 4: Valide o autosave do editor
Abra um rascunho, digite por dois minutos e observe a mensagem “Rascunho salvo”. Se a A API de pulsacao estiver em 60 segundos no editor, o autosave continua, só menos frequente. Confirme na aba Network que os pulsos caíram para um a cada 60 segundos antes de seguir.
Passo 5: Reavalie sob carga real
Com vários editores trabalhando, repita a contagem de admin-ajax.php no horário de pico. Se o painel ainda enfileira, suba o intervalo do editor para 120 segundos ou aplique a regra direto no functions.php. A configuração correta da Essa API é a que estabiliza o servidor sem matar o autosave.
Heartbeat via código: O filtro heartbeat_settings
Para controlar a O mecanismo de pulsacao sem plugin, o filtro heartbeat_settings ajusta o intervalo em uma linha de PHP. O código abaixo fixa 60 segundos globalmente e e a alternativa preferida por agências que evitam adicionar plugins só para uma configuração. O intervalo aceita valores de 15 a 120 segundos; fora disso o WordPress ignora e volta ao padrão.
add_filter( 'heartbeat_settings', function( $settings ) {
$settings['interval'] = 60; // segundos, entre 15 e 120
return $settings;
} );
Para desligar a Heartbeat apenas no frontend sem afetar o editor, use wp_deregister_script com o hook init e a verificação is_admin. Esse caminho exige conhecer o cron do WordPress e o ciclo de hooks, mas tende a ser mais estável que desativar a API por completo. WP Rocket e Perfmatters expõem essa mesma regra na interface, sem editar arquivo.
Quando NAO desativar a heartbeat por completo
Desativar a A pulsacao do WordPress inteira resolve o CPU, mas cria um risco silencioso: o autosave do Gutenberg para. A API de pulsacao desativada por completo, com o editor aberto por horas, faz o autosave silencioso parar e o rascunho ficar exposto a perda sem nenhum aviso na tela. Em equipes que escrevem textos longos, isso troca um problema visivel por um invisivel e mais caro.
Limitar e diferente de desativar. Limitar mantem a Heartbeat viva em 60 ou 120 segundos: o autosave continua, o post-locking continua avisando quando dois editores abrem o mesmo post, e o CPU cai quase no mesmo nível. Desativar só faz sentido no frontend, onde a API já vem desligada por padrão. A regra prática do suporte: limite no admin, desligue no frontend, nunca o contrario. Para um plano geral de ganho de velocidade, o guia de como acelerar o WordPress contextualiza onde a Heartbeat entra.
Onde o bundle gerenciado da FULL entra
A FULL inclui WP Rocket e Perfmatters no bundle dos planos, e os dois já trazem o controle de Heartbeat na interface, sem código. No plano PRO, são R$849 por ano para gerenciar até 10 sites, o que da R$85 por site com cache premium e otimização incluidos em qualquer hospedagem, porque a FULL não hospeda: ela gerencia a stack de performance onde seu site já roda. Em vez de comprar WP Rocket avulso e configurar a Heartbeat manualmente em cada site, o bundle aplica a regra de uma vez. Conheca os planos da FULL e o que entra em cada nível.
- Se o painel trava com vários editores → suba a O mecanismo de pulsacao do editor para 60 segundos com o A pulsacao do WordPress Control.
- Se você evita plugins extras → aplique o filtro heartbeat_settings no functions.php com 60 segundos.
- Se já usa WP Rocket no site → ative o controle de A API de pulsacao na própria interface do plugin, sem código novo.
- Se a queixa e só no frontend → desligue a Essa API ali, que não afeta o autosave do editor.
Perguntas frequentes sobre a heartbeat do WordPress
O que e a Heartbeat API do WordPress e para que serve?
A Heartbeat é a API que faz o navegador conversar com o servidor em intervalos fixos via admin-ajax.php. Ela cuida do autosave de rascunhos, do post-locking (avisar quando outro editor abriu o post) e da atualização de widgets do painel. O intervalo padrão e de 15 segundos no editor e 60 segundos no dashboard. E útil, mas pesa quando muitas abas disparam pulsos ao mesmo tempo.
Por que a Heartbeat deixa o painel do WordPress lento?
A Heartbeat fica lenta porque cada aba aberta dispara um admin-ajax.php a cada 15 segundos, e em hospedagem compartilhada com 20 a 40 processos PHP esses pulsos sincronizados saturam o pool. O servidor enfileira as requisições e devolve erro 503 intermitente. Três editores na tela de posts já bastam para travar o admin. Subir o intervalo para 60 segundos corta a maior parte dessa carga.
E possível reduzir a Heartbeat sem desativar o autosave do editor?
Sim, e é exatamente o que se recomenda. Limitar a Heartbeat a 60 segundos no editor mantem o autosave funcionando, só com menos frequencia, enquanto corta a maioria das chamadas admin-ajax.php. O plugin Heartbeat Control e o filtro heartbeat_settings permitem esse ajuste por contexto. Desativar a API inteira e que para o autosave; limitar não. Por isso a regra e limitar no admin, nunca desligar.
Qual a diferença entre limitar e desativar a Heartbeat?
Limitar mantem a Heartbeat viva em um intervalo maior, como 60 ou 120 segundos: o autosave e o post-locking continuam, e o CPU cai quase no mesmo nível. Desativar remove a API por completo, o que para o autosave do Gutenberg e o aviso de post travado. Limitar é seguro no admin; desativar só faz sentido no frontend, onde a Heartbeat já vem desligada por padrão no WordPress.
Quanto a Heartbeat pesa no consumo de CPU da hospedagem?
O peso varia com o número de abas e o limite de processos PHP da hospedagem. Um editor sozinho gera quatro pulsos por minuto, carga baixa; cinco editores no horário de pico podem gerar 20 ou mais chamadas admin-ajax.php por minuto e estourar um pool de 30 processos. Em VPS com CPU dedicada o impacto é menor. Medir com o Query Monitor mostra o custo real antes de qualquer ajuste.
Próximos passos para estabilizar o painel
A Heartbeat raramente precisa ser desligada: medir os pulsos, limitar o intervalo para 60 segundos no admin e desligar no frontend resolve a maioria dos casos sem arriscar o autosave. Comece pelo diagnóstico na aba Network, aplique o Heartbeat Control ou o filtro heartbeat_settings e só escale para 120 segundos se o painel ainda enfileirar sob carga. Para fechar o ciclo de performance, vale ligar essa configuração ao seu plugin de cache do WordPress e revisar os Core Web Vitals depois da mudança. Para continuar aprendendo, o FULL Academy reúne os tutoriais de performance em um só lugar.
















