Cómo optimizar WordPress picos de tráfico en un servidor VPS o dedicado

El problema no es el tráfico en sí, sino si la configuración de tu servidor puede soportarlo sin ralentizarse hasta casi detenerse o quedarse completamente fuera de línea.

Esta guía trata sobre la configuración del lado del servidor que determina la capacidad de tu sitio web para soportar picos de tráfico. La optimización del front-end (compresión de imágenes, minificación) ayuda, pero el límite máximo de tráfico que se puede gestionar lo marca tu pila de servidores. Eso es lo que vamos a abordar aquí.

Por qué WordPress cuando hay mucha carga (y cómo solucionarlo de verdad)

WordPress las páginas de forma dinámica. Cada solicitud de un visitante, por defecto, activa una ejecución de PHP que consulta la base de datos, arma la página y la envía al navegador. Un sitio que recibe 1.000 solicitudes simultáneas significa que hay 1.000 procesos PHP en marcha y 1.000 consultas a la base de datos ocurriendo al mismo tiempo.

La solución consiste en servir páginas ya generadas desde la caché en lugar de generarlas con cada solicitud. Una WordPress correctamente almacenada en caché y servida desde la memoria consume una fracción de los recursos de CPU y E/S que una solicitud dinámica sin caché. La diferencia en la capacidad de solicitudes simultáneas no es incremental, sino de un orden de magnitud.

Almacenamiento en caché de páginas del lado del servidor

Caché de página completa con NGINX Cache

La caché FastCGI NGINXalmacena páginas HTML completas en el servidor y las sirve directamente, sin pasar por PHP ni por la base de datos en el caso de las páginas almacenadas en caché. Esta es la capa de almacenamiento en caché más eficaz para soportar picos de tráfico.

En el caso de WordPress alojados en la infraestructura de servidores VPS gestionados o servidores dedicados InMotion Hostingque incluyen NGINX su pila, la caché FastCGI se puede configurar a nivel de servidor. La UltraStack disponible en los planes de VPS gestionados de InMotion incluye un proxy NGINX con caché integrada, que se encarga de esto sin necesidad de configuración manual.

Plugins de almacenamiento en caché WordPress

En los sitios web en los que no se ha configurado el almacenamiento en caché NGINX, W3 Total Cache y WP Super Cache son las opciones principales. W3 Total Cache con configuraciones a nivel de servidor, como Redis y Memcached. WP Super Cache genera archivos HTML estáticos que Apache o NGINX directamente. Ambos reducen significativamente la frecuencia de ejecución de PHP.

Para los sitios alojados en InMotion, W3 Total Cache el plugin recomendado, ya que se adapta a la infraestructura de servidores de InMotion. Configúralo para que utilice el almacenamiento en caché mejorado por disco o el almacenamiento en caché de objetos Redis, dependiendo de tu plan.

Almacenamiento en caché de objetos en Redis

Redis es un almacén de datos en memoria que puede almacenar en caché los resultados de las consultas WordPress , lo que reduce el número de consultas a la base de datos cada vez que se carga una página. Para sitios con contenido que requiere un uso intensivo de la base de datos (catálogos de productos extensos, tiendas de WooCommerce, sitios con mucha actividad de sesiones de usuario), Redis ofrece una mejora significativa en el rendimiento.

Instalar Redis en un VPS de Ubuntu:

sudo apt install redis-server

sudo apt install redis-server

Configura los ajustes básicos de Redis en /etc/redis/redis.conf:

maxmemory 256mbmaxmemory-policy allkeys-lru

maxmemory 256mbmaxmemory-policy allkeys-lru

La política «allkeys-lru» elimina las claves menos utilizadas recientemente cuando la memoria está llena, lo cual es el comportamiento adecuado para un caso de uso de caché.

Instala el plugin Redis Object Cache en WordPress y, a continuación, configura el archivo wp-config.php:

define('WP_REDIS_HOST', '127.0.0.1');define('WP_REDIS_PORT', 6379);

define('WP_REDIS_HOST', '127.0.0.1');define('WP_REDIS_PORT', 6379);

Activa la caché de objetos desde el panel de control del plugin Redis Object Cache. Comprueba que esté activa y que la conexión esté establecida antes de habilitar el almacenamiento en caché.

Ajuste del grupo de PHP-FPM para picos de tráfico

PHP-FPM gestiona un grupo de procesos de trabajo de PHP. Durante un pico de tráfico, el número de solicitudes PHP simultáneas puede superar el número de procesos de trabajo disponibles en el grupo, lo que hace que las nuevas solicitudes se pongan en cola o se agoten el tiempo de espera. Ajustar el grupo antes de que se produzcan eventos de tráfico conocidos marca la diferencia entre un sitio web que aguanta el pico y uno que se colapsa ante él.

Edita la configuración del grupo de PHP-FPM (normalmente /etc/php/8.2/fpm/pool.d/www.conf):

pm = dynamicpm.max_children = 50pm.start_servers = 10pm.min_spare_servers = 10pm.max_spare_servers = 30

pm = dynamicpm.max_children = 50pm.start_servers = 10pm.min_spare_servers = 10pm.max_spare_servers = 30

pm.max_children establece el número máximo de procesos de trabajo de PHP. Cada proceso de trabajo consume memoria. Un cálculo aproximado: en un servidor con 4 GB de RAM, si asignas 1,5 GB a los procesos de trabajo de PHP (a unos 50 MB por proceso), obtendrás 30 procesos. Ajusta este valor según el consumo real de memoria de PHP de tu servidor.

En caso de eventos de tráfico previstos (lanzamientos de productos, campañas promocionales), aumenta temporalmente el valor de `pm.max_children`, supervisa el uso de memoria durante el evento y redúcelo después.

Configuración de MySQL para WordPress con alta concurrencia

La base de datos WordPresses el segundo cuello de botella más habitual, después de PHP, cuando el sistema está bajo carga. Hay dos ajustes que son los que más influyen.

El parámetro `max_connections` controla el número de conexiones simultáneas a la base de datos que acepta MySQL. El valor predeterminado suele ser 151. Cuando hay mucho WordPress , este límite se puede agotar rápidamente, lo que provoca errores del tipo «demasiadas conexiones». Aumenta este valor en el archivo `/etc/mysql/mysql.conf.d/mysqld.cnf`:

max_connections = 500

max_connections = 500

El parámetro `innodb_buffer_pool_size` determina la cantidad de datos que MySQL almacena en memoria. Las consultas que se atienden desde el búfer no requieren lecturas de disco, lo que supone la principal diferencia de rendimiento bajo carga. Configúralo al 70 % de la RAM disponible en un servidor dedicado a la base de datos, o entre el 25 y el 30 % en un servidor de aplicaciones compartido:

innodb_buffer_pool_size = 1G   # para un servidor de aplicaciones de 4 GB

innodb_buffer_pool_size = 1G   # for a 4GB application server

Integración de CDN para la descarga de recursos estáticos

Incluso una WordPress bien optimizada con caché envía una cantidad considerable de tráfico de recursos estáticos (imágenes, CSS, JavaScript) al servidor de origen. Una CDN descarga la entrega de archivos estáticos a nodos periféricos geográficamente cercanos a los visitantes, lo que reduce la carga del servidor de origen y mejora al mismo tiempo la percepción del rendimiento.

En el caso de WordPress, la integración de una CDN suele consistir en configurar Cloudflare de tu dominio o en utilizar un plugin WordPress . El plan gratuito Cloudflareofrece funciones básicas de CDN y protección contra ataques DDoS. Para sitios web en producción que gestionan tráfico real, las reglas de almacenamiento en caché Cloudflaredeben configurarse para almacenar en caché los recursos estáticos de forma intensiva y evitar el almacenamiento en caché de las páginas WordPress .

InMotion admite la integración de CDN en todos los planes de servidores VPS y dedicados. La clave está en configurar tu CDN para que respete el comportamiento de invalidación de la caché WordPress, sobre todo en sitios con WooCommerce o funciones de membresía, donde las páginas específicas de la sesión no deben almacenarse en caché.

Limpieza de la base de datos antes de los eventos

Con el tiempo, WordPress revisiones de entradas, opciones temporales y comentarios spam en la base de datos. Antes de un evento con mucho tráfico, limpiar la base de datos reduce el tamaño de las tablas y mejora el rendimiento de las consultas.

• Eliminar revisiones de entradas: usa el plugin WP-Optimize o ejecútalo directamente en MySQL.
• Borrar archivos temporales caducados: WP-Optimize también se encarga de esto.
• Vacía la cola de comentarios spam.
• Ejecuta OPTIMIZE TABLE en las tablas wp_posts y wp_options después de la limpieza.

Esto es mantenimiento, no una optimización de última hora. Incorpóralo a un plan trimestral en lugar de tratarlo solo como una preparación previa al evento.

Relacionado: «Optimiza tu VPS para WordPress explica en detalle WordPress optimizada de InMotion WordPress .WordPress : un solo sitio frente a varios sitios