Añádelo como fuente preferida en Google
Pongámonos en situación. Tu nuevo chatbot de WooCommerce supera todas las pruebas. Responde a preguntas sobre productos, ayuda a los compradores a comparar opciones y responde con tanta rapidez que nadie se plantea ni por un momento si el rendimiento es adecuado.
El problema no se nota hasta que la tienda tiene una tarde muy activa. El proceso de pago empieza a tardar un poco más y los tiempos de respuesta van aumentando a medida que los hilos de PHP llegan al límite de su capacidad. Al principio, la ralentización parece deberse a un pico de tráfico, pero el número de visitantes es más o menos el mismo que la semana anterior. Lo que ha cambiado es la cantidad de trabajo que realiza el servidor durante cada visita.
Cada intercambio con el chatbot puede activar una llamada a la API en tiempo real que pasa por WordPress, evita la caché de la página y ocupa un hilo de PHP mientras el proveedor del modelo genera su respuesta. También puede consultar la base de datos para obtener detalles del producto, el historial de la conversación u otro tipo de contexto. El comprador ve que la respuesta llega en dos segundos. El servidor ve un hilo que no puede usar para nada más durante ese tiempo.
Cada vez resulta más difícil evitar esta cuestión relacionada con la infraestructura. WordPress 7.0 incorporó la IA al núcleo mediante un cliente de IA independiente del proveedor, junto con la API Abilities y un centro de conectores centralizado.
Esa misma carga puede venir de funcionalidades que, a simple vista, parecen muy diferentes. La búsqueda con IA, las recomendaciones de productos, el contenido personalizado, las herramientas editoriales y las integraciones con agentes interactúan cada una a su manera con WordPress. Saber si se ejecutan en el panel de control, en el front end o a través de una API (y si sus solicitudes se pueden almacenar en la caché) te ayuda a planificar los recursos del servidor que van a necesitar.
Cómo funciona realmente la IA de WordPress en un sitio web activo
La IA en WordPress no es una única carga de trabajo. El lugar donde se ejecuta la funcionalidad, cuándo se ejecuta y si un visitante la activa son factores que influyen en el perfil de la infraestructura.
Chatbots con IA y asistentes de atención al cliente
Esta es la categoría más visible. Plugins como AI Engine (con más de 100.000 instalaciones activas), MxChat y Tidio incorporan interfaces conversacionales en el front end.
Cada mensaje puede iniciar una solicitud dinámica, recuperar contexto, llamar a un modelo externo y almacenar datos de la conversación. A diferencia de lo que ocurre al enviar un formulario de contacto, una sola conversación puede generar varias de estas solicitudes en rápida sucesión.
Personalización, recomendaciones y búsqueda con IA
La personalización, las recomendaciones y la búsqueda con IA suelen ejecutarse en el front-end. En una tienda de WooCommerce, eso podría significar ajustar las sugerencias de productos en función de lo que el comprador ya haya visto o interpretar una consulta de búsqueda en lugar de buscar una coincidencia exacta con las palabras exactas. El resto de la página a menudo puede cargarse desde la caché, pero esos resultados aún deben generarse para cada solicitud individual.
Herramientas de generación de contenido y edición basadas en IA
Piensa en herramientas como Jetpack AI, Rank Math Content AI, Divi AI y GetGenie. Se ejecutan principalmente dentro del panel de control de WordPress.
Como estas herramientas se ejecutan principalmente en el panel de control de WordPress, por lo general no ralentizan la carga de las páginas del front-end. Aun así, pueden suponer una carga notable para el servidor cuando varios editores las usan al mismo tiempo.
Agentes de IA e integraciones con MCP
Las integraciones MCP no esperan a que alguien visite la web. La compatibilidad con MCP de AI Engine y el adaptador MCP oficial de WordPress permiten que una herramienta externa se conecte a WordPress y realice tareas autorizadas, como leer datos de la web o actualizar una entrada. Cada tarea se procesa como una solicitud de API autenticada, lo que añade otra fuente de actividad del servidor que hay que tener en cuenta.
Dos sitios web pueden usar IA y, aun así, necesitar niveles muy diferentes de recursos de alojamiento. Uno podría usarla de vez en cuando en el editor para sugerir titulares, mientras que otro genera recomendaciones de productos para cada comprador. Para calcular el impacto, fíjate dónde se ejecuta la funcionalidad y con qué frecuencia genera una solicitud de WordPress.
Qué efectos tienen realmente las funcionalidades de IA en tu servidor
El coste de una funcionalidad de IA viene determinado por el trabajo que conlleva la respuesta del modelo. WordPress sigue teniendo que recibir la solicitud, ejecutar el código del plugin, recuperar los datos necesarios, ponerse en contacto con el proveedor externo y devolver el resultado. Hay cuatro partes de ese proceso que son las que más afectan al rendimiento.
Los hilos de PHP permanecen ocupados más tiempo
El contenido almacenado en caché se puede servir sin usar un hilo de PHP. Una solicitud dinámica de IA debe procesarse mediante uno de ellos, y cada hilo solo gestiona una solicitud a la vez. Si un chatbot espera dos segundos a un proveedor externo, el hilo de PHP que gestiona ese intercambio puede permanecer ocupado durante esos dos segundos. Si las conversaciones simultáneas ocupan todos los hilos disponibles, las demás solicitudes que no están en caché pasan a una cola.
Esto es similar, desde el punto de vista estructural, a los patrones de tráfico de bots que se recogen en el Informe sobre IA y Tráfico de Bots de Kinsta. Los bots que acceden a endpoints de búsqueda, carrito y otros endpoints dinámicos reservan hilos de PHP y obligan a que el procesamiento se realice en el servidor de origen. Las funcionalidades de IA hacen lo mismo de forma intencionada y, en el mejor de los casos, de forma productiva. El coste de infraestructura de cada solicitud sigue siendo similar.
Cada vez hay más peticiones que no pasan por la caché
Muchas respuestas de IA son específicas para la persona que realiza la solicitud, por lo que no se pueden reutilizar sin más para el siguiente visitante. La página principal del producto puede seguir cargándose desde la caché, pero un panel de recomendaciones o un resultado de búsqueda de IA tiene que generarse por separado. Cuanto más a menudo ocurra esto durante una visita, más solicitudes tendrá que gestionar el servidor de origen.
La actividad de la base de datos se vuelve más compleja
Antes de enviar una solicitud, puede que un plugin tenga que recuperar datos del producto, mensajes anteriores o información sobre el usuario desde WordPress. Como los datos cambian de una solicitud a otra, es más difícil almacenarlos en la caché que una consulta normal a la página. Si llegan muchas de estas solicitudes a la vez, aumentan la actividad de la base de datos justo cuando las páginas del carrito y el registro están intentando hacer su trabajo.
La latencia de las API externas afecta al rendimiento del sitio
Los plugins de IA suelen tener que esperar a que un servicio externo responda antes de poder completar una solicitud. Si OpenAI tarda tres segundos en responder, WordPress también se queda esperando —y, al tratarse de una llamada sincrónica, lo mismo ocurre con el hilo de PHP que la gestiona—. El plugin debería tener un tiempo de espera para que una llamada bloqueada no se quede abierta indefinidamente. Algunas cargas de trabajo también se pueden poner en cola o almacenar en la caché, aunque un chatbot en tiempo real normalmente tiene que esperar al proveedor.
El propio WordPress 7.0 ofrece un ejemplo muy útil. El equipo del núcleo retiró la colaboración en tiempo real de la versión después de que las pruebas plantearan dudas sobre la carga del servidor, el uso de memoria y las condiciones de carrera. La funcionalidad seguía teniendo valor, pero no estaba lista para lanzarse dentro de los límites de rendimiento que debía cumplir el núcleo de WordPress.
Las tres características de alojamiento más importantes para un WordPress con IA
Las cargas de trabajo de IA son dinámicas, presentan picos de actividad y, a menudo, dependen de servicios ajenos a tu entorno de alojamiento. Hay tres características del alojamiento que determinan si esas solicitudes se mantienen controladas y se pueden diagnosticar, o si empiezan a afectar al resto del sitio web.
1. Arquitectura de contenedores aislados
Esto puede ser un problema en el alojamiento compartido, donde tu sitio no es el único que utiliza el servidor. Si la actividad de IA se dispara de repente, puede consumir los recursos de CPU, memoria y base de datos disponibles para otros sitios en la misma máquina.
Kinsta aloja cada sitio de WordPress en su propio contenedor Linux aislado, con un stack de software dedicado que incluye Nginx, PHP y MySQL. Además, cada sitio cuenta con su propio hilo de PHP y su propia asignación de memoria. Si un chatbot de IA se encuentra de repente gestionando docenas de conversaciones a la vez, su carga de trabajo se mantiene dentro del contenedor de ese sitio, en lugar de usar recursos asignados a otro sitio.
Este aislamiento es especialmente valioso para las agencias. Un plugin de IA mal configurado en el sitio de un cliente puede seguir afectando a ese sitio, pero el problema no se extiende al resto del portfolio.
2. Una versión de PHP actualizada y la configuración adecuada
PHP 7.4 es compatible con WordPress 7.0, pero no es la versión que elegirías si buscas rendimiento. PHP 8.x procesa el código de WordPress más rápido, por lo que el trabajo relacionado con una solicitud de IA tarda menos tiempo y el hilo de PHP queda disponible antes.
Una versión más reciente de PHP no hace que OpenAI o Anthropic respondan más rápido, pero sí puede reducir el trabajo que realiza WordPress antes y después de esa llamada externa. Kinsta admite versiones de PHP hasta la 8.5 y te permite cambiar de versión en entornos individuales, ya sean de producción o staging, desde MyKinsta. Probar primero el cambio en el entorno de desarrollo te ayuda a detectar posibles conflictos de compatibilidad en el plugin de IA, el tema o el código personalizado.
3. Visibilidad de toda la solicitud
Los problemas de rendimiento de la IA pueden tener su origen en varios sitios: el código PHP del plugin, una consulta a la base de datos, el proveedor externo del modelo o una capacidad insuficiente de hilos. Sin datos a nivel de solicitud, las cuatro causas pueden parecer una ralentización general del alojamiento.
La herramienta APM de Kinsta separa esos componentes.
Una investigación práctica podría ser así:
- Ve a Analíticas > Rendimiento para comprobar cuándo aumentaron los tiempos de respuesta.
- Abre APM > Transacciones para identificar los endpoints y las solicitudes más lentos.
- Revisa APM > Externo para medir las llamadas a OpenAI, Anthropic u otro proveedor.
- Echa un vistazo a APM > Base de datos para detectar consultas de personalización lentas o repetidas.
- Realiza una revisión de las principales formas de eludir la caché del servidor para ver qué rutas generadas por IA llegan hasta el origen.
En cuanto veas dónde se ha ido el tiempo, tendrás un punto de partida útil. Una transacción lenta en WordPress requiere una solución diferente a la de una base de datos atascada o una API de modelo que tarda varios segundos en responder.
Las funcionalidades de IA también modifican tu perfil de tráfico
La IA puede aumentar la demanda de infraestructura en ambos sentidos. Tu sitio de WordPress envía más solicitudes a los proveedores de modelos, mientras que los sistemas automatizados envían más solicitudes a tu sitio.
La publicación asistida por IA puede ampliar rápidamente la superficie de rastreo de un sitio. Si un equipo de redacción aumenta su producción de cinco artículos a la semana a veinte, el sitio añade más URLs, enlaces internos, archivos y paginación que los rastreadores deben explorar. A los rastreadores no les importa ni saben necesariamente que la IA haya ayudado a producir el contenido. Simplemente ven una biblioteca más grande y que se actualiza con más frecuencia, y vuelven para rastrearla.
Un millón de solicitudes de páginas en la caché suponen una carga muy diferente para un servidor que un millón de solicitudes a URLs dinámicas. En el análisis de Kinsta de más de 10.000 millones de solicitudes, los rastreadores acceden repetidamente a resultados de búsqueda, páginas de productos filtradas, enlaces para añadir al carrito y endpoints similares. Cada solicitud puede saltarse la caché y enviar trabajo a PHP y a la base de datos.
Esto hace que el tráfico automatizado compita con las propias funcionalidades de IA de tu sitio. Una solicitud de un chatbot y un rastreador que accede a un filtro de productos dinámico pueden tener fines totalmente distintos, pero ambos pueden ocupar hilos de PHP. Si los rastreadores consumen una parte considerable de la capacidad disponible de tu sitio, las solicitudes de chatbots, búsquedas y recomendaciones legítimas tendrán menos espacio para ejecutarse.
Una web con IA necesita suficiente margen para las solicitudes que realmente hacen tus visitantes. Los controles de bots ayudan a mantenerlo. Googlebot sigue necesitando acceso a las páginas que quieres que se indexen, y quizá decidas que vale la pena permitir el acceso a algunos rastreadores de IA. El tráfico que hay que reducir es la actividad repetida en endpoints dinámicos que no aporta ningún valor, pero que sigue ocupando hilos de PHP.
La Protección contra bots de Kinsta ofrece controles a nivel de entorno para permitir, verificar o bloquear el tráfico automatizado, incluida una opción específica para los rastreadores de IA. Sus analíticas muestran cómo se clasifican y gestionan las solicitudes.
Las estadísticas de los bots son solo una parte del panorama. Compáralas con los registros de APM, los informes de omisión de la caché y las principales direcciones IP de los clientes en MyKinsta. Así te resultará más fácil saber si la carga proviene de tus propias funcionalidades de IA o de rastreadores externos, y si esas solicitudes de los rastreadores merecen los recursos que consumen.
Qué debes comprobar antes de añadir una funcionalidad de IA a un sitio de WordPress
Antes de poner en producción una funcionalidad de IA, comprueba cómo se comporta en tu infraestructura actual. Empieza por estas cinco preguntas.
1. ¿En qué momento del ciclo de solicitudes se ejecuta este plugin?
Aquí es importante la ruta de la solicitud. Las herramientas de redacción y edición suelen guardar su trabajo dentro de wp-admin. Las herramientas para los clientes comparten la capacidad de PHP con el resto del front end, incluidas las páginas de pago y de cuenta. Un agente puede saltarse ambas rutas y acceder a través de la API. Comprueba el flujo de solicitudes del plugin antes de calcular cuánta capacidad necesita.
2.¿Qué elementos puede almacenar en caché el plugin?
Averigua exactamente qué es lo que el plugin excluye de la caché. Puede que la respuesta en sí tenga que seguir siendo dinámica, ya que cambia según la pregunta o el usuario, pero los datos relacionados, como el estado de la conversación, los resultados de búsqueda o las recomendaciones, pueden ser reutilizables durante un breve periodo de tiempo. Un endpoint de API específico sin caché sale mucho más barato que un plugin que hace que toda la página del producto sea dinámica.
3. ¿Qué pasa si la API externa va lenta?
Prueba también una llamada que falle, no solo una que sea lenta. Interrumpe temporalmente la conexión en staging y fíjate cuándo termina la solicitud. Algunos plugins vuelven a intentarlo enseguida; otros permanecen abiertos hasta que PHP los corta. Si varias solicitudes del chatbot hacen eso a la vez, es posible que las solicitudes de pago y de cuenta tengan que esperar a que se libere un hilo de PHP.
4. Haz pruebas primero en el entorno staging con la herramienta APM funcionando.
Instala el plugin en un entorno staging y activa la herramienta APM de Kinsta durante las pruebas. Reproduce conversaciones típicas, búsquedas o flujos de trabajo de generación de contenido, incluyendo actividad simultánea cuando sea pertinente. Revisa las pestañas Transacciones, Externas y Base de datos para determinar cuánto tardan las solicitudes y en qué se invierte ese tiempo.
5. ¿PHP está preparado para el trabajo extra?
Anota cómo se comporta el sitio de staging antes de cambiar la versión de PHP. MyKinsta te muestra si ya se está alcanzando el límite de hilos de PHP, además de datos sobre el tiempo de respuesta y el uso de memoria. Cambia el sitio de staging a una versión actual de PHP 8.x, repite los mismos procesos y comprueba que el plugin sigue funcionando antes de aplicar el cambio en el entorno de producción.
Un entorno de staging no va a reproducir el entorno de producción a la perfección. Aun así, puede mostrar si el plugin hace que se salten demasiadas solicitudes de la caché, si tarda demasiado en responder a una API externa, si ejecuta consultas que consumen muchos recursos o si deja muy poca capacidad de PHP para el resto de la web.
Trata cada lanzamiento de IA como un cambio en la infraestructura
WordPress 7.0 ofrece a los desarrolladores una forma estándar de integrarse con proveedores de IA y llamar a modelos desde WordPress. El servidor sigue teniendo que procesar esas solicitudes una vez que la función está activa.
Antes de cambiar la configuración del alojamiento, abre unos cuantos registros APM. La lista de plugins no te dirá cuánto está trabajando tu sitio, y el número de hilos de PHP tampoco te explicará por qué una solicitud tarda tanto. Un registro te muestra si la solicitud ha pasado por alto la caché, cuánto tiempo ha tardado PHP en procesarla y si el retraso se debe a la base de datos o a la API del modelo. A partir de ahí, podrás decidir si hay que modificar el plugin o si tu sitio necesita más capacidad.
Un plugin de IA puede funcionar a la perfección y, aun así, no encajar bien con la capacidad actual de la web. Antes de implementarlo en la web del cliente, ejecuta APM en el entorno staging y comprueba cuánto tardan sus llamadas a API externas, qué peticiones no se almacenan en la caché y qué versión de PHP usa el entorno. Vuelve a revisar esos datos después del lanzamiento, cuando ya haya tráfico real.
Esas pocas comprobaciones pueden detectar la sobrecarga de hilos, las dependencias lentas y los comportamientos de consulta costosos antes de que se conviertan en un sitio web lento… o en una conversación complicada con el cliente.
