Cómo el uso de IA en WordPress afecta el rendimiento de tu hosting

El chatbot de tu tienda WooCommerce funciona perfecto en las pruebas. Responde preguntas sobre productos, ayuda a comparar opciones y parece rápido. El problema aparece recién cuando llega una tarde de mucho tráfico: el checkout empieza a demorarse y los tiempos de respuesta suben aunque la cantidad de visitantes sea la misma que la semana pasada.

Lo que cambió no fue el tráfico, sino el trabajo que el servidor realiza en cada visita. Cada intercambio con el chatbot dispara una llamada a una API externa que pasa por WordPress, evita el caché de página y ocupa un hilo PHP mientras el proveedor del modelo genera la respuesta. Puede además consultar la base de datos para detalles de productos, historial de conversación o contexto del usuario.

El comprador ve la respuesta en dos segundos. El servidor ve un hilo que no puede usar para nada más durante ese tiempo. Esta pregunta de infraestructura se está volviendo cada vez más difícil de ignorar.

WordPress 7.0 incorporó IA en el núcleo con un AI Client agnóstico de proveedor, la Abilities API y un hub central de conectores. Pero la presión también puede venir de funcionalidades que parecen muy distintas: búsqueda con IA, recomendaciones de productos, contenido personalizado, herramientas editoriales o integraciones de agentes.

Saber si corren en el dashboard, en el front-end o a través de una API (y si sus pedidos se pueden cachear) te ayuda a planificar los recursos de servidor que van a necesitar. La IA en WordPress no es una sola carga de trabajo. Dónde se ejecuta, cuándo se ejecuta y si un visitante la dispara afecta completamente el perfil de infraestructura.

Los plugins conversacionales como AI Engine (con más de 100.000 instalaciones activas), MxChat o Tidio ponen interfaces de chat en el front-end. Cada mensaje puede iniciar varios pedidos dinámicos, recuperar contexto, llamar a un modelo externo y guardar datos de conversación. A diferencia de un formulario de contacto, una sola charla puede generar varios pedidos en rápida sucesión.

Las recomendaciones personalizadas y la búsqueda con IA también corren en el front-end. En una tienda WooCommerce eso puede significar ajustar sugerencias según lo que el comprador ya vio o interpretar una consulta en lugar de buscar coincidencia exacta. El resto de la página puede salir del caché, pero esos resultados tienen que generarse para cada pedido individual.

Herramientas como Jetpack AI, Rank Math Content AI, Divi AI o GetGenie corren principalmente dentro del dashboard. Por eso no suelen ralentizar las cargas de página del front-end. Igual pueden generar presión notable cuando varios editores las usan al mismo tiempo.

Las integraciones MCP (como las de AI Engine o el adaptador oficial de WordPress) no esperan a que alguien visite el sitio. Cada tarea llega como un pedido API autenticado y suma otra fuente de actividad en el servidor.

Dos sitios pueden usar IA y necesitar niveles muy distintos de recursos de hosting. Uno la usa ocasionalmente en el editor para sugerir títulos; otro genera recomendaciones para cada comprador. Para estimar el impacto hay que mirar dónde corre la funcionalidad y con qué frecuencia dispara pedidos a WordPress.

El costo real de una funcionalidad con IA viene del trabajo que rodea la respuesta del modelo. WordPress tiene que recibir el pedido, ejecutar código del plugin, recuperar datos, . Cuatro partes de ese proceso impactan más en el rendimiento.

El caché permite servir contenido sin usar un hilo PHP. Un pedido dinámico con IA debe ser procesado por uno, y cada hilo maneja solo un pedido a la vez. Si un chatbot espera dos segundos por un proveedor externo, el hilo PHP queda ocupado esos dos segundos. Cuando varias conversaciones simultáneas usan todos los hilos disponibles, otros pedidos sin caché entran en cola.

Muchas respuestas de IA son específicas del usuario que las pide, por lo que no se pueden reutilizar para el siguiente visitante. La página principal puede seguir saliendo del caché, pero un panel de recomendaciones o un resultado de búsqueda con IA debe generarse por separado.

Antes de enviar un prompt, el plugin suele necesitar traer detalles de productos, mensajes anteriores o información del usuario desde WordPress. Como esos datos cambian entre pedidos, es más difícil cachearlos que una consulta de página normal. Si muchos pedidos llegan juntos, suman actividad en la base de datos justo cuando el checkout y las páginas de cuenta también están trabajando.

Los plugins de IA suelen esperar a un servicio de terceros antes de terminar el pedido. Si OpenAI tarda tres segundos, WordPress también espera, y con una llamada síncrona el hilo PHP queda bloqueado. El plugin debería tener un timeout para que una llamada trabada no quede abierta indefinidamente.

WordPress 7.0 mismo dio un ejemplo útil: el equipo sacó la colaboración en tiempo real de la versión final después de que las pruebas mostraran problemas de carga de servidor, uso de memoria y race conditions.

Las cargas de IA son dinámicas, por ráfagas y suelen depender de servicios externos. Tres características del hosting determinan si esos pedidos se mantienen contenidos o empiezan a afectar el resto del sitio.

En hosting compartido, si la actividad de IA sube de repente puede consumir CPU, memoria y recursos de base de datos que otros sitios en la misma máquina necesitan. Kinsta corre cada sitio WordPress en su propio contenedor Linux aislado con pila dedicada (Nginx, PHP y MySQL). Cada sitio recibe su propio hilo PHP y asignación de memoria. Si un chatbot maneja decenas de conversaciones simultáneas, la carga queda dentro de ese contenedor y no afecta a otros sitios.

Esta aislamiento es especialmente valioso para agencias: un plugin de IA mal configurado en un sitio de cliente no degrada el resto del portafolio.

PHP 7.4 corre WordPress 7.0, pero PHP 8.x maneja el código más rápido, libera antes el hilo PHP y reduce el trabajo que WordPress hace antes y después de la llamada externa. Kinsta soporta hasta PHP 8.5 y permite cambiar la versión por sitio desde MyKinsta. Siempre probá primero en staging.

Los problemas de rendimiento con IA pueden originarse en el código PHP del plugin, una consulta a la base de datos, el proveedor del modelo o falta de hilos PHP. Sin datos por pedido, todo parece una ralentización general del hosting.

La herramienta APM de Kinsta separa esos componentes. Una investigación práctica permite ver en qué se fue el tiempo: si es una transacción lenta de WordPress, una base de datos saturada o una API de modelo que tarda segundos.

La IA también aumenta la demanda en la otra dirección. Tu sitio envía más pedidos a proveedores de modelos, pero sistemas automáticos envían más pedidos a tu sitio. La publicación asistida por IA puede expandir rápidamente la superficie de crawl. Si un equipo pasa de 5 a 20 artículos por semana, el sitio suma más URLs, links internos, archivos y paginación para los crawlers.

Los crawlers no saben que la IA ayudó a crear el contenido; solo ven una biblioteca más grande y actualizada con más frecuencia. Un millón de pedidos a páginas cacheadas genera una carga muy distinta que un millón a URLs dinámicas. Kinsta analizó más de 10 mil millones de pedidos y vio que los crawlers golpean repetidamente resultados de búsqueda, páginas de productos filtradas, links de agregar al carrito y endpoints similares.

Eso pone al tráfico automatizado en competencia con las propias funcionalidades de IA de tu sitio. Tanto un pedido de chatbot como un crawler que pega en un filtro dinámico de productos ocupan hilos PHP.

Un sitio con IA necesita suficiente margen para los pedidos que realmente hacen los visitantes. Los controles de bots ayudan a preservarlo. Kinsta Bot Protection ofrece controles a nivel de entorno para permitir, desafiar o bloquear tráfico automatizado, con una opción separada para crawlers de IA. Sus analíticas muestran cómo se clasifican y manejan los pedidos.

Combiná esas analíticas con los traces de APM, reportes de cache-bypass y los IPs de clientes más activos en MyKinsta. Así es más fácil distinguir si la carga viene de tus propias herramientas de IA o de crawlers externos.

Antes de pasar una funcionalidad con IA a producción, probala en tu infraestructura actual. Empezá respondiendo estas cinco preguntas:

• ¿Dónde corre la funcionalidad? (dashboard, front-end o API)
• ¿Qué parte de la respuesta se puede cachear y por cuánto tiempo?
• ¿Qué pasa cuando la llamada al modelo falla o se demora mucho?
• ¿Cuánto agregan las consultas a la base de datos en escenarios de concurrencia?
• ¿Cómo se comporta el sitio cuando varios usuarios o conversaciones ocurren al mismo tiempo?

Instalá el plugin en staging, activá la herramienta APM de Kinsta y reproducí conversaciones, búsquedas o flujos de generación de contenido, incluyendo actividad concurrente. Revisá las pestañas de Transactions, External y Database para ver exactamente dónde se va el tiempo.

Según informó Kinsta.