La mayoría de las pruebas de rendimiento de WordPress se hacen en un momento de calma. Muestran cómo se carga una página cuando en el sitio no hay mucha actividad en segundo plano.

Los sitios en producción casi nunca funcionan así.

Un sitio de WordPress activo puede atender a los visitantes mientras se ejecutan tareas programadas, se procesan importaciones de productos, se realizan copias de seguridad, se sincronizan pedidos, los plugins llevan a cabo tareas programadas y las actualizaciones se procesan en el sistema. Los visitantes no ven cómo ocurre todo eso, pero pueden notar el impacto cuando las páginas tardan en cargarse, los formularios van lentos, los resultados de búsqueda se atascan o el proceso de pago tarda más de lo habitual.

Por eso los problemas de rendimiento pueden parecer aleatorios. Una página puede funcionar bien por la mañana y, unas horas más tarde, ralentizarse, aunque no haya cambiado nada visible en la interfaz de usuario.

En este artículo, analizamos cómo las cron jobs, las importaciones, las copias de seguridad y otros procesos en segundo plano afectan al rendimiento de WordPress, cómo detectar las señales de alerta y por qué el alojamiento juega un papel tan importante a la hora de mantener estable la experiencia del usuario mientras se realizan tareas en segundo plano.

Por qué se ralentizan los sitios de WordPress durante la actividad en segundo plano

Las tareas en segundo plano pueden ejecutarse sin que te des cuenta, pero siguen consumiendo recursos del servidor. Los cron jobs, las importaciones, las copias de seguridad y las tareas de los plugins pueden consumir recursos de PHP, ejecutar consultas a la base de datos y utilizar memoria, CPU e I/O de disco mientras los visitantes están usando la web.

Es precisamente en ese momento donde empiezan los problemas de rendimiento. Un visitante que carga una página, envía un formulario, busca productos, inicia sesión en una cuenta o realiza el pago puede necesitar los mismos recursos que una tarea en segundo plano.

El almacenamiento en caché puede aliviar un poco la carga. Si una página ya está almacenada en caché, el servidor suele poder servirla rápidamente sin tener que ejecutar WordPress desde cero. Pero las solicitudes dinámicas funcionan de otra manera. Las páginas de pago, los paneles de control de las cuentas, las pantallas de administración, los portales de membresía, los resultados de búsqueda y el envío de formularios suelen necesitar ejecución de PHP en tiempo real y actividad de la base de datos. Cuando las tareas en segundo plano están utilizando esos recursos, estas partes del sitio suelen ser las primeras en ralentizarse.

Por eso las tiendas de comercio electrónico, los sitios de membresía, las plataformas LMS, los editores y los sitios con mucho tráfico notan el impacto con más frecuencia. Procesan pedidos, actualizan registros de usuarios, gestionan suscripciones, publican contenido, sincronizan el inventario, envían notificaciones y dan soporte a los usuarios que han iniciado sesión a lo largo del día.

Muchas pruebas de rendimiento pasan por alto estos factores. Un sitio web puede funcionar bien cuando está inactivo, pero tener problemas cuando se intensifica la actividad normal de producción. El rendimiento real de WordPress depende de lo bien que el sitio gestione simultáneamente el tráfico del frontend y las tareas en segundo plano.

Tareas en segundo plano habituales que afectan al rendimiento

La actividad en segundo plano de WordPress proviene de varias fuentes. Algunas tareas provienen del núcleo de WordPress. Otras provienen de plugins, temas, herramientas de comercio electrónico, integraciones de marketing o del entorno de alojamiento.

Por sí solas, muchas de estas tareas son normales y necesarias. El problema surge cuando se ejecutan con demasiada frecuencia, duran demasiado o se solapan con la actividad de los visitantes.

Algunos ejemplos comunes son:

• Eventos de WP-Cron: WordPress y los plugins usan tareas programadas para publicar, limpiar, comprobar actualizaciones, enviar notificaciones y otras tareas recurrentes.
• Importaciones de productos o contenido: las importaciones de gran volumen pueden actualizar entradas, productos, imágenes, categorías, etiquetas, campos personalizados y metadatos.
• Actualizaciones de la base de datos: los plugins pueden crear, modificar o limpiar tablas de la base de datos durante las actualizaciones o el mantenimiento programado.
• Actualizaciones de plugins y temas: las actualizaciones pueden provocar cambios en los archivos, migraciones de la base de datos, vaciado de la caché y comprobaciones tras la actualización.
• Copias de seguridad completas del sitio o de la base de datos: las tareas de copia de seguridad pueden escanear archivos, exportar tablas de la base de datos, comprimir archivos y trasladar datos al almacenamiento.
• Procesamiento de pedidos de WooCommerce: los pedidos pueden activar correos electrónicos, actualizaciones de stock, cambios en el estado de los pagos, cálculos de impuestos, flujos de trabajo de envío y actividad en el CRM.
• Renovaciones de suscripciones: Los sitios de membresía y suscripción suelen gestionar pagos recurrentes, cambios de acceso, avisos de pagos fallidos y actualizaciones de cuentas.
• Sincronizaciones de inventario: las tiendas de comercio electrónico pueden sincronizar la disponibilidad de productos entre almacenes, sistemas de punto de venta, marketplaces o fuentes de datos de proveedores.
• Sincronizaciones con CRM o marketing por correo electrónico: el envío de formularios, las compras, las actualizaciones de usuarios y los cambios en las listas pueden activar transferencias de datos a plataformas de terceros.
• Indexación de búsquedas: los plugins de búsqueda y filtrado pueden reconstruir índices, lo que permite a los visitantes buscar productos, entradas, documentos o anuncios.
• Procesamiento de imágenes: las subidas e importaciones pueden activar la generación de miniaturas, la compresión, la conversión de formatos y las actualizaciones de metadatos.
• Publicación programada: los editores pueden poner en cola entradas, páginas de destino, lanzamientos de productos o contenido de campañas para que se publiquen a horas concretas.
• Tareas de limpieza de plugins: los plugins pueden eliminar datos transitorios caducados, sesiones antiguas, registros, revisiones, carritos abandonados o archivos temporales.

Las importaciones y las sincronizaciones merecen una atención especial porque pueden generar mucho trabajo sin que, a simple vista, parezca nada del otro mundo. Una importación de productos, por ejemplo, puede implicar miles de escrituras en la base de datos, descargas de imágenes, generación de miniaturas, actualizaciones de taxonomía, cambios en los metadatos y limpieza de la caché. Una sincronización puede parecer un pequeño proceso en segundo plano, pero si se ejecuta cada pocos minutos, puede estar accediendo a la base de datos constantemente a lo largo del día.

El impacto depende de cómo se ejecute la tarea. Un trabajo por lotes pequeño durante un periodo de poco tráfico puede pasar casi desapercibido. En cambio, una importación grande en horas punta puede ralentizar procesos como el pago y otras partes dinámicas de la web. El momento en que se realiza, el tamaño del lote, la calidad del plugin, el estado de la base de datos y los recursos de alojamiento influyen en el grado de interrupción que causa la actividad en segundo plano.

Por qué WP-Cron puede provocar picos de rendimiento

WP-Cron ayuda a WordPress a ejecutar tareas programadas como publicar entradas, buscar actualizaciones, enviar notificaciones, borrar datos temporales y activar los flujos de trabajo de los plugins.

El problema es que, por defecto, WP-Cron no funciona como un auténtico cron de servidor. En lugar de seguir una programación fija del servidor, comprueba si hay tareas pendientes cada vez que alguien visita el sitio. Eso significa que la carga normal de una página también puede activar tareas en segundo plano.

En sitios con mucho tráfico, esto puede provocar picos de rendimiento durante los periodos de mayor actividad. Los visitantes que cargan páginas, envían formularios, exploran productos o realizan el proceso de compra pueden experimentar respuestas más lentas mientras WordPress procesa simultáneamente las tareas programadas. Esa actividad adicional de PHP y de la base de datos afecta sobre todo a las solicitudes dinámicas, justo cuando el sitio necesita esos recursos para los usuarios.

Los sitios con poco tráfico pueden tener el problema contrario. Si hay poca gente que los visita, puede que WP-Cron no se ejecute a tiempo. Las tareas pueden acumularse y procesarse todas de golpe la próxima vez que alguien cargue la página. Ese visitante puede notar que la página va más lenta porque WordPress tiene que procesar un montón de tareas atrasadas.

Un cron del servidor de verdad le da a WordPress una programación más predecible. En lugar de esperar a que el tráfico de visitantes active las tareas, el servidor las ejecuta a intervalos fijos. No hace que todas las tareas en segundo plano sean ligeras, pero sí reduce la probabilidad de que las tareas programadas se ejecuten en momentos aleatorios mientras estás usando la página.

WP-Cron frente a Servidor Real Cómo pueden afectar las copias de seguridad al rendimiento de WordPress

Las copias de seguridad protegen tu sitio, así que son imprescindibles. Si algo sale mal durante una actualización, una importación, un Despliegue o un problema de seguridad, una copia de seguridad reciente te puede ayudar a recuperarte rápidamente.

Pero las copias de seguridad siguen necesitando recursos para ejecutarse. El impacto depende de cómo funcione la copia de seguridad, del tamaño del sitio, de la frecuencia con la que se ejecuten y de qué más esté ocurriendo en el sitio al mismo tiempo.

Las copias de seguridad basadas en plugins pueden ser más exigentes porque suelen ejecutarse directamente a través de WordPress. Un plugin de copias de seguridad puede escanear archivos, exportar tablas de la base de datos, comprimir archivos, crear archivos temporales y enviar los datos de la copia de seguridad a un almacenamiento remoto. Ese proceso puede consumir recursos de PHP, conexiones a la base de datos, CPU, memoria y I/O de disco mientras los visitantes siguen utilizando el sitio.

Los sitios web grandes se ven más afectados. Una tienda de WooCommerce con años de datos de pedidos, un blog con miles de entradas o un sitio de membresía con muchos usuarios pueden tener más archivos, tablas, registros, sesiones y metadatos que procesar. Los sitios con mucho contenido multimedia pueden suponer una carga aún mayor, ya que las bibliotecas de imágenes tardan tiempo en analizarse y empaquetarse.

El momento también es importante. Una copia de seguridad durante un periodo de poco tráfico apenas afectará a los visitantes. Sin embargo, si se hace durante una campaña de rebajas, la importación de productos, una hora punta con muchos procesos de pago o un periodo de mucha actividad administrativa, puede interferir con el tráfico en tiempo real y ralentizar las solicitudes dinámicas.

La cuestión no es que las copias de seguridad sean malas. Es que la estrategia de copias de seguridad afecta al rendimiento. Los flujos de trabajo de copias de seguridad a nivel de alojamiento pueden reducir la necesidad de utilizar plugins de copias de seguridad pesados dentro de WordPress, lo que ayuda a los equipos a proteger el sitio sin que la experiencia del usuario se vea tan afectada.

Por qué los problemas de rendimiento en segundo plano parecen aleatorios

Los problemas de rendimiento en segundo plano son difíciles de detectar porque los síntomas aparecen antes de que se identifique la causa. Los propietarios de los sitios web notan la ralentización, pero el evento cron, la importación, la copia de seguridad o la sincronización responsables de ello ya se están ejecutando en segundo plano sin que te des cuenta.

Esa desconexión es lo que hace que estos problemas parezcan incoherentes. No ha cambiado nada a simple vista en la interfaz, pero la carga de trabajo oculta sí lo ha hecho.

Las páginas en caché suelen seguir cargándose sin problemas. El impacto suele notarse más en las partes dinámicas del sitio: actividad de la cuenta, flujos de trabajo de administración, envíos de formularios y páginas con muchas búsquedas. Estas solicitudes dependen de recursos PHP y de la base de datos en tiempo real, por lo que notan la presión antes que las páginas estáticas o en caché.

Algunos signos comunes son:

• Picos en el tiempo de respuesta del servidor sin un aumento claro del tráfico
• Aumento de la lentitud en el proceso de pago, el inicio de sesión, las búsquedas o las acciones de administración
• Tiempos de espera durante importaciones, actualizaciones, copias de seguridad o tareas de plugins
• Los visitantes dicen que el sitio parece funcionar de forma irregular
• Pruebas de velocidad que parecen correctas fuera del periodo en el que se produce el problema
• Ralentizaciones que se producen a horas similares cada día o cada semana

En muchos casos, el problema no está en la página en sí. El sitio está compitiendo con su propia carga de trabajo en segundo plano.

Cómo diagnosticar problemas de rendimiento en segundo plano

Lo mejor es empezar por el momento en que ocurre. Si el sitio se ralentiza a ciertas horas del día, durante flujos de trabajo específicos o justo después de una actividad programada, ese patrón puede ayudarte a identificar la causa.

Revisa las tareas programadas

Revisa las programaciones de cron para ver qué tareas se ejecutan, con qué frecuencia lo hacen y si hay varias que se activan al mismo tiempo. Puede que una sola tarea programada no suponga mucha carga, pero si se ejecutan varias a la vez, la carga sobre PHP y la base de datos puede aumentar rápidamente.

Revisa las copias de seguridad, las importaciones y las sincronizaciones

Fíjate en los horarios de las copias de seguridad, los registros de importación y los de sincronización. Si las ralentizaciones coinciden con copias de seguridad completas del sitio web, exportaciones de la base de datos, actualizaciones de feeds de productos, sincronizaciones de inventario, sincronizaciones de CRM o integraciones de marketing por correo electrónico, es posible que la actividad en segundo plano esté compitiendo con el tráfico en tiempo real.

En el caso de los sitios de WooCommerce, revisa también las acciones programadas. El procesamiento de pedidos, las renovaciones de suscripciones, los reintentos de pago, los correos electrónicos, los webhooks y las actualizaciones de inventario pueden generar trabajo en segundo plano. Una acumulación de acciones pendientes o fallidas puede indicar que hay tareas que no se están completando correctamente.

Compara los periodos de ralentización con el tráfico

Analiza el rendimiento en función de los patrones de tráfico. Si los tiempos de respuesta se disparan durante un pico de tráfico, es posible que el sitio necesite más capacidad o una caché más potente. Si los tiempos de respuesta se disparan mientras el tráfico se mantiene normal, es más probable que la causa sea la actividad en segundo plano.

Echa un vistazo a los datos del servidor y de la aplicación

Comprueba el uso de hilos PHP para ver si hay solicitudes dinámicas en cola. Revisa las consultas lentas a la base de datos, los registros de errores, los tiempos de espera, los problemas de memoria, las solicitudes externas fallidas y las advertencias repetidas de los plugins.

Los datos de APM pueden relacionar todas estas pistas. Ayudan a los equipos a identificar transacciones PHP lentas, consultas a la base de datos, peticiones HTTP externas y procesos de larga duración durante el periodo en el que se produjo el problema. En lugar de tener que adivinar qué tarea provocó la ralentización, pueden ver dónde invirtió el sitio tiempo y recursos.

Qué debes tener en cuenta en el alojamiento para sitios de WordPress con mucha actividad en segundo plano

El alojamiento influye en cómo gestiona WordPress tanto el tráfico del frontend como el trabajo en segundo plano al mismo tiempo. Incluso un sitio bien construido puede tener problemas si el entorno de alojamiento no tiene suficiente capacidad para la actividad real de producción.

Si tu sitio web tiene cron jobs frecuentes, importaciones, copias de seguridad, sincronizaciones o actividad de comercio electrónico, busca un alojamiento que incluya:

• Aislamiento de recursos: El trabajo en segundo plano no debería depender de un entorno compartido saturado ni afectar fácilmente a otros sitios web.
• Suficiente capacidad PHP: Si las tareas en segundo plano consumen demasiada capacidad PHP, las solicitudes dinámicas se acumulan en la cola y los visitantes tienen que esperar.
• Compatibilidad real con tareas cron en el servidor: Las tareas programadas deben ejecutarse según un horario predecible, en lugar de depender del tráfico de visitantes para activarse.
• Almacenamiento en caché potente: La caché de páginas, la compatibilidad con CDN y Edge Caching pueden reducir el número de solicitudes que necesitan recursos de PHP y de la base de datos.
• Optimización del rendimiento de la base de datos: Las importaciones, los pedidos, la indexación de búsquedas, las renovaciones de suscripciones y las tareas de limpieza dependen todas del buen funcionamiento de la base de datos.
• Flujos de trabajo de copias de seguridad fiables: Las copias de seguridad deben proteger el sitio sin que cada tarea de copia tenga que ejecutarse a través del propio WordPress.
• Visibilidad del rendimiento: Las herramientas de analítica, los datos de uso de PHP, los datos de caché, los códigos de respuesta, los registros y las herramientas APM ayudan a los equipos a ver qué ha pasado durante una ralentización.
• Soporte específico para WordPress: Los problemas de rendimiento en segundo plano pueden estar relacionados con el comportamiento de las tareas cron, los plugins, los límites de PHP, las consultas a la base de datos, las reglas de caché, las llamadas a APIs externas o las acciones programadas de WooCommerce.

Estas características son fundamentales para los sitios que dependen de elementos como pedidos, inicios de sesión, importaciones, renovaciones, sincronizaciones, flujos de trabajo de publicación o actividad de administración. Cuanto más dependa un sitio de estas cargas de trabajo, más necesitará un alojamiento diseñado para que el trabajo de frontend y backend se realice al mismo tiempo.

Cómo mantiene Kinsta la velocidad de respuesta de WordPress mientras se realizan tareas en segundo plano

Kinsta ofrece a los sitios de WordPress un entorno de alojamiento diseñado para la actividad real de producción, no solo para simples pruebas de velocidad.

Cada sitio de WordPress se ejecuta en su propio contenedor de software aislado con los recursos necesarios para su funcionamiento, incluyendo Linux, NGINX, PHP y MySQL. Esa separación hace que el uso de recursos sea más predecible cuando las tareas programadas, las importaciones, las copias de seguridad o las sincronizaciones empiezan a ejecutarse al mismo tiempo que el tráfico en tiempo real.

Kinsta también ofrece a los equipos más control sobre el rendimiento de PHP. Las solicitudes dinámicas, como el proceso de pago, el inicio de sesión, las búsquedas, los flujos de trabajo de administración, las importaciones y la actividad de los miembros, dependen todas de PHP. En MyKinsta, los equipos pueden revisar y ajustar la configuración de rendimiento de PHP para cada sitio, de modo que el entorno se adapte mejor a la carga de trabajo.

El rendimiento de PHP se puede ajustar en MyKinsta.

La caché también ayuda a reducir la carga. Kinsta utiliza la caché FastCGI de NGINX para almacenar las páginas en caché, de modo que las páginas que se pueden almacenar en caché se cargan sin necesidad de usar hilos de PHP. Así se mantiene más capacidad de PHP disponible para las solicitudes dinámicas que la necesitan.

También puedes ajustar la configuración de la caché en MyKinsta.

En cuanto a las tareas programadas, Kinsta soporta cron jobs a nivel de servidor. Esto ofrece a los equipos una forma más predecible de ejecutar tareas en segundo plano, en lugar de depender únicamente de los eventos de WP-Cron que se activan con las visitas al sitio.

Kinsta también ofrece a los equipos una mejor visibilidad de los problemas de rendimiento. Las Analíticas de MyKinsta muestra el uso de recursos, los datos de rendimiento, los códigos de respuesta, el comportamiento de la caché, el uso de la CDN y los patrones de tráfico. Kinsta APM va más allá con datos sobre procesos PHP, consultas MySQL, llamadas HTTP externas y transacciones lentas, lo que facilita el seguimiento de las caídas de rendimiento relacionadas con la actividad en segundo plano.

En cuanto a las copias de seguridad, Kinsta ofrece copias de seguridad automáticas diarias de WordPress y copias generadas por el sistema, con puntos de restauración disponibles en MyKinsta. Esto reduce la necesidad de depender de plugins de copias de seguridad pesados que se ejecutan dentro de WordPress para la protección rutinaria.

En conjunto, estas funcionalidades ayudan a que WordPress siga respondiendo bien mientras el sitio web funciona en segundo plano. Los cron jobs siguen ejecutándose, las importaciones siguen procesándose y las copias de seguridad siguen siendo importantes. Pero los equipos tienen más control, más visibilidad y un entorno de alojamiento diseñado para gestionar las cargas de trabajo en segundo plano sin que afecte a la experiencia de los visitantes.

Mantén WordPress rápido mientras tu sitio web trabaja en segundo plano

Tu sitio de WordPress tiene que seguir respondiendo bien durante la actividad real de producción, no solo cuando está inactivo.

El alojamiento para WordPress de Kinsta ofrece a los equipos la infraestructura, el almacenamiento en caché, los controles de rendimiento de PHP, las copias de seguridad, la compatibilidad con tareas cron y la visibilidad que necesitan para que los sitios con mucho tráfico funcionen sin problemas.