Use caché de objeto y de página (Redis, Varnish o plugin). Ajuste PHP-FPM y MySQL. Para tráfico alto separe la BD y use VPS mayor o dedicado. Considere WordPress gestionado o headless si el equipo prefiere no gestionar servidores.
Caché
- Caché de objeto: Backend Redis o Memcached para object cache de WordPress (sesiones, resultados de queries). Reduce mucho la carga en la BD.
- Caché de página: Caché de página completa (Varnish, Nginx FastCGI cache o plugin como WP Super Cache, W3 Total Cache) para que visitantes repetidos reciban HTML estático. Invalide al actualizar post.
- CDN: Descargue activos estáticos (imágenes, CSS, JS) a una CDN.
PHP y MySQL
- PHP-FPM: Ajuste pm.max_children y procesos pm para su RAM. Use OPcache; mantenga versión de PHP soportada (ej. 8.x).
- MySQL: Buffer pool InnoDB, query cache (si disponible), connection pool. Indexe tablas; evite queries pesadas en tablas grandes.
- BD separada: Cuando el tráfico crezca, mueva MySQL a su propio servidor.
Cuándo pasar a dedicado
- Límites del VPS: CPU, memoria o I/O consistentemente altos; necesidad de más control o rendimiento predecible.
- Dedicado: Servidor completo para WordPress y (opcionalmente) servidor de BD separado. Sin vecinos ruidosos; mejor para tráfico alto o plugins complejos.
- WordPress gestionado: El proveedor gestiona actualizaciones, seguridad y escalado.
- Headless: Use WordPress como CMS (API) y sirva el front desde sitio estático o app separada. Escala mejor para tráfico de lectura.
Resumen
Caché a nivel de objeto y página; ajuste PHP-FPM y MySQL; separe la BD cuando haga falta. Pase a dedicado o WordPress gestionado para tráfico alto o menos ops.
