Para disminuir el impacto de admin-ajax.php es necesario gestionar la API Heartbeat de WordPress: ampliar el intervalo entre pulsos, restringirla a determinadas áreas o desactivarla. Este archivo se encarga de las peticiones AJAX y provoca una carga continua, especialmente con WooCommerce. La alternativa más conveniente varía según cuántas funciones dinámicas emplee tu sitio web.
Como seguramente ya sabes, en SevenSerp estamos especializados en WordPress, y uno de los aspectos más relevantes en este CMS es contar con una buena velocidad de carga y con un consumo de recursos lo más bajo posible.
Para lograrlo, lo más recomendable es llevar a cabo una optimización integral de nuestro sitio web, aunque para ello resulta necesario saber cómo funciona WordPress y cada una de sus partes, y tener muy claro qué funciones emplea y requiere nuestra instalación, y si podemos prescindir de alguna de ellas.
Habitualmente, para optimizar WordPress suelen aplicarse ciertas configuraciones estándar, por ejemplo, la instalación de un plugin de caché, la desactivación del WP Cron, la configuración de un CDN como Cloudflare, etc.; sin embargo, hay que considerar que cada web es un caso distinto y, según la configuración y las funcionalidades de que disponga, puede plantearse la realización de otro tipo de procesos.
En este artículo, hablaremos de un archivo de WordPress que suele generar un consumo muy elevado de recursos en determinadas instalaciones, el «admin-ajax.php», explicaremos qué es exactamente este archivo, cuál es su función y qué opciones tenemos para optimizarlo de modo que no nos provoque consumos excesivos en nuestro hosting ni ralentice nuestro sitio web.
¿Qué es el archivo admin-ajax.php y para qué se utiliza?
A partir de la versión 3.6 de WordPress, se incorporó una nueva funcionalidad denominada API Heartbeat que normalmente se ejecuta desde el fichero «admin.ajax.php». Este archivo es uno de los más importantes en WordPress, ya que posibilita la comunicación asíncrona entre el servidor y el cliente mediante AJAX (Asynchronous JavaScript and XML), es decir, gestiona solicitudes Ajax desde el lado del usuario sin necesidad de recargar la página, lo que permite a WordPress incorporar funcionalidades dinámicas en el front-end y en el propio back-end.
Como puedes imaginar, las peticiones que se hacen a este archivo generan carga en nuestro sitio web y en el propio servidor y, en ciertos casos, pueden llegar a ralentizar la velocidad de carga en gran medida, ya que estas peticiones suelen ser las más largas y las que más tardan en procesarse por completo.
Hay que tener en cuenta que el núcleo de WordPress no es el único que emplea esta funcionalidad, existen multitud de plugins y temas que también la utilizan (unos más que otros); es el caso de WooCommerce, que como todos sabréis, es uno de los plugins que más problemas ocasiona a nivel de consumos, precisamente por el uso que hace del API Heartbeat, además de otros motivos adicionales.
A continuación te indicaremos una serie de funcionalidades muy habituales de WordPress que se ejecutan con el API Heartbeat para que las tengas en cuenta y comprendas mejor su funcionamiento.
- La funcionalidad de autoguardado de post, la cual permite que los cambios en las publicaciones o páginas se vayan guardando de forma automática mientras se van realizando cambios, lo que evita la pérdida de contenido en caso de que se produzca algún problema.
- El control de las sesiones, lo que ayuda a mantener las sesiones de los usuarios activas mientras se navega por el administrador de WordPress.
- Los carritos de compra y todo tipo de funcionalidad dinámica en el sitio web (por eso es tan importante para un plugin como WooCommerce y por eso suele generar tantos problemas de consumos).
- Los cambios que se realizan en opciones que no requieran de un guardado manual y se guardan automáticamente.
- El bloqueo por edición de contenido entre varios usuarios.
- Los filtros automáticos que no requieren actualizar la web manualmente, sino que van filtrando en función de las opciones que indiques.
Estos son solo algunos ejemplos de todo lo que abarca esta funcionalidad en WordPress; no obstante, con esto ya puedes hacerte una idea de todos los procesos que realiza y de su importancia en determinados sitios webs.
Cómo funciona el API Heartbeat de WordPress
Ahora que ya sabemos qué utilidad tiene esta funcionalidad en WordPress, nos faltaría explicar cómo funciona exactamente.
La API Heartbeat funciona mediante pulsos, es decir, cada cierto periodo de tiempo, se enviará una petición (un pulso) desde el navegador del visitante al archivo admin-ajax.php del sitio web que se está visitando. Estos pulsos permiten que se mantenga todo sincronizado entre el WordPress y dicho navegador, lo que permite que ciertas funcionalidades de WordPress (dinámicas, sobre todo) funcionen correctamente sin necesidad de recargar la página.
Por ejemplo, si tenemos abierta una pestaña en el navegador en el administrador de WordPress, en la sección de plugins, podemos ver que se genera una petición cada ciertos segundos (puedes ver en la siguiente captura la cantidad de peticiones que se generan en 2 minutos, sin realizar ninguna acción, únicamente con tener la pestaña abierta).
Como indicamos con anterioridad, cada petición que se realiza al archivo admin-ajax.php, genera cierta carga en la web, en el ejemplo anterior puedes comprobar las peticiones que se realizan en el administrador sin ni siquiera realizar una acción, no obstante, hay que tener en cuenta que el uso del admin-ajax.php no se realiza únicamente en el administrador o el editor de WordPress, sino también en la propia parte pública, sobre todo si tiene muchas funcionalidades dinámicas que lo utilicen.
Por ejemplo, en una web con WooCommerce que tiene bastantes visitas, van a estarse realizando peticiones de forma continua a este fichero, lo que puede provocar que el consumo de recursos sea insostenible, en la siguiente captura puedes comprobar cómo ese archivo (junto al wp-cron.php, el cual genera una petición por cada visita) genera básicamente el 30-40% de las peticiones que se hacen a la web, y teniendo en cuenta que cada una de esas peticiones es de 97/98 bytes, y que en ciertas ocasiones, pueden llegar a realizarse incluso decenas de peticiones simultáneas, podemos llegar a tener unos consumos demasiado elevados a nivel CPU/RAM.
Para intentar controlar este tipo de situaciones, lo idóneo es intentar optimizar el uso de este archivo lo máximo posible. Existen varias alternativas para esto, aunque antes de nada tendremos que conocer qué opciones tenemos dependiendo de las funcionalidades de nuestro sitio web.
Controlar y optimizar el API Heartbeat de WordPress
Existen algunas alternativas que podemos utilizar para reducir los consumos del API Heartbeat de WordPress. Dependiendo del tipo de web que tengamos, podemos valorar distintas opciones:
- Incrementar el intervalo entre pulsos, por ejemplo, en el propio editor de WordPress el lapso entre pulsos es de 15 segundos, podríamos duplicarlo o ampliarlo según consideremos, siempre que no provoque ningún inconveniente en el funcionamiento.
- Podemos deshabilitar por completo el API Heartbeat, si bien esto puede ocasionar que muchas funcionalidades de WordPress dejen de operar
- En lugar de deshabilitarlo por completo, podemos plantear la desactivación del API Heartbeat de WordPress solo en determinadas zonas de WordPress, por ejemplo en el frontend, aunque esto solo resulta aconsejable en sitios web que no cuenten con contenidos dinámicos, algo poco habitual hoy en día.
Hoy en día, el API Heartbeat de WordPress resulta necesario en la gran mayoría de sitios web, y solo en situaciones puntuales y concretas podemos plantear su desactivación en ciertas zonas; sin embargo, ampliar el intervalo entre pulsos sí es factible, a continuación te mostraremos algunos casos prácticos para que veas qué alternativas tendrías en cada uno de ellos.
- Si nuestro sitio web emplea un plugin que haga un uso intensivo de esta funcionalidad, como , no es posible desactivar en ningún caso la API Heartbeat, aunque sí podemos ampliar el intervalo entre pulsos para disminuir los consumos todo lo posible.
- Si nuestro sitio web es una web estática e informativa (sin contenidos dinámicos), podríamos desactivar el API Heartbeat para todo el frontend, ya que en realidad no se estaría utilizando (esto también puede depender del tema que emplees).
- En caso de que nuestro sitio web cumpla el punto anterior y, además, no vayamos a realizar nunca cambios en él y no necesitemos las funcionalidades dinámicas del administrador de WordPress (autoguardados, control de sesiones, etc.), podríamos desactivar la API Heartbeat de WordPress por completo, lo que podría contribuir a reducir notablemente los consumos a nivel de CPU/RAM.
Dicho todo esto, a continuación te indicaremos algunos plugins con los que puedes gestionar esta funcionalidad en WordPress para que los tengas en cuenta.
Administrar el API Heartbeat con LiteSpeed Caché
LiteSpeed Caché es el plugin de caché que solemos aconsejar siempre para sitios web alojados en cualquiera de nuestros hostings compartidos, por motivos de rendimiento y compatibilidad.
Este plugin cuenta con multitud de opciones, y una de ellas es precisamente la configuración de los pulsos de la API Heartbeat de WordPress.
La configuración es sencilla. Si queremos controlar los pulsos y reducir o ampliar su periodicidad, tan solo tendremos que activar la zona que deseemos controlar (ponerla en ON) y fijar la cantidad de segundos en los que queremos que se ejecute el pulso.
Administrar el API Heartbeat con WP Rocket
Wp Rocket también nos permite controlar en cierta medida los pulsos de Heartbeat, por lo que si empleamos este plugin, podemos usar esta funcionalidad del mismo: https://wp-rocket.me/
Como puedes comprobar, la configuración es aún más sencilla que en LiteSpeed Caché, solo nos permite elegir entre 3 opciones: reducir actividad (lo cual amplía ligeramente el tiempo entre pulsos), desactivar por completo o mantener la configuración por defecto.
No te aconsejamos adquirir el plugin únicamente por esta opción, hay alternativas mejores y más avanzadas, o incluso un plugin que se emplea exclusivamente para esta configuración, y que consideramos que es de los que mejor funcionan, del cual hablaremos a continuación.
Administrar el API Heartbeat con Heartbeat Control
Este plugin es gratuito, es de los mismos desarrolladores que Wp Rocket, puedes descargarlo directamente desde el repositorio de WordPress: https://es.wordpress.org/plugins/heartbeat-control/
La configuración en este caso es la misma que en LiteSpeed Caché. Puedes desactivar la API Heartbeat de WordPress por completo o ampliar el tiempo entre pulsos de cada zona de WordPress (backend, frontend y editor).
Preguntas Frecuentes
¿Por qué admin-ajax.php consume tantos recursos en mi servidor?
Porque cada llamada arranca el núcleo completo de WordPress, incluyendo plugins y temas, aunque la tarea sea mínima. Ese coste se multiplica si hay peticiones frecuentes desde el frontend o desde el escritorio. El resultado son procesos PHP largos y consultas a base de datos que elevan la carga del servidor, sobre todo en hosting compartido con recursos limitados.
¿Cómo puedo saber qué peticiones a admin-ajax.php está recibiendo mi WordPress?
Revisa el log de acceso del servidor filtrando por admin-ajax.php y mira el parámetro action de cada URL. Esa acción identifica el plugin o función que origina la llamada. Herramientas como Query Monitor también muestran las peticiones AJAX en el escritorio. Con esos datos puedes decidir qué acciones conviene limitar, cachear o sustituir por una llamada más ligera.
¿Se puede bloquear admin-ajax.php para los visitantes no registrados?
Sí, si tu tema o plugins no lo usan para el frontend público. Muchas instalaciones solo lo necesitan en el escritorio, así que restringir el acceso a usuarios con sesión iniciada reduce peticiones anónimas. Aplícalo con cuidado: algunos formularios, carritos o filtros lo usan sin autenticación y dejarían de funcionar. Prueba primero en un entorno de staging.
¿Qué alternativas hay a admin-ajax.php para peticiones del frontend?
La API REST de WordPress es la vía recomendada desde hace años y permite endpoints más específicos y cacheables. Para acciones simples también sirven formularios que envían datos por POST a una URL propia o un endpoint REST ligero. La ventaja es evitar cargar todo el núcleo en cada petición, aunque requiere registrar rutas y validar permisos con cuidado.
