Ir al contenido 
La API Heartbeat de WordPress causa silencios en el alojamiento compartido debido a los frecuentes pings AJAX a través de admin-ajax.php. Carga del servidor y provoca un retraso notable en el backend. Te mostraré cómo controlar de forma segura la frecuencia de los latidos, reducir la carga del servidor de WordPress y conservar funciones importantes como el autoguardado.
Puntos centrales
- Frecuencia cardíaca Prolongar de forma específica en lugar de desactivar por completo.
- Autoguardado Guardar en el editor, detener los pings innecesarios.
- Recursos compartidos Proteger: CPU, RAM, E/S a la vista.
- Monitoreo antes/después de la optimización para obtener efectos claros.
- Integral Optimización: almacenamiento en caché, base de datos, CDN, versión PHP.
Entender Heartbeat: una función útil con costes
La API Heartbeat envía solicitudes AJAX periódicas, normalmente cada 15 segundos en el panel de control, para mantener las sesiones y guardar los borradores; estas Frecuencia Sin embargo, esto tiene su precio. Cada ping llega a admin-ajax.php y activa procesos PHP, accesos a la base de datos y, en su caso, ganchos de plugins. Si el navegador permanece minimizado, la comunicación suele continuar y genera picos de carga. Las pestañas abiertas multiplican las solicitudes y reducen el tiempo de respuesta del editor. En sistemas muy compartidos, esto provoca procesos ralentizados, autoguardados tardíos y un trabajo subjetivamente „pesado“.
Por qué el alojamiento compartido se ve especialmente afectado
En el alojamiento compartido, comparto la CPU, la RAM y la E/S con sitios vecinos, por lo que las solicitudes adicionales pueden ralentizar Capacidad agotar más rápidamente. Si se conectan varios usuarios a la vez o el panel de control permanece abierto durante horas, los pings se acumulan y bloquean los trabajadores PHP. Entonces aumentan el TTFB y los tiempos de espera en el administrador, y la carga del servidor WordPress alcanza picos breves. Cuando se producen cargas simultáneas de sitios vecinos, se produce una reacción en cadena: los aciertos de caché disminuyen, los bloqueos de la base de datos aumentan y el editor se vuelve lento. Así, sin quererlo, convierto una función cómoda en una fuente de carga.
Reconocer los síntomas a tiempo
Si noto clics lentos en el backend, un número llamativo de solicitudes POST en DevTools y entradas entrecortadas en el editor, todo apunta a que los pings de latido son la causa. Conductores Las advertencias del host debido a picos de CPU o límites de memoria también encajan en el panorama. Unos Core Web Vitals más débiles en el contexto administrativo y una disminución de las puntuaciones de PageSpeed también pueden ser señales indirectas. En los registros veo acumulaciones de accesos a admin-ajax.php con acción „heartbeat“. Si estos efectos se producen durante el procesamiento inactivo, las pestañas en segundo plano desperdician recursos valiosos.
¿Cuántas solicitudes se generan realmente? Un breve cálculo
Un intervalo estándar de 15 segundos genera cuatro pings por minuto por cada pestaña. Tres pestañas de administración abiertas significan 12 solicitudes de latido por minuto, por cada editor. Si dos personas trabajan en paralelo, son ya 24 por minuto, es decir, 1440 por hora. Si establezco el intervalo en la administración en 60 segundos, reduzco la misma carga a tres pings por minuto y por persona. En el ejemplo anterior, el número se reduce de 24 a 6 por minuto: una reducción del 75 %. Este sencillo cálculo explica por qué el tiempo de respuesta percibido mejora significativamente después de una reducción.
Tomar el control: complementos o código
En primer lugar, apuesto por una regla clara: aumentar la frecuencia en lugar de actuar a ciegas. apagar. Con herramientas como Heartbeat Control, WP Rocket o LiteSpeed Cache, configuro 30-60 segundos en el administrador, 120-180 segundos en el frontend y desactivo los pings en páginas sin interacción. Si prefieres el código, puedes ralentizar la API de forma selectiva. Ejemplo: establece intervalos de 60 segundos y deja solo el autoguardado en el editor. De esta manera, reduzco la carga sin perder seguridad para el contenido.
// Ajustar intervalos add_filter('heartbeat_settings', function($settings) { $settings['interval'] = 60; // Segundos return $settings; });
// Desactivar Heartbeat, por ejemplo, en el frontend add_action('init', function() { if ( ! is_admin() ) wp_deregister_script('heartbeat'); }, 1);
Editor de bloques frente a clásico: lo que realmente hace Heartbeat en el editor
En el editor clásico, el autoguardado se basa directamente en Heartbeat. En el editor de bloques (Gutenberg), el autoguardado se ejecuta principalmente a través de la API REST, pero Heartbeat sigue realizando tareas importantes como el bloqueo de publicaciones y las comprobaciones de sesión. Conclusión práctica: una prolongación moderada (30-60 s) no interrumpe el autosave en el editor de bloques, pero puede retrasar la actualización de los bloqueos y los mensajes de estado. Por eso, en el editor elijo intervalos más cortos que en el resto del administrador y compruebo con borradores reales si los bloqueos y las advertencias funcionan según lo esperado.
Restricción selectiva según pantalla y función
Para obtener el máximo control, regulo Heartbeat en función de la pantalla y, si es necesario, de los roles de los usuarios. De este modo, el editor sigue siendo rápido, mientras que las áreas administrativas tranquilas prácticamente no generan pings.
// 1) Intervalos diferentes según la pantalla 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: más frecuente para autosave/bloqueo
} else { $settings['interval'] = 60; // resto de Admin } } return $settings; }); // 2) Cargar Heartbeat en Admin solo donde sea necesario add_action('admin_enqueue_scripts', function($hook) {
$allowed = ['post.php', 'post-new.php', 'site-editor.php']; // Contextos del editor if ( ! in_array($hook, $allowed, true) ) { wp_deregister_script('heartbeat'); } }, 1);
// 3) Tratar el frontend de forma diferenciada (por ejemplo, para usuarios registrados) add_action('wp_enqueue_scripts', function() { if ( ! is_user_logged_in() ) { wp_deregister_script('heartbeat'); // Visitantes: no es necesario Heartbeat } }, 1);
// Opcional: armonizar el intervalo de autoguardado add_filter('autosave_interval', function() { return 60; });Con esta configuración, las funciones en vivo permanecen activas donde son útiles y desaparecen en áreas sin interacción. En el contexto de la tienda o del proceso de pago, mantengo Heartbeat activo y breve de forma específica, mientras que en el resto del frontend permanece inactivo.
Intervalos razonables y excepciones
Mantengo el editor operativo mientras elimino los pings innecesarios en las páginas tranquilas, porque Autoguardado sigue siendo esencial. 60 segundos en el administrador suelen ser el punto óptimo entre seguridad y carga. En el frontend, normalmente no necesito Heartbeat, salvo en el caso de los componentes en vivo. En tiendas o interfaces de usuario dinámicas, solo planifico ciclos más cortos donde se realizan entradas. De este modo, la página sigue siendo rápida y estable, sin poner en peligro los contenidos.
| Contexto | Intervalo recomendado | Nota |
|---|---|---|
| Panel de control general | 60 s | Carga disminuye notablemente, las sesiones permanecen activas. |
| Post-editor | 30-60 s | El autoguardado y el bloqueo siguen estando disponibles. |
| Frontend estático | Desactivar | Sin interacción, por lo que no se necesitan pings. |
| Interfaz interactiva (por ejemplo, caja) | 15-30 s | Solo en los casos afectados Páginas activar. |
| Pestañas de administración abiertas durante mucho tiempo | 90-120 s | Ahorra recursos cuando la pestaña permanece en segundo plano. |
Optimizar la carga útil de Heartbeat: menos datos por ping
Además de la frecuencia, también cuenta la cantidad de datos transmitidos. Algunos complementos añaden información adicional a Heartbeat. Mediante filtros, puedo reducir aún más la carga del servidor eliminando la carga útil innecesaria o simplificando las respuestas.
// 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);A continuación, compruebo el tamaño de las respuestas de latido en DevTools. Si la carga útil se reduce, se alivia la carga de la base de datos y PHP, especialmente en horas punta.
Optimización integral: almacenamiento en caché, base de datos, medios, PHP
Heartbeat es una pieza del rompecabezas, pero consigo un efecto real cuando combino el almacenamiento en caché, el mantenimiento de bases de datos y la optimización de medios para Carga seguir reduciendo. El almacenamiento en caché de páginas y objetos reduce las consultas a la base de datos en el flujo de administración. Reduzco el tamaño de las imágenes de forma sistemática y activo la carga diferida. Limpio regularmente las revisiones, los transitorios y las sesiones. Además, compruebo la versión de PHP y elimino los complementos innecesarios; profundizo más en esta guía sobre Antipatrones de plugins.
En la base de datos, presto atención a las opciones autocargadas, las revisiones infladas y los transitorios obsoletos. Un límite máximo para las revisiones evita el crecimiento descontrolado sin renunciar a la seguridad. El almacenamiento en caché de objetos (por ejemplo, Redis) ayuda notablemente en el área de administración, ya que las consultas recurrentes encuentran sus datos más rápidamente. Además, menos plugins activados significan menos hooks que pueden activar cada llamada de heartbeat.
Combinar WP-Cron y Heartbeat
Muchas instalaciones utilizan Heartbeat de forma indirecta, mientras que WP-Cron activa tareas en paralelo, lo que en horas punta puede provocar Trabajador además, ocupa recursos. Por lo tanto, compruebo las tareas programadas, resumo las frecuencias y evito eventos innecesarios. En caso de carga continua, cambio al cron del sistema real y desactivo las llamadas wp-cron.php de los visitantes. Esto estabiliza los tiempos de respuesta y protege la interfaz de administración. Si desea profundizar más, encontrará pasos prácticos en mi artículo sobre Optimizar WP-Cron.
Trabajadores PHP, concurrencia y colas AJAX
Las solicitudes AJAX compiten con las visitas a la página, por lo que un número reducido de trabajadores PHP puede ralentizar el tiempo de espera notablemente. Si se acumulan las llamadas de latido, el backend se bloquea, aunque el servidor sigue estando disponible. Por lo tanto, mi objetivo es realizar menos pings, pero más significativos, y utilizar cachés que alivien la carga de PHP. A medida que los proyectos crecen, compruebo si hay más contingentes de trabajadores disponibles o cambio de tarifa. Si quieres entender cómo funciona todo esto, lee mi guía sobre Equilibrio de trabajadores PHP.
Comportamiento del navegador y del usuario: pestañas en segundo plano y limitación del temporizador
Los navegadores modernos ralentizan los temporizadores en las pestañas en segundo plano, pero las llamadas de latido no desaparecen por completo, solo se vuelven menos frecuentes. Lo decisivo es cuántas ventanas, perfiles y dispositivos están abiertos al mismo tiempo. Sensibilizo a los editores: cerrar las pestañas de administración que no se necesiten, evitar largos periodos de inactividad y, en caso de duda, guardar los borradores antes de abandonar el puesto de trabajo. La limitación técnica mediante código complementa estas normas de comportamiento de forma óptima.
Localización de errores: conflictos típicos y pruebas seguras
Si surgen problemas tras una reducción, lo primero que compruebo es: ¿funciona el post-locking? ¿Se siguen notificando los tiempos de espera de sesión? ¿Funciona correctamente el proceso de pago en los formularios en tiempo real? Desactivo temporalmente algunos pasos de optimización, realizo pruebas con diferentes roles y cambio entre el editor clásico y el editor de bloques. En DevTools, filtro la red por „action=heartbeat“ y observo el intervalo, la duración y el tamaño. En el lado del servidor, los registros PHP y de errores proporcionan información si los ganchos de los plugins ralentizan Heartbeat de forma imprevista.
Plan de supervisión y pruebas: así mido el efecto
Empiezo con un perfil previo: número de solicitudes admin-ajax.php por minuto, porcentaje de CPU, RAM y tiempo de respuesta del editor para Base . A continuación, establezco nuevos intervalos y repito las mediciones con el mismo uso. En Browser-DevTools compruebo si los pings son menos frecuentes y se completan más rápidamente. En el panel de alojamiento observo si los picos de carga se suavizan. Solo cuando los resultados son estables, transfiero la configuración a los sistemas en vivo.
Valores objetivo y evaluación
Mi objetivo en el administrador es: intervalo de 60 s en pantallas generales, 30-60 s en el editor, menos de 300 ms TTFB para respuestas de latido y un tamaño de respuesta medio inferior a 10 KB, dependiendo de los plugins. Bajo carga (varios usuarios, varias pestañas), no deberían producirse colas largas; la carga de trabajo se mantiene estable, en lugar de caer en picos. Si lo consigo, el equipo editorial notará la diferencia de inmediato.
Cuándo es conveniente actualizar el alojamiento web
Incluso con una configuración limpia, un proyecto puede utilizar los recursos comunes de una tarifa. volar. Un mayor número de editores simultáneos, el proceso de pago de la tienda, la búsqueda o los widgets de chat aumentan la carga de AJAX. En estos casos, calculo los costes: pérdida de tiempo en el equipo frente al sobrecoste por más trabajadores, RAM y CPU. A menudo, merece la pena realizar una actualización tan pronto como los editores se bloquean a diario. Empiezo con el siguiente plan y compruebo si la edición sigue siendo fluida.
Brevemente resumido
La API Heartbeat proporciona valiosas funciones en tiempo real, pero sobrecarga el alojamiento compartido si no configuro los intervalos y contextos. control. Con ciclos más largos en el administrador, el frontend desactivado y el autoguardado activo en el editor, reduzco significativamente las solicitudes. El almacenamiento en caché, el orden de la base de datos, los plugins ligeros y una versión actualizada de PHP proporcionan una estabilidad adicional. En combinación con un WP-Cron limpio y suficientes trabajadores PHP, desaparecen los lentos clics en el backend. De esta manera, mantengo la comodidad y la seguridad y, al mismo tiempo, reduzco la carga en mi alojamiento.
