LiteSpeed vs Nginx vs Apache: ¿cuál es mejor para hosting?

La respuesta corta

Si necesitas decidir hoy, este es el resumen honesto:

• WordPress, WooCommerce o cualquier CMS en PHP, sobre hosting compartido: LiteSpeed. Combina compatibilidad total con Apache y una caché dentro del propio servidor web.
• Contenido estático, proxy inverso, balanceo, aplicaciones Node.js o Python: Nginx. Es el estándar del sector para ese trabajo y su configuración es explícita y predecible.
• Configuraciones heredadas, módulos poco comunes, requisitos de compatibilidad estricta: Apache. Su catálogo de módulos no tiene rival y prácticamente cualquier problema ya está documentado.
• Un VPS pequeño con una sola aplicación y presupuesto cero de licencias: Nginx u OpenLiteSpeed.

El resto del artículo explica por qué.

De dónde viene cada uno

El origen de cada servidor explica sus decisiones de diseño mejor que cualquier benchmark.

Apache HTTP Server (abril de 1995). Nació como sucesor de NCSA HTTPd y fue el servidor que sostuvo la web durante dos décadas. Lo desarrolla la Apache Software Foundation bajo licencia Apache 2.0. Su prioridad histórica fue la flexibilidad: cualquier configuración es posible mediante módulos, y la configuración se puede delegar por carpeta con archivos .htaccess. Esa flexibilidad tuvo un costo en consumo de recursos que se volvió evidente cuando la web creció.

LiteSpeed Web Server (1 de julio de 2003). Creado por George Wang y desarrollado por LiteSpeed Technologies, escrito en C y C++. Su planteamiento fue directo: mantener la compatibilidad con Apache —.htaccess, mod_rewrite, mod_security— pero reemplazar por dentro el modelo de procesos por uno basado en eventos. Es software propietario con una variante libre, OpenLiteSpeed, bajo licencia GPLv3.

Nginx (público en 2004). Creado por Igor Sysoev para resolver el problema C10k: cómo atender más de 10.000 conexiones simultáneas en una sola máquina. Su arquitectura es asíncrona y basada en eventos desde el primer día, y no intentó ser compatible con Apache. Es software libre bajo licencia BSD de dos cláusulas; F5 compró Nginx, Inc. en marzo de 2019 por 670 millones de dólares y mantiene además una versión comercial, NGINX Plus.

Cuánto se usa cada uno hoy

Según W3Techs, al 6 de septiembre de 2026 el reparto entre los sitios cuyo servidor web se puede identificar es:

Dos advertencias para leer bien esta tabla. La primera: mide sitios, no tráfico ni calidad; una decisión de un gran proveedor de hosting mueve millones de sitios de golpe. La segunda: Cloudflare Server no es comparable con los demás, porque es la capa que responde delante de sitios que por detrás usan cualquiera de los otros tres.

Modelo de concurrencia: qué pasa cuando llegan muchos visitantes

Aquí está la diferencia arquitectónica de fondo, y se entiende con un ejemplo antes que con la regla.

Piensa en una ventanilla de atención. En el modelo prefork de Apache, cada persona que llega recibe un funcionario dedicado en exclusiva, que se queda con ella todo el rato, incluso mientras rellena el formulario. Con 500 personas hacen falta 500 funcionarios, y cada uno ocupa memoria aunque esté esperando.

En el modelo por eventos de Nginx y LiteSpeed, unos pocos funcionarios atienden a todos, pasando de uno a otro solo cuando alguien necesita algo. Como en una conexión web la mayor parte del tiempo se pasa esperando, esos pocos procesos rinden por muchos.

Matiz importante y poco dicho: Apache dejó de ser el pesado de la historia hace años. Con el MPM event y PHP-FPM, su comportamiento bajo carga se acerca bastante al de Nginx. El problema es que muchos servidores de hosting compartido siguen configurados con prefork y mod_php por compatibilidad, y ahí la diferencia sí se nota. Cuántos visitantes simultáneos aguanta realmente un plan es una pregunta con más variables que el servidor web; la desarrollamos en cuánto tráfico soporta un hosting.

.htaccess: la diferencia práctica más importante

Un archivo .htaccess es un archivo de configuración que se coloca dentro de una carpeta del sitio y que el servidor lee en cada petición, permitiendo cambiar reglas sin tocar la configuración global ni reiniciar nada.

• Apache: lo lee. Es su invento.
• LiteSpeed Enterprise: lo lee, en tiempo real y con la misma sintaxis.
• OpenLiteSpeed: no lo lee. Hay que traducir las reglas a su configuración.
• Nginx: no lo lee, por diseño. Toda la configuración vive en archivos centrales y requiere recargar el servicio.

Por qué esto decide migraciones enteras: WordPress escribe sus reglas de enlaces permanentes en .htaccess. Los plugins de seguridad escriben ahí. Las redirecciones 301 de una migración se ponen ahí. Pasar un sitio de Apache a LiteSpeed no requiere tocar nada; pasarlo a Nginx obliga a reescribir esas reglas a mano.

La otra cara, y hay que decirla: la ausencia de .htaccess en Nginx es también una ventaja de rendimiento y seguridad. Apache tiene que buscar y leer esos archivos en cada carpeta y en cada petición, y en hosting compartido cualquier usuario puede meter ahí una regla que rompa su propio sitio. La configuración centralizada de Nginx es más rápida y más difícil de estropear.

Cómo ejecuta PHP cada uno

Un servidor web no ejecuta PHP: se lo entrega a otro programa. Cómo lo hace cambia el rendimiento.

• Apache con mod_php: el intérprete de PHP va incrustado en cada proceso de Apache. Sencillo de configurar, pero cada proceso ocupa memoria de PHP aunque solo esté sirviendo una imagen. Es el modelo más antiguo y el más pesado.
• Apache o Nginx con PHP-FPM: PHP corre como un servicio aparte con su propio grupo de procesos, y el servidor web le pasa las peticiones dinámicas. Es el estándar moderno y funciona bien en ambos. Cuando ese grupo de procesos se satura o tarda, aparecen los errores 502 Bad Gateway.
• LiteSpeed con LSAPI: una interfaz propia entre el servidor y PHP, diseñada para reducir la sobrecarga de cada llamada, con procesos persistentes por cuenta de usuario.

Para un sitio corporativo con tráfico moderado, las tres opciones sirven. La diferencia se acumula cuando hay muchas peticiones dinámicas por segundo, que es el escenario de una tienda en campaña.

Caché: nativa contra montada aparte

Este es el punto donde LiteSpeed se separa más claramente del resto, y también donde más marketing hay.

• LiteSpeed incluye LSCache, una caché de páginas dentro del propio servidor web, con plugins oficiales para WordPress, WooCommerce, Magento y otros CMS. Sirve la página ya generada sin arrancar PHP ni consultar MySQL.
• Nginx tiene proxy_cache y fastcgi_cache, que funcionan muy bien pero hay que configurarlos a mano, incluida la política de invalidación: decidir cuándo una copia guardada deja de ser válida.
• Apache tiene mod_cache, menos usado en la práctica; lo habitual es delegar la caché a un plugin de PHP como W3 Total Cache o a un servicio delante, como Varnish.

La diferencia real no es "tener caché o no": es quién la configura y quién la invalida. Con LSCache, publicar una entrada en WordPress purga automáticamente las páginas afectadas. Con fastcgi_cache en Nginx, esa lógica hay que construirla. En hosting compartido, donde el cliente no administra el servidor, esa automatización es la diferencia entre tener caché y tener caché mal configurada. El detalle de cómo funciona está en qué es LiteSpeed y por qué importa en tu hosting.

Tabla comparativa completa

Cuándo elegir cada uno

Elige LiteSpeed si tu sitio corre sobre WordPress, WooCommerce, PrestaShop o cualquier CMS en PHP y quieres caché que se invalide sola sin que tú la administres. Es la razón por la que domina en hosting compartido: da el rendimiento del modelo por eventos sin obligar a reescribir la configuración heredada de Apache.

Elige Nginx si vas a montar un VPS para servir una aplicación Node.js, Python o Go, si necesitas proxy inverso o balanceo de carga, o si tu sitio es mayoritariamente estático. También si tu equipo prefiere configuración explícita en archivos versionados en Git frente a la dispersión de los .htaccess.

Elige Apache si dependes de un módulo que solo existe ahí, si mantienes una aplicación antigua que asume su comportamiento, o si tu equipo ya lo domina y el sitio no tiene problemas de carga. Un Apache con MPM event y PHP-FPM bien configurado rinde mucho mejor de lo que sugiere su reputación.

Y una consideración que suele pesar más que las tres anteriores: en hosting compartido tú no eliges el servidor web, lo elige el proveedor. Lo que sí puedes hacer es verificar cuál usa antes de contratar, ejecutando curl -I https://sudominio.com y mirando la cabecera Server. Junto con el tipo de disco —comparado en NVMe vs SSD para hosting web— es uno de los dos datos técnicos que más dicen sobre un plan.