WordPress es un CMS muy completo y, en algunas ocasiones, podemos encontrarnos con funcionalidades que no necesitamos o que, al menos, no necesitamos al completo y que pueden llegar a ser un problema para muchos usuarios.
Hoy vamos a hablar del API Heartbeat de WordPress, una funcionalidad de WordPress que se añadió en la versión 3 y que normalmente funciona mediante el famoso archivo admin-ajax.php de WordPress. Sirve para que el código AJAX se pueda comunicar con el núcleo de WordPress, dando lugar a las funcionalidades dinámicas del front-end y back-end de WordPress como, por ejemplo, los autoguardados del editor de WordPress (revisiones).
Sin embargo, el API Heartbeat no solo es utilizada por el núcleo de WordPress. También la usan los themes y plugins.
WooCommerce, por ejemplo, hace un uso intensivo del API Heartbeat (cosa que podemos ver normalmente en las peticiones al admin-ajax.php) debido a todas sus funcionalidades dinámicas, como los filtrados.
Algunas funcionalidades comunes de WordPress que se ejecutan con el API Heartbeat son:
- Autoguardado de revisiones en cualquier editor ejecutado en el panel de WordPress.
- Filtrados de contenido realizados sin recargar la página.
- Cambio en opciones que se realizan sin pulsar ningún botón “Guardar”.
- Carritos de la compra y transiciones de datos dinámicas.
- Bloqueos por edición de contenido entre varios usuarios.
Y muchas otras funcionalidades especificas utilizadas por plugins y themes, ya que es algo común. En la siguiente URL, puedes ver documentación en el “Plugin Handbook” oficial de WordPress.org: https://developer.wordpress.org/plugins/javascript/heartbeat-api/
Como he dicho antes, normalmente la gente conoce el API Heartbeat por el archivo admin-ajax.php que podemos encontrar en WordPress. Quizá sepas ya que, al realizar un test de carga con Pingdom Tools, normalmente este archivo produce ralentizaciones.
Las peticiones realizadas al API Heartbeat se realizan a esta ruta dentro del sitio web:
1 | /wp-admin/admin-ajax.php |
Ahora que hemos visto para qué sirve el API Heartbeat de WordPress, vamos a ver cómo funciona y cómo podemos “solucionar” o “mitigar” los problemas de los sitios que hacen uso intensivo del API Heartbeat y del admin-ajax.php.
¿Cómo funciona el API Heartbeat en WordPress?
Bien, ahora que ya sabes qué hace el API Heartbeat, vamos a ver cómo funciona.
En este caso, vuelvo a comentar algo que ya dije en el artículo de wp-cron.php para WordPress, y es que no me gusta la forma que tienen de funcionar algunos sistemas de WordPress. El API Heartbeat es uno de estos casos.
Vamos a partir de la base de que, actualmente, en WordPress no podemos vivir sin el API Heartbeat. Esto se debe a que es lo que hace que nuestros sitios sean dinámicos: desde ciertas animaciones con datos dinámicos del front-end hasta los autoguardados del editor.
Para que funcione el API Heartbeat se envían pulsos (latidos) cada cierto tiempo entre el navegador del visitante y el servidor que aloja el WordPress. Estos pulsos hacen que se mantenga una continua sincronización entre WordPress y el navegador del visitante, permitiéndonos manejar datos en ambos lados sin necesidad de que se recargue la página.
La idea ya no solo es el funcionamiento de zonas dinámicas: si hay varios usuarios trabajando contra el mismo WordPress en sus navegadores, mediante el API Heartbeat el propio WordPress sabe lo que están haciendo, aunque no exista una comunicación “voluntaria” en ese preciso momento.
¿Y cuál es el problema?
Pues que estos pulsos o latidos que se realizan desde el navegador del usuario al servidor que aloja la instalación de WordPress consumen recursos de CPU, RAM y ancho de banda. Lo más marcado es el consumo de recursos de CPU o ciclos de procesador, ya que son datos que deben “ejecutarse” o “interpretarse”.
El tiempo entre peticiones (pulsos o latidos) suele ser de entre 15 y 60 segundos, dependiendo de la zona de WordPress en la que estemos trabajando.
Para entender mejor cómo va esto hay un artículo en la web de Inmotion donde puedes ver en una captura lo que ocurre con el API Heartbeat de WordPress: https://www.inmotionhosting.com/support/website/wordpress/heartbeat-ajax-php-usage#heartbeat-in-action
Lo que puedes ver en la imagen anterior es simple: al autentificarse en el dashboard de WordPress se realiza una petición al admin-ajax.php y, pasado 1 minuto, comienzan a realizarse peticiones al admin-ajax.php involuntarias, realizadas por el API Heartbeat de WordPress.
Como ya he dicho, estas peticiones realizan un consumo de CPU y RAM, ya que se abren hilos PHP para atender estas peticiones realizadas. Cuantos más WordPress tengas instalados en un mismo hosting ejecutando el API Heartbeat, mayor será el consumo de recursos producido por el API Heartbeat.
Aunque el consumo de recursos total puede variar dependiendo de la versión de PHP y el uso del API Heartbeat que producen los themes y plugins, lo que queda claro es que el API Heartbeat consume recursos. Además, los consume no solo en background, como hemos visto anteriormente, sino también en el front-end:
En el front-end, las peticiones al admin-ajax.php (además de consumir recursos de CPU, RAM y ancho de banda) ralentizan los tiempos de carga de la página y, por lo tanto, dañan el WPO del sitio web.
Controlar y optimizar el API Heartbeat
Podemos controlar o mitigar en gran parte los efectos del API Heartbeat de WordPress. Sin embargo, en muchos casos la desactivación total no es una opción debido al fallo de funcionalidades.
Existen varias cosas que podemos hacer para solucionar el problema:
- Podemos hacer que el tiempo entre pulsos sea más amplio ya que, en zonas como el editor de WordPress, el tiempo entre pulsos es de 15 segundos.
- Podemos desactivar el funcionamiento del API Heartbeat en algunas zonas como, por ejemplo, para todo el front-end o para todo el back-end.
- Podemos desactivar el API Heartbeat para toda la web, aunque esto suele causar problemas importantes en el funcionamiento normal del sitio.
Dependiendo de las circunstancias, podemos tomar alguna de las soluciones anteriores o varias.
Estos son algunos ejemplos de lo que podemos hacer dependiendo del caso:
- Si tenemos un sitio web WordPress con una tienda online WooCommerce, no podremos desactivar el API Heartbeat por completo. No obstante, podemos ampliar el tiempo entre pulsos para reducir el consumo de recursos en background lo máximo posible.
- Si tenemos un blog normal, sin mucho dinamismo, podemos desactivar el API Heartbeat para todo el front-end del sitio web. De esta forma, reducimos mucho el consumo de recursos y podremos hasta mejorar los tiempos de carga.
- Si tenemos una web estática (por ejemplo, un nicho), podemos desactivar el API Heartbeat para todo el front-end, ya que no lo vamos a notar. Esto, siempre y cuando utilicemos un theme simple como, por ejemplo, GeneratePress.
Si podemos prescindir de los autoguardados o de las funcionalidades dinámicas del dashboard o panel de administración de WordPress, también podemos desactivar el API Heartbeat en el back-end en caso de poder desactivar el API Heartbeat en el front-end.
De todas formas, esto se basa en el modelo prueba-error, ya que no existe un esquema exacto de cuándo se necesita el API Heartbeat o no. Todo depende del tipo de sitio web y de la combinación de theme y plugins utilizada.
Vale. Pues ahora que ya sabes más o menos cuándo desactivar el API Heartbeat o, al menos, tienes una orientación sobre el tema, vamos a explicar cómo desactivar o aumentar el tiempo entre pulsos del API Heartbeat.
Tenemos dos formas de hacer esto. Una es de forma manual, añadiendo código al functions.php del theme activo en WordPress. La otra es con plugins.
Para editar el functions.php del theme activo, debes tener unos conocimientos mínimos para encontrar al menos el archivo functions.php y saber cómo recuperar el sitio web en caso de que tengas algún problema importante al editarlo. En el siguiente vídeo que he grabado para ti, puedes ver cómo editar el archivo functions.php del theme activo:
Desactivar el API Heartbeat de forma manual
Podemos desactivar el API Heartbeat con código en el functions.php del theme activo. En el vídeo de arriba puedes ver cómo hacerlo exactamente.
Este es el código que debemos poner para apagar por completo el API Heartbeat en todo el sitio web, tanto en el front-end como en el back-end:
1 2 3 4 | add_action( 'init', 'stop_heartbeat', 1 ); function stop_heartbeat() { wp_deregister_script('heartbeat'); } |
Y este es el código que tienes que poner para desactivar el API Heartbeat en el dashboard de WordPress, es decir, en el index.php del dashboard:
1 2 3 4 5 6 | add_action( 'init', 'stop_heartbeat', 1 ); function stop_heartbeat() { global $pagenow; if ( $pagenow == 'index.php' ) wp_deregister_script('heartbeat'); } |
Esto es útil para desactivar el API Heartbeat para usuarios que entran al dashboard de WordPress y se quedan ahí autentificados, pero sin hacer nada.
Con este otro código, desactivaras el API Heartbeat para TODO el dashboard de WordPress. Sin embargo, quedará activo en los editores de post y páginas, con el fin de que los autoguardados y las revisiones sigan funcionando como siempre:
1 2 3 4 5 6 | add_action( 'init', 'stop_heartbeat', 1 ); function stop_heartbeat() { global $pagenow; if ( $pagenow != 'post.php' && $pagenow != 'post-new.php' ) wp_deregister_script('heartbeat'); } |
Como ves, personalizando el código puedes hacer lo que quieras con el API Heartbeat y desactivarlo donde quieras.
Limitar el API Heartbeat de forma manual
Si quieres limitar el funcionamiento del API Heartbeat con el functions.php del theme activo, también puedes hacerlo de la misma forma que lo puedes desactivar.
Con este código puedes cambiar el tiempo entre periodos de pulsos o latidos, desde 15 a 60 segundos, ya que esos son los tiempos que nos permite el API:
1 2 3 4 5 | function limit_heart( $settings ) { $settings['interval'] = 60; //Entre 15 y 60 segundos return $settings; } add_filter( 'heartbeat_settings', 'limit_heart' ); |
Con esto podemos mitigar el problema que existe cuando abrimos el editor de WordPress. Los pulsos, en lugar de realizarse cada 15 segundos en esa zona, se realizarán cada 60 segundos. Como consecuencia, se consumirá un 70% menos de recursos por el API Heartbeat cuando el editor de WordPress esté abierto.
Gestionar el API Heartbeat con Heartbeat Control
De todos los plugins que existen para controlar el API Heartbeat en WordPress, personalmente el que más me gusta es Heartbeat Control.
Heartbeat Control es un plugin gratuito que podemos encontrar en el repositorio oficial de plugins de WordPress. Nos permite desactivar y limitar Heartbeat desde una interfaz gráfica integrada en el panel de control de WordPress.
El plugin Heartbeat Control ha mejorado mucho y, desde hace algún tiempo, funciona con un sistema de reglas. El orden de las reglas importa bastante para el funcionamiento y las condiciones que establecemos.
En el siguiente vídeo que he grabado para ti, puedes ver el funcionamiento y configuración del plugin Heartbeat Control para WordPress:
Si quieres más información o descargar el plugin Hearbeat Control para WordPress, puedes hacerlo desde aquí: https://wordpress.org/plugins/heartbeat-control/
Gestionar el API Heartbeat con WP Rocket
Desde ya hace algunas versiones, el plugin de cache WP Rocket tiene la opción de gestionar el API Heartbeat desde su interfaz gráfica.
Puedes ver un vídeo completo sobre cómo funciona WP Rocket, incluidas sus opciones de control del API Heartbeat, desde aquí:
Si no utilizas WP Rocket, no es necesario que lo compres y lo instales por esta funcionalidad. Con el plugin Heartbeat Control tendrás todo lo que necesitas.
Si estás interesado en comprar WP Rocket, puedes hacerlo desde aquí: https://alvarofontela.com/wprocket
8 comentarios
Interesante, no había oído nunca hablar del API Heartbeat.
Gracias por la información!
Me alegro de que te sirva Jacobo 🙂
hola alavaro no tendrias algun articulo o algun video de como hacer carga asicronica de admin ajax con lite speed ???
Hola Marcos, tengo este video, es algo antiguo, no recuerdo si en esa fecha LiteSpeed Cache tenía esa funcionalidad: https://www.youtube.com/watch?v=5yeZ5fK1DPM
Hola Alvaro. Utilizo WooCommerce en mi sitio, por lo que explicas no debería desactivar el latido de WP, pero hay modo de que solo funcione para las llamadas de woocommerce y la actualización de la edición de entradas y paginas?
Hola Tito, si usas WooCoommerce yo no te recomiendo desactivar el API Heartbeat, ya que se usa para varias partes.
Desgraciadamente, se puede elegir para front-end y back-end, pero no para páginas o acciones específicas. (Salvo el wc_fragments, pero lo necesitas para WooCommerce).
Hola Álvaro!
Muchas gracias por tus posts, siempre son muy útiles y muy bien explicados para personas como yo que tenemos un blog autogestionado (de unas 200 URL y unas 10/15 mil visitas mensuales) y aunque tengo conocimientos de “desarollo” básicos como para gestionarlo… surgen problemas como estos y no entiendo ni el idioma. He recibido un correo de mi hosting de que mi plan ha superado el 80% de la cuota de segundos del CPU, no entendía nada ya que tengo un buen plan contratado y me remitían al heartbeat y he tenido que recurrir a tu blog… El caso es que mi web lleva un año en funcionamiento y nunca me había pasado esto, ni he hecho ninguna actualización o cambio que me hiciese entender porque la semana pasada esto iba bien y hoy no. Ha habido como un despunte (de unas dos horas) de repente en la gráfica de ejecución de programas que ha vuelto a bajar. Tengo WP Rocket instalado y tengo activado (ya de antes) “Reducir actividad”. “Controlar actividad” no lo tenía clicado. No sé si eso podrá ayudar… es suficiente con lo de WP Rocket o crees que mejor reduzco la actividad en segundos en functions? Sé introducirlo, pero al salir ya por defecto en WP Rocket no quiero liarla teniendo “2 configuraciones”. Disculpa mi lenguaje… como ves no soy una experta! Mil gracias como siempre!
Hola Victoria, lo que haces realmente al marcar “Reducir actividad”. “Controlar actividad” es limitarlo como si lo hicieses en el functions.php.
Si quisieras hacer algo más, ya habría que detectar que plugin o función esta usando tanto el API Heartbeat, ya sea mediante el admin-ajax.php o mediante otra implementación.