PUNTOS CLAVE
- La Heartbeat API mantiene la comunicación en tiempo real mediante admin-ajax.php.
- Peticiones constantes cada 15-60 segundos pueden saturar el uso de CPU.
- Es vital limitar su frecuencia en el escritorio y deshabilitarla en el front-end.
- La optimización se realiza mediante el filtro nativo heartbeat_settings.
Cuando un servidor comienza a mostrar picos de uso de CPU injustificados en sitios de WordPress, el sospechoso habitual suele ser la API Heartbeat de WordPress. Esta funcionalidad, aunque esencial para el guardado automático y el bloqueo de edición de entradas, genera un goteo constante de peticiones POST hacia admin-ajax.php que, en entornos de hosting compartido o con múltiples editores activos, termina degradando el rendimiento general de la infraestructura.
#El Funcionamiento del «Latido» de WordPress
Introducida en la versión 3.6, la Heartbeat API actúa como un puente de comunicación bidireccional entre el navegador y el servidor. Utiliza eventos de JavaScript para enviar paquetes de datos cada intervalo de tiempo definido. Su propósito es noble: avisarte si otro autor está editando el mismo post o sincronizar actualizaciones de e-commerce en tiempo real. Sin embargo, el coste operativo es una ejecución completa de PHP en cada latido.
#Reduciendo la Carga con Filtros Nativos
La estrategia más eficiente no es deshabilitarla por completo, lo cual rompería funciones críticas, sino modular su frecuencia y restringir su área de actuación. Por defecto, cuando estás editando una entrada, el latido ocurre cada 15 segundos; en el resto del panel administrativo, cada 60 segundos.
En un proyecto reciente para un medio digital con 12 redactores concurrentes, el servidor Apache colapsaba cada mañana. Al analizar los logs de acceso, detectamos miles de llamadas a admin-ajax provenientes de pestañas del panel de control que los redactores dejaban abiertas sin usar. Implementé una lógica para ralentizar el latido a 60 segundos incluso en el editor y desactivarlo totalmente en el front-end público, donde rara vez aporta valor real.
add_filter( 'heartbeat_settings', function( $settings ) {
// Forzamos el intervalo máximo permitido: 60 segundos
$settings['interval'] = 60;
return $settings;
});
// Desactivar Heartbeat en el Front-end
add_action( 'init', function() {
if ( ! is_admin() ) {
wp_deregister_script( 'heartbeat' );
}
}, 1 );
#Cuándo usar / Cuándo NO usar
- Cuándo usar: Sitios en hosting compartido con recursos limitados, blogs con múltiples autores trabajando simultáneamente o si tu herramienta de analítica muestra un uso excesivo de admin-ajax.php.
- Cuándo NO usar: Webs que dependan de subastas en vivo, chats integrados que usen esta API o si eres el único administrador y tu servidor tiene potencia de sobra.
#Pros y Contras
Optimizar el latido es una decisión de equilibrio entre la estabilidad del servidor y la inmediatez de las funciones internas de WordPress.
- Pros: Reducción drástica del uso de CPU, eliminación de procesos PHP innecesarios y mayor escalabilidad del sitio ante tráfico administrativo.
- Contras: Mayor tiempo de espera para el autoguardado y notificaciones de edición bloqueada más lentas (un autor podría entrar a editar un post que otro ya ha empezado hace 40 segundos).
«Optimizar la API Heartbeat es la forma más rápida de silenciar un servidor que grita por falta de recursos en el backend.»
| Parámetro | Valor Original | Valor Optimizado |
|---|---|---|
| Intervalo Editor | 15 segundos | 60 segundos |
| Intervalo Dashboard | 60 segundos | 60 – 120 segundos |
| Carga Front-end | Activa | Deshabilitada |
| Impacto CPU | Alto (en escalado) | Bajo / Controlado |
Para profundizar en la implementación técnica de los parámetros de configuración, puedes visitar la documentación oficial de la Heartbeat API o consultar soluciones de diagnóstico en proyectos de control de latido comunitarios.