Optimizar WordPress: las causas reales de una web lenta y cómo resolverlas desde el servidor
La mayoría de los artículos sobre WordPress lento te mandan a instalar WP Rocket o a comprimir imágenes. No está mal, pero es atacar los síntomas desde el lado equivocado. Si el servidor donde está alojada tu web es lento, ningún plugin de caché va a compensarlo del todo. El rendimiento de WordPress empieza en la infraestructura.
Dónde se pierde realmente el tiempo al cargar WordPress
Una petición a WordPress recorre varias capas antes de devolver HTML al navegador. El servidor web (Apache o Nginx) recibe la petición, la pasa al intérprete PHP, PHP procesa WordPress, WordPress consulta MySQL, MySQL devuelve datos, PHP genera el HTML y el servidor lo envía. Cada una de esas capas tiene su propio cuello de botella potencial.
El tiempo hasta el primer byte (TTFB) mide exactamente eso: cuánto tarda el servidor en empezar a enviar la respuesta. Un TTFB por encima de 200ms en una instalación WordPress básica indica un problema en la capa del servidor, no en el frontend.
PHP-FPM y por qué la versión de PHP importa más de lo que parece
PHP-FPM (FastCGI Process Manager) es el modo de ejecución de PHP que usan los servidores modernos. A diferencia del módulo mod_php de Apache, PHP-FPM mantiene procesos PHP persistentes que atienden peticiones sin el overhead de arrancar un nuevo proceso por cada visita.
La versión de PHP tiene un impacto directo medible. PHP 8.4, que incluimos en todos nuestros planes de hosting web, es entre un 20% y un 40% más rápido que PHP 7.4 en benchmarks de WordPress, según mediciones de Kinsta y WP Engine. El motivo está en el JIT compiler (compilador Just-In-Time) introducido en PHP 8.0 y mejorado en cada versión posterior, que compila fragmentos de código frecuentemente ejecutados a código máquina nativo en tiempo de ejecución.
OPcache: el acelerador que viene incluido pero hay que configurar bien
OPcache almacena en memoria el bytecode compilado de los archivos PHP. Sin OPcache, cada petición hace que PHP lea el archivo del disco, lo parsee y lo compile. Con OPcache activo, ese trabajo solo se hace una vez y el resultado se guarda en RAM para todas las peticiones siguientes.
La configuración por defecto de OPcache es conservadora. Para WordPress en producción los parámetros más relevantes son opcache.memory_consumption (mínimo 128MB para una instalación con plugins), opcache.max_accelerated_files (al menos 10000) y opcache.validate_timestamps=0 en producción para eliminar el check de si el archivo cambió en cada petición.
El impacto del almacenamiento NVMe en el rendimiento de WordPress
WordPress hace muchas operaciones de lectura de archivos: cargar el núcleo, cargar plugins, leer themes, acceder a archivos de caché. En almacenamiento HDD tradicional cada operación de lectura aleatoria cuesta entre 5 y 10ms. En SSD SATA baja a 0.1ms. En NVMe, que es lo que usamos en ISPACTIVO, cae a menos de 0.05ms.
En términos prácticos, una instalación WordPress con 30 plugins activos hace entre 200 y 500 operaciones de I/O por petición sin caché de objeto. La diferencia entre HDD y NVMe en ese escenario puede ser de varios cientos de milisegundos de TTFB, independientemente de todo lo demás.
Caché de objeto con Redis o Memcached
La caché de página (lo que hacen WP Rocket o W3 Total Cache) guarda el HTML generado para no ejecutar PHP en visitas repetidas. Pero WordPress también hace consultas a la base de datos dentro de la misma ejecución, por ejemplo para cargar menús, widgets o configuraciones que se consultan varias veces.
Redis o Memcached como caché de objeto de WordPress guardan en RAM los resultados de esas consultas durante la ejecución de PHP. Con el plugin WP Redis o Redis Object Cache activado y conectado a un servidor Redis local, las consultas repetidas a la base de datos dentro de la misma petición se sirven desde memoria en microsegundos en lugar de ir a MySQL.
HTTP/3 y QUIC: por qué el protocolo de red cambia el rendimiento en móvil
HTTP/3, disponible en todos nuestros servidores, usa QUIC en lugar de TCP como protocolo de transporte. La diferencia clave para WordPress es el comportamiento ante pérdida de paquetes. Con HTTP/2 sobre TCP, si se pierde un paquete toda la conexión se detiene hasta recuperarlo (head-of-line blocking). Con QUIC, cada stream es independiente: la pérdida de un paquete de una imagen no bloquea la carga del CSS ni del JavaScript.
En redes móviles con pérdidas del 1-3% de paquetes (normal en 4G con señal media), HTTP/3 reduce los tiempos de carga percibidos entre un 10% y un 30% respecto a HTTP/2. En redes estables la diferencia es menor, pero el handshake de QUIC también es más rápido (0-RTT en conexiones conocidas) lo que reduce la latencia inicial.
Balanceo de carga y alta disponibilidad
Más allá del rendimiento por petición, la arquitectura de red determina qué pasa cuando la carga aumenta. En nuestros servidores usamos balanceo de carga activo con redundancia, de forma que el tráfico se distribuye entre múltiples instancias y ningún servidor individual se convierte en el cuello de botella. Cuando el tráfico de tu web crece, el sistema escala sin que necesites migrar a otra infraestructura.
El resultado de combinar PHP 8.4, OPcache bien configurado, NVMe, Redis y HTTP/3 es que una instalación WordPress estándar puede servir cientos de peticiones por segundo desde un solo plan de hosting compartido, algo imposible hace cinco años con las stacks tecnológicas que aún usan muchos proveedores.
