Tener un VPS no hace rápido a tu WordPress. Lo que lo hace rápido es la configuración: un VPS recién instalado trae valores de fábrica pensados para cualquier cosa, no para una web WordPress.
Esta guía recorre las piezas que se afinan en un VPS dedicado a WordPress, en el orden en que conviene tocarlas y con una forma de comprobar que cada cambio ha servido. Si todavía no sabes qué tamaño de servidor necesitas, empieza por la guía de qué VPS elegir para WordPress.
Antes de tocar nada: mide
Optimizar sin medir es adivinar. Anota dos cosas antes del primer cambio:
1. El tiempo hasta el primer byte (TTFB) de tu portada y de una página interior, sin caché de navegador:
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://tudominio.com/Repítelo tres veces y quédate con la mediana. La primera puede salir peor porque la caché está fría.
2. Una página que no se pueda cachear: el carrito, el área de cliente o wp-admin. Es el peor caso y donde más se nota un servidor mal afinado, porque ahí WordPress tiene que ejecutarse entero.
Si el TTFB ya es bueno y tu web aun así va lenta, el problema no está en el servidor: mira por qué un TTFB alto no siempre es culpa del hosting o el peso de la página.
El orden que recomendamos
La regla es sencilla: primero lo que evita trabajo, después lo que hace el trabajo más rápido. Servir una página ya preparada siempre gana a ejecutar PHP más deprisa.
| Orden | Pieza | Qué consigues |
|---|---|---|
| 1 | Caché de página | Que la mayoría de visitas no ejecuten WordPress |
| 2 | PHP bien dimensionado | Que lo que sí se ejecuta no agote la memoria |
| 3 | Caché de objetos (Redis) | Que WordPress no repita las mismas consultas |
| 4 | Base de datos | Que las consultas que quedan sean ligeras |
| 5 | Tareas programadas | Que nada pesado se dispare en mitad de una visita |
| 6 | Copias y vigilancia | Que si algo se rompe, puedas volver |
1. Caché de página: lo que más pesa
Una web WordPress sin caché de página ejecuta PHP y consulta la base de datos en cada visita, aunque la página sea idéntica para todos. Con caché de página, el servidor guarda el resultado ya montado y lo entrega sin despertar a WordPress.
Hay dos formas de hacerlo y conviene entender la diferencia:
- Caché a nivel de servidor (LSCache en LiteSpeed y OpenLiteSpeed, FastCGI Cache en Nginx): la página se entrega sin cargar PHP. Es la más eficaz.
- Caché a nivel de plugin (WP Super Cache, W3 Total Cache, WP Rocket): WordPress arranca primero y después decide si sirve la copia. Funciona, pero hace más trabajo por visita.
Si tu servidor lleva LiteSpeed u OpenLiteSpeed, usa el plugin de LSCache: es el que conecta WordPress con la caché del servidor. Cómo funciona por dentro lo explicamos en LiteSpeed y LSCache para WordPress.
Lo que hay que configurar siempre, no solo activar:
- Excluir lo privado. El carrito, el pago y la cuenta de cliente de WooCommerce no se cachean, y tampoco las páginas que cambian por usuario. Un plugin bien configurado ya lo trae por defecto, pero compruébalo.
- Purgar al publicar. Cuando editas una entrada, la caché de esa página y de los listados donde sale tiene que renovarse. Si no, tus visitantes ven la versión vieja.
- Calentar la caché tras una limpieza. Después de purgar todo, la primera visita a cada página es lenta. En webs grandes merece la pena precargar las páginas más visitadas.
Cómo comprobarlo: mira las cabeceras de la respuesta. Con LSCache, x-litespeed-cache: hit indica que esa visita salió de la caché; miss indica que WordPress tuvo que trabajar.
curl -sI https://tudominio.com/ | grep -i "x-litespeed-cache"Si siempre sale miss, la caché no está funcionando, y no merece la pena seguir afinando otras piezas hasta arreglarlo.
2. PHP: versión, memoria y procesos
Aquí se tocan tres cosas.
La versión. Usa una versión de PHP que aún reciba parches de seguridad. Antes de subir, comprueba que tu tema y tus plugins son compatibles; la forma de verlo está en cómo comprobar la versión de PHP de WordPress.
OPcache. Guarda el código PHP ya compilado para no recompilarlo en cada petición. Casi siempre viene activado, pero con valores justos. Una configuración razonable para WordPress es:
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.revalidate_freq=60El número de procesos de PHP. Es el ajuste que más errores provoca cuando se deja de fábrica. Cada proceso de PHP consume memoria mientras atiende una visita. Si permites demasiados, el servidor se queda sin RAM y empieza a usar disco (swap) o a matar procesos. Si permites muy pocos, las visitas hacen cola y ves errores 502 o 504.
El cálculo básico:
- Mide cuánta memoria usa de media un proceso de PHP de tu web (con
psotopmientras hay tráfico). - Resta de la RAM total lo que necesitan el sistema, la base de datos y Redis.
- Divide lo que queda entre el consumo medio de un proceso.
El resultado es tu techo de procesos simultáneos. Una tienda WooCommerce con muchos plugins gasta bastante más por proceso que un blog sencillo, así que no copies el número de otra web. Los detalles de los parámetros están en PHP-FPM en VPS; con LiteSpeed el concepto es el mismo aunque el ajuste se llame distinto.
Cómo comprobarlo: durante un pico de tráfico, el servidor no debería usar swap y los registros no deberían mostrar que se alcanza el límite de procesos.
3. Redis: que WordPress no repita consultas
Aunque una página no esté en la caché de página (porque es privada o porque la caché está fría), WordPress hace muchas consultas repetidas a la base de datos: opciones, menús, datos de productos. Una caché de objetos guarda esos resultados en memoria y evita repetirlas. Redis es la opción habitual.
Donde más se nota es en lo que no se puede cachear como página: el panel de administración, el carrito y las tiendas con muchos productos. En un blog que casi todo lo sirve desde la caché de página, la ganancia es menor.
Tres cosas que se olvidan:
- Ponle un límite de memoria, y que se vacíe lo más antiguo cuando se llene. Si no, Redis crece hasta ocupar la RAM que necesitaba PHP.
maxmemory 256mb
maxmemory-policy allkeys-lru- Un prefijo propio por web si el servidor aloja varias, para que no se mezclen las cachés.
- Que no sea accesible desde fuera. Redis debe escuchar solo en local. Un Redis abierto a internet es un incidente de seguridad esperando a ocurrir.
Más detalle en Redis en VPS y, para la comparación entre tipos de caché, en caché en VPS.
Cómo comprobarlo: el plugin de Redis muestra el porcentaje de aciertos. Si está muy bajo tras unas horas de uso, algo no está bien configurado.
4. Base de datos: dos frentes
El servidor de la base de datos. El ajuste que más pesa es la memoria que MariaDB o MySQL dedican a guardar tablas e índices (innodb_buffer_pool_size). Si la base de datos cabe entera en esa memoria, las lecturas no tocan el disco. Cuánto asignar depende de qué más corre en la misma máquina: si comparte servidor con PHP y Redis, no puedes darle casi toda la RAM. La guía MySQL en VPS explica cómo calcularlo.
El contenido de la base de datos. Aquí el problema suele estar en WordPress, no en el servidor:
- Datos de carga automática (autoload) inflados. WordPress los lee en cada petición. Si un plugin dejó megas ahí, todas las páginas pagan ese coste. Lo explicamos en autoload de WordPress.
- Revisiones, transitorios caducados y restos de plugins desinstalados. Limpiarlos es seguro con una copia previa; el procedimiento está en cómo optimizar la base de datos de WordPress.
Un servidor perfectamente afinado no compensa una base de datos con tres megas de autoload basura.
5. Tareas programadas: sácalas de las visitas
Por defecto, WordPress ejecuta sus tareas programadas (publicar entradas, enviar correos, limpiezas de plugins) cuando alguien visita la web. Es lo que se llama WP-Cron. En una web con poco tráfico las tareas llegan tarde, y en una con mucho pueden coincidir con visitas y volverlas lentas.
La solución estándar es desactivar ese disparo y lanzar las tareas desde el sistema, cada pocos minutos.
En wp-config.php:
define('DISABLE_WP_CRON', true);Y en el cron del sistema, con WP-CLI instalado:
*/5 * * * * cd /ruta/de/tu/wordpress && wp cron event run --due-now >/dev/null 2>&1Es un cambio pequeño con un efecto doble: las visitas dejan de cargar con tareas ajenas y las tareas programadas salen a su hora.
6. Copias y vigilancia: la parte que no se ve
Un servidor rápido que no puedes restaurar no es un servidor optimizado. Lo mínimo:
- Copia diaria fuera del servidor. Una copia en la misma máquina se pierde con la máquina.
- Copia antes de cada actualización importante, para poder volver atrás si un plugin rompe algo.
- Restaurar de vez en cuando, de verdad. Una copia que nunca has probado a restaurar es una suposición.
- Vigilar desde fuera. Un aviso cuando la web deje de responder, no cuando te lo diga un cliente.
El método completo está en backups en VPS. Y la seguridad del servidor y de WordPress, que también forma parte de dejarlo bien montado, en seguridad de WordPress en VPS.
Qué no hace falta tocar
Para no perder tiempo, estas cosas suelen dar muy poco:
- Reescribir ajustes avanzados del sistema operativo sin una causa medida.
- Instalar tres plugins de caché a la vez. Se pisan entre sí. Uno solo, bien configurado.
- Cambiar de servidor web "porque es más rápido" cuando la caché de página ni está activa.
- Comprar más RAM sin mirar antes cuánta usas. Si tu web usa la mitad, más RAM no cambia nada.
Cuándo parar y cuándo cambiar de tamaño
Optimizar tiene un límite. Si has hecho todo lo anterior y, con el servidor bajo carga normal, sigues viendo swap, procesos de PHP al tope o la base de datos pidiendo más memoria de la que hay, el servidor se ha quedado pequeño para tu web. Ahí lo correcto es subir de tamaño y no seguir apretando. Para decidir cuánto, la guía de dimensionamiento de recursos en VPS te da el método.
Hacerlo tú o que lo hagan por ti
Todo esto se puede hacer a mano, y aprenderlo merece la pena. Pero no es un trabajo de una tarde: hay que mantenerlo cuando suben las versiones de PHP, cuando cambia tu web y cuando un plugin nuevo rompe una suposición.
Si prefieres no encargarte, un VPS para WordPress administrado trae esta configuración ya montada y la mantenemos nosotros. Si ya tienes tu servidor en otro proveedor, podemos administrarlo igualmente. Y si tienes dudas sobre qué opción te encaja, la diferencia entre un VPS administrado y uno que no lo es está explicada con calma.
Preguntas frecuentes
¿Qué es lo primero que debo optimizar en un VPS con WordPress?
La caché de página. Es lo que más trabajo evita al servidor. Antes de tocar PHP o la base de datos, comprueba que las visitas públicas salen de la caché.
¿Hace falta Redis en todas las webs?
No. Se nota sobre todo en tiendas, webs con zona privada y paneles de administración pesados. En un blog que sirve casi todo desde la caché de página, la mejora es pequeña.
¿Cuántos procesos de PHP debo configurar?
Depende de cuánta memoria use cada uno en tu web y de la RAM que te quede tras el sistema, la base de datos y Redis. Mide tu consumo real y calcula el techo; no copies el número de otra web.
¿Es seguro desactivar WP-Cron?
Sí, siempre que lo sustituyas por una tarea del sistema. Si lo desactivas sin más, las tareas programadas dejan de ejecutarse.
¿Cómo sé si el servidor se me ha quedado pequeño?
Si bajo carga normal ves uso de swap, los procesos de PHP llegan siempre a su límite o la base de datos necesita más memoria de la que tiene, optimizar ya no basta y toca subir de tamaño.
Guías relacionadas
- Mejor VPS para WordPress: guía de configuración
- Cómo optimizar el rendimiento de tu WordPress
- Cómo optimizar el rendimiento y la RAM de tu VPS
- TTFB alto en WordPress: cómo bajarlo
¿Quieres que lo hagamos por ti?
En Avantys gestionamos tu web, hosting y crecimiento digital de punta a punta. Tú a lo importante.
