En resumen
- Para la mayoría de los sitios PHP, la elección entre Nginx y Apache mueve el rendimiento menos que las capas que la rodean: PHP-FPM, OPcache y una caché de página completa.
- La verdadera diferencia arquitectónica es la concurrencia. El bucle de eventos de Nginx sostiene miles de conexiones inactivas de forma barata; el modelo de procesos/hilos de Apache usa más memoria con la misma carga.
- Ejecuta PHP mediante PHP-FPM en cualquiera de los dos servidores.
mod_phpata un intérprete de PHP a cada proceso de Apache y es el mayor error de rendimiento heredado. - «Nginx delante de Apache» es un patrón real, no una excusa: Nginx termina el TLS y sirve los archivos estáticos, Apache mantiene la compatibilidad con
.htaccesspara la aplicación.
Cada pocos meses alguien me pregunta si debería «cambiar a Nginx para que el sitio vaya más rápido», y la respuesta honesta suele ser no —no porque Nginx sea lento, sino porque el servidor web rara vez es donde se va su tiempo. He visto un sitio reducir su tiempo de respuesta a la mitad activando OPcache y una caché de página completa mientras seguía en el mismo Apache con el que empezó. El software del servidor nunca fue el cuello de botella.
Así que este no es un artículo de «quién gana», porque planteado así la pregunta apenas importa. Trata de dónde viene realmente el rendimiento de un servidor web, qué difiere de verdad entre Nginx y Apache y cómo elegir sin tratarlo como una decisión de marca.
La diferencia que es real: la concurrencia
Apache y Nginx manejan las conexiones con modelos fundamentalmente distintos, y este es el único lugar donde la elección tiene consecuencias reales de rendimiento.
Apache, en sus configuraciones habituales, mapea las conexiones a procesos o hilos. Bajo carga con muchos clientes lentos o inactivos —redes móviles, conexiones keep-alive, descargas largas— cada uno ocupa un worker, y el uso de memoria sube con la concurrencia. Nginx usa un bucle orientado a eventos: un pequeño conjunto fijo de procesos worker multiplexa miles de conexiones, y las inactivas cuestan casi nada. Por eso Nginx brilla como proxy inverso y con alta concurrencia, y por eso se volvió el predeterminado delante de APIs y CDNs.
Para un sitio que sirve a unos cientos de usuarios concurrentes, ambos son cómodamente rápidos. La diferencia aparece en la cola —alta concurrencia, muchas conexiones inactivas— no en la petición mediana.
La capa que importa más: cómo corre PHP
mod_php es el error heredado
El antiguo predeterminado de Apache incrusta un intérprete de PHP en cada proceso de Apache, así que cada uno carga la memoria de PHP incluso al servir un archivo estático. Ejecuta PHP mediante PHP-FPM en su lugar —un pool de workers de PHP separado y ajustable con el que tanto Apache como Nginx hablan por FastCGI. Este único cambio suele hacer más por el rendimiento que cambiar de servidor web.
Con PHP-FPM en su sitio, las palancas que de verdad mueven el rendimiento en su mayoría no son el servidor web en absoluto:
OPcache
Cachea el bytecode de PHP compilado en memoria. A menudo la mayor victoria individual, y con frecuencia desactivada.
Caché de página completa
Servir una respuesta HTML cacheada salta PHP y la base de datos por completo —la mayor victoria para sitios de contenido.
Caché de objetos
Redis o Memcached recortan consultas repetidas a la base en páginas dinámicas.
Ajuste del pool FPM
Dimensiona el número de workers a tu RAM para no quedarte corto ni hacer swap bajo carga.
Para un sitio WordPress en concreto, una caché de página completa (caché FastCGI en Nginx, o un plugin de caché como LiteSpeed, o una detrás de Varnish) es la diferencia entre reconstruir cada página desde PHP y la base de datos en cada acceso y servir un archivo estático en microsegundos. Esa decisión eclipsa la de Nginx contra Apache.
Dónde Apache aún se gana su sitio: .htaccess
Los archivos .htaccess por directorio de Apache son a la vez su superpoder de compatibilidad y un coste silencioso de rendimiento. Permiten que un plugin, un framework o un usuario de hosting compartido cambie reglas de reescritura y acceso sin tocar la configuración central —que es justo por lo que tanto del ecosistema WordPress y PHP heredado los da por hechos. El coste es que Apache comprueba la existencia de archivos .htaccess en cada petición a lo largo de la ruta. Nginx no tiene equivalente; sus reglas viven en una configuración central, lo que es más rápido pero implica que los cambios requieren un reload y acceso al servidor.
Si tu aplicación o tu hosting depende de .htaccess, esa dependencia es una razón real para mantener Apache en el stack, no un fracaso en modernizar.
Nginx delante de Apache: el híbrido pragmático
No tienes que elegir. Una forma común en producción pone Nginx en el borde y Apache detrás: Nginx termina el TLS, sirve los assets estáticos directamente y hace de proxy inverso de las peticiones dinámicas hacia Apache, que ejecuta la aplicación con su compatibilidad .htaccess intacta. Obtienes el manejo de conexiones y la velocidad de archivos estáticos de Nginx delante y la compatibilidad del ecosistema de Apache detrás. Muchos hostings WordPress gestionados ejecutan algo así sin anunciarlo.
Una forma práctica de elegir
Cambiar de servidor para arreglar la velocidad
Antes de cambiar de servidor web, confirma que OPcache, una caché de página completa y PHP-FPM están en su sitio. Suelen importar más.
Usar mod_php en 2026
Incrustar PHP en los procesos de Apache desperdicia memoria en cada petición. Pásate a PHP-FPM sea cual sea el servidor que mantengas.
Sin caché de página completa en un sitio de contenido
Reconstruir cada página desde PHP y la base en cada acceso es el cuello de botella evitable más común.
Ajustar la capa equivocada
Ajustar a mano directivas de workers mientras la base hace escaneos completos sin índice optimiza la parte que no era lenta.
La versión corta: elige Nginx cuando la carga es de alta concurrencia, orientada a proxy o basada en API, y cuando controlas la configuración del servidor. Mantén Apache cuando dependes de .htaccess, corres en hosting compartido o tu equipo ya lo opera bien. Luego gasta tu esfuerzo real en el cacheo, PHP-FPM y la base de datos —ahí están las victorias.
FAQ
- ¿Es Nginx más rápido que Apache?
- Para cargas de alta concurrencia y de proxy inverso, el modelo orientado a eventos de Nginx usa menos memoria y maneja las conexiones inactivas con más eficiencia. Para el tráfico típico, ambos son rápidos, y OPcache, una caché de página completa y PHP-FPM afectan al rendimiento real mucho más que la elección entre ellos.
- ¿Debo usar mod_php o PHP-FPM?
- PHP-FPM, en casi todos los casos. Ejecuta PHP en un pool de workers separado y ajustable que tanto Apache como Nginx usan por FastCGI, en lugar de incrustar un intérprete en cada proceso del servidor web. Pasar de
mod_phpa PHP-FPM suele mejorar el rendimiento más que cambiar de servidor web. - ¿Cuál es la mayor victoria de rendimiento para un sitio WordPress?
- Una caché de página completa. Servir una respuesta HTML cacheada salta PHP y la base de datos por completo, convirtiendo una construcción de página de varias consultas en una lectura de archivo estático. Después, OPcache y una caché de objetos con Redis son las siguientes mayores victorias —todas independientes de si usas Nginx o Apache.
- ¿Puedo ejecutar Nginx y Apache juntos?
- Sí, y es un patrón común. Nginx se sitúa en el borde para terminar el TLS y servir archivos estáticos, y luego hace de proxy inverso de las peticiones dinámicas hacia Apache, que ejecuta la aplicación y mantiene el soporte de
.htaccess. Obtienes el manejo de conexiones de Nginx con la compatibilidad de Apache.
Artículos relacionados
- Docker y WordPress: cómo los contenedores simplifican el desarrollo facilita comparar estas opciones de servidor en un stack reproducible.
- WordPress Bedrock con Docker en local y PHP puro en producción cubre la caché de página completa de LiteSpeed y el flujo de despliegue en hosting compartido real.
