En el mundo WordPress, la conversación suele girar siempre en torno a lo mismo: cambiar de tema, probar otro constructor visual, instalar “el mejor” plugin de caché o limpiar la base de datos. Sin embargo, muchas veces el verdadero cuello de botella no está en el código de la web, sino en algo mucho menos vistoso: la configuración del servidor.
En este caso real, una serie de ajustes a nivel de PHP, base de datos y sistema consiguieron reducir el tiempo de carga de una instalación de WordPress en torno a un 60 %, sin tocar ni el tema ni los plugins. El cambio no fue mágico, fue técnico… pero muy efectivo.
La mayoría de administradores pasa horas comparando temas “rápidos” o plugins de optimización, mientras da por hecho que el servidor “ya está bien”. Aquí ocurrió justo lo contrario: el gran salto vino de revisar cómo ejecutaba PHP, dónde vivía MySQL y cómo usaba la memoria el motor de base de datos.
Los números del caso antes de los cambios eran claros:
Después de los ajustes, sin cambiar el número de consultas, las métricas quedaron así:
La web “se sentía” mucho más rápida, pero lo importante es que la mejora venía de la capa que menos miradas recibe: el servidor.
El primer gran bloque de mejora vino de revisar la configuración de PHP-FPM y, sobre todo, de OPcache. Este módulo de PHP guarda en memoria los scripts ya compilados para evitar que el intérprete tenga que analizarlos y compilarlos en cada petición.
El problema no era que OPcache no existiera, sino que estaba mal dimensionado:
opcache.memory_consumption seguía en 64M, un valor típico de hace años que se queda corto para sitios con muchos plugins.opcache.max_accelerated_files tampoco reflejaba el número real de ficheros PHP cargados.Tras aumentar la memoria de OPcache a 256M y ajustar el número de ficheros acelerados, el TTFB bajó de media de 480 ms a unos 290 ms. La lógica es sencilla: si el opcode cache puede mantener en memoria la mayoría del código PHP, el servidor responde antes y reduce el trabajo por petición.
No es un truco nuevo, pero muchas instalaciones heredadas siguen arrastrando valores por defecto pensados para proyectos mucho más pequeños.
Otro error muy habitual es pensar que, para acelerar la base de datos, basta con darle más CPU y más RAM. En este caso se comprobó que la mejora no venía de sobredimensionar el servidor, sino de acercarlo a la aplicación.
La base de datos se encontraba en un nodo con más recursos, sí, pero en otra región o segmento de red con más latencia. Al devolverla a la misma red local que el servidor web, el tiempo de respuesta de las consultas mejoró:
En WordPress, donde una página de producto en WooCommerce puede disparar entre 60 y 100 consultas, esos milisegundos se suman como una bola de nieve. No es raro que un sitio “se sienta cansado” sin estar técnicamente caído: simplemente la suma de latencias hace que todo vaya a trompicones.
La lección es clara: mover MySQL a una máquina “más potente” pero con peor latencia puede ser un paso atrás. La proximidad de red importa tanto como el número de núcleos.
El tercer pilar del cambio fue revisar el InnoDB Buffer Pool, la caché de datos y índices de InnoDB. Durante años quedó en un “valor razonable” que nadie había vuelto a revisitar, pese a que el volumen de datos y tráfico había crecido.
Tras dimensionarlo para que cupiera aproximadamente un 80 % de los datos activos, las lecturas en disco se redujeron drásticamente y:
En la práctica, esto significa que muchas consultas se resuelven directamente desde memoria, sin tener que golpear el disco de forma constante. En entornos con WordPress y WooCommerce, donde se repiten consultas similares una y otra vez, el impacto es inmediato.
Sobre esa base, hay una serie de ajustes adicionales que complementan la mejora y que muchos administradores pasan por alto:
memcache) evita escribir sesiones en disco y reduce la contención en sistemas con muchas peticiones concurrentes.wp-cron.php suele ofrecer un comportamiento más predecible y menos penalizaciones de rendimiento en sitios con tráfico irregular.tmpfs (RAM) si el servidor tiene memoria de sobra. Usar RAM como almacenamiento temporal reduce latencias de disco para operaciones intensivas en ficheros temporales.Todo esto, combinado, forma un conjunto de pequeñas optimizaciones que, sumadas, pueden superar con creces lo que se logra añadiendo otro plugin de caché “milagroso”.
En muchas conversaciones técnicas, los nombres que salen primero son siempre los mismos: LiteSpeed, WP Rocket, plugins de “performance” con decenas de opciones y paneles visuales. Sin embargo, en un servidor bien configurado:
la necesidad de soluciones agresivas disminuye muchísimo. No es que sean inútiles, pero sí es cierto que no pueden compensar un servidor mal ajustado.
La metáfora es sencilla: un frontend muy optimizado sobre un backend estrangulado es como montar un motor de coche deportivo sobre una canoa. Puede sonar muy bien, pero no va a ningún sitio.
¿Qué mejora más el rendimiento: un plugin de caché o ajustar OPcache y MySQL?
Ambos ayudan, pero si el servidor está mal configurado, el plugin de caché solo maquilla el problema. Ajustar OPcache, reducir la latencia hacia la base de datos y dimensionar bien el InnoDB Buffer Pool suele ofrecer mejoras más profundas y estables.
¿Tiene sentido usar Redis o memcached si mi sitio es pequeño?
Sí, siempre que el coste de gestión no sea un problema. Incluso en sitios pequeños, una caché de objetos reduce la carga de la base de datos y mejora la estabilidad cuando hay picos de tráfico. En entornos compartidos o muy sencillos quizá baste con APCu.
¿Es obligatorio mover WP-Cron a un cron del sistema?
No es obligatorio, pero en sitios con tráfico serio o tareas programadas críticas es muy recomendable. El cron interno de WordPress depende de visitas para dispararse; el cron del sistema es mucho más predecible.
¿Qué métricas debería vigilar para saber si mi servidor es el problema?
Como mínimo: TTFB, tiempo medio de consulta SQL, porcentaje de uso del buffer pool de InnoDB, carga de CPU de PHP-FPM, latencia entre el servidor web y la base de datos, y número de IOPS en disco. Si esas métricas están al límite, cambiar de tema o minificar más el CSS no resolverá el fondo del problema.
En definitiva, este caso deja una conclusión clara: las mayores ganancias de rendimiento en WordPress suelen estar en la configuración del servidor, no en el último plugin de moda. Ajustar bien esa capa es lo que marca la diferencia entre una web “cansada” y un sitio que responde con la agilidad que los usuarios esperan.
Referencias: Reddit
