Cómo optimizar WordPress en un VPS con KVM y OpenLiteSpeed

Tu sitio de WordPress es lento. Has probado todos los plugins de caché, optimizado imágenes hasta convertirlas prácticamente en arte abstracto y la página aún carga como si fuera 2005. El problema no es WordPress. Es lo que hay debajo.

El VPS que estás utilizando, la tecnología de virtualización que emplea, el servidor web que se encuentra delante de PHP: estos son los factores que realmente afectan la optimización de la velocidad de WordPress. La mayoría de las guías de optimización se saltan directamente los plugins. Vamos a empezar desde la base y avanzar hacia arriba.

Esta guía cubre la virtualización de VPS (especialmente KVM frente a OpenVZ), la selección de servidores web (Apache frente a NGINX frente a OpenLiteSpeed), y una configuración detallada de WordPress VPS que no requiere conocimientos avanzados de administración de sistemas. Examinaremos pruebas de rendimiento reales, no datos de marketing. Al final, sabrás exactamente qué stack le da a WordPress la mejor oportunidad de cargarse rápido bajo condiciones reales.

Aviso previo: si esperas un listado de «Los 10 mejores proveedores de hosting para WordPress», estás en el lugar equivocado. Hablamos de las decisiones de arquitectura que determinan si tu VPS es rápido o simplemente caro. La diferencia entre un VPS de WordPress bien configurado y uno mal configurado puede ser de un segundo completo en el tiempo de carga de la página. Para un sitio de ecommerce, ese segundo es la diferencia entre una venta y un abandono.

¿Qué es la virtualización VPS y por qué es importante?

La virtualización es la capa de software que divide un servidor físico en múltiples máquinas virtuales aisladas. Cada máquina virtual (VM) tiene su propio sistema operativo, su propia CPU y RAM asignadas y su propio espacio en disco. Desde dentro de la VM, se comporta como un servidor dedicado. Desde fuera, es uno de los muchos usuarios que comparten el mismo hardware.

La pieza de software que realiza esta división se llama «hipervisor». Se sitúa entre el hardware físico y las máquinas virtuales, asigna recursos y mantiene cada VM aislada de sus vecinas. Si una VM comienza a saturar su disco o a agotar la CPU, un hipervisor bien configurado evita que eso afecte a los demás.

El objetivo de la virtualización es la eficiencia de recursos. Ejecutar diez servidores físicos al 10 % de capacidad cada uno es un despilfarro. Ejecutar un servidor físico que aloje diez VM a casi plena capacidad es eficiencia. Para los proveedores de hosting, esto significa menores costes de infraestructura. Para ti, significa planes de VPS más baratos con un rendimiento sorprendentemente bueno, siempre que se utilice la tecnología de virtualización adecuada.

¿Por qué importa el tipo de virtualización para tu sitio WordPress? Porque controla directamente el rendimiento de la CPU, la velocidad de E/S en disco, el aislamiento de memoria y el rendimiento de red. Dos planes VPS con especificaciones idénticas sobre el papel, el mismo número de núcleos, la misma RAM, puede funcionar de forma diferente dependiendo de si utiliza KVM o OpenVZ por debajo. Para un sitio de WordPress que maneja tráfico real con consultas de base de datos en cada carga de página, esa diferencia se nota inmediatamente en los tiempos de carga de páginas y en la experiencia del usuario.

Tipos de Virtualización: KVM vs. OpenVZ

Dos tipos de virtualización dominan el mercado de hosting de VPS: KVM y OpenVZ. Adoptan enfoques fundamentalmente distintos para aislar las cargas de trabajo, y comprender la diferencia es fundamental cuando eliges un plan de hosting para WordPress.

KVM: Máquina Virtual Basada en Kernel

KVM es virtualización a nivel de hardware completo. Cada VM ejecuta su propio núcleo, su propio sistema operativo, completamente independiente de las demás VM en el servidor físico. Utiliza extensiones de hardware (Intel VT-x, AMD-V) integradas en CPUs modernas para crear entornos virtuales que operan a velocidades casi nativas.

La virtualización KVM se integró en el núcleo de Linux en 2007, lo que significa que no es una solución de terceros añadida. Es parte del propio sistema operativo. Todos los principales proveedores de nube — AWS, Google Cloud, DigitalOcean — utilizan KVM o un hipervisor derivado de él, y no es casualidad.

Aquí está lo que KVM te ofrece en la práctica:

Aislamiento completo. Tu VM está genuinamente aislada de las demás VM en el servidor. El proceso PHP descontrolado de un vecino no afectará a tus recursos. Cada VM recibe asignaciones dedicadas y garantizadas de CPU, RAM y E/S de disco. Sin sobreaprovisionamiento, sin recursos compartidos.

Flexibilidad del sistema operativo. Ejecuta Ubuntu, Debian, CentOS, Rocky Linux o incluso Windows. Tienes un núcleo real, por lo que cualquier función que admita el hardware está disponible.

Rendimiento casi nativo. La virtualización asistida por hardware implica que la penalización de rendimiento frente al bare metal es mínima. Operaciones limitadas por la CPU como la ejecución de PHP y las consultas de base de datos se ejecutan casi tan rápido como lo harían en un servidor dedicado.

Instantáneas y migración en vivo. Toma instantáneas de la VM antes de actualizaciones arriesgadas de WordPress o instalaciones de plugins. Los proveedores pueden migrar tu VM entre servidores físicos sin tiempo de inactividad durante el mantenimiento de hardware.

Asignación flexible de recursos. El hipervisor puede ajustar dinámicamente las asignaciones de CPU y memoria a las VM según la demanda, facilitando a los proveedores ofrecer planes escalables.

¿La desventaja? Cada VM ejecuta un sistema operativo completo, que consume más RAM de base que los enfoques basados en contenedores. Un VPS KVM que ejecute Ubuntu utiliza quizás entre 300 y 500 MB de RAM solo para el sistema operativo antes de que WordPress incluso se cargue. La complejidad de la configuración es mayor si estás construyendo desde cero sin plantillas.

OpenVZ: Virtualización Basada en Contenedores

OpenVZ toma el enfoque opuesto. Es virtualización a nivel de sistema operativo, más parecida a lo que hace Docker que a lo que hace KVM. Todos los contenedores comparten el núcleo de Linux del servidor. No hay un sistema operativo separado ejecutándose dentro de cada instancia de VPS, solo espacios de usuario aislados que se ejecutan sobre un núcleo compartido.

Esto hace que OpenVZ sea extremadamente ligero:

Sobrecarga mínima. Compartir el núcleo significa menos memoria desperdiciada y tiempos de arranque casi instantáneos. Los proveedores pueden alojar significativamente más contenedores en un solo servidor físico, razón por la que los planes de OpenVZ tienden a ser más baratos.

Provisionamiento rápido. Crear un nuevo contenedor tarda segundos, no minutos. Escalar horizontalmente mediante el despliegue de instancias adicionales es muy sencillo.

Mayor densidad. Debido a que los contenedores comparten el núcleo y utilizan menos memoria, un solo servidor físico puede alojar más instancias de OpenVZ que VM de KVM. Esto se traduce en menores costes por instancia.

Pero las contrapartidas se notan mucho cuando ejecutas un sitio WordPress en producción. Cada contenedor está bloqueado a la versión del núcleo del servidor: no puedes actualizarlo ni cambiarlo. No puedes ejecutar una distribución de sistema operativo diferente si el servidor está ejecutando un núcleo más antiguo. Y el aislamiento es fundamentalmente más débil: un vecino con mal comportamiento puede afectar al rendimiento de tu contenedor, porque todos comparten el mismo núcleo y, en la práctica, a menudo los mismos canales de E/S.

Para alojar varios sitios de WordPress no relacionados, el modelo de núcleo compartido de OpenVZ crea un riesgo real. Diferentes sitios pueden necesitar diferentes versiones de PHP, diferentes módulos del núcleo o bibliotecas del sistema incompatibles. En KVM, cada VM gestiona esto de manera independiente. En OpenVZ, estás limitado a lo que el servidor proporciona.

Benchmarks de rendimiento de KVM vs OpenVZ

La teoría es útil, pero los números cierran argumentos. Esto es lo que revelan las pruebas de rendimiento reales al comparar KVM con OpenVZ. La prueba comparó un plan KVM (un núcleo, 4 GB de RAM) con un plan OpenVZ (dos núcleos, 2 GB de RAM) para mostrar cómo el tipo de virtualización supera las especificaciones crudas.

Velocidad de CPU a través de Geekbench: El plan KVM de un solo núcleo ofreció un 35 % más de rendimiento en un solo núcleo que el plan OpenVZ de dos núcleos. Eso no es un error tipográfico. Un núcleo de KVM superó a dos núcleos de OpenVZ en cargas de trabajo monohilo. El rendimiento multinúcleo fue casi idéntico entre ellos, lo que significa que el único núcleo de KVM estaba haciendo el trabajo de dos núcleos de OpenVZ. La virtualización asistida por hardware proporciona a cada VM acceso directo a las extensiones de CPU que los contenedores OpenVZ no pueden utilizar completamente.

E/S de almacenamiento con FIO: KVM mostró una mejora del 67 % en las velocidades combinadas de lectura/escritura aleatoria. Esta es quizás la prueba de rendimiento más importante para WordPress. Cada carga de página activa múltiples consultas a MySQL, cada una requiriendo lecturas de disco. Cada carga de medios, cada actualización de plugin, cada copia de seguridad: todo es E/S de disco. Una mejora del 67 % aquí se traduce directamente en tiempos de respuesta de base de datos más rápidos y generación de páginas más rápida.

Ancho de banda de red a través de iPerf3: KVM ofreció un 66 % más de ancho de banda en subidas y descargas. Los planes KVM modernos normalmente vienen con conexiones de red de 300 Mbps en comparación con 100 Mbps en configuraciones OpenVZ heredadas. Para sitios que sirven páginas pesadas en medios o gestionan descargas de archivos, esta brecha es enorme.

En cada métrica — CPU, disco, red — KVM ganó, y no por pequeños márgenes. La brecha de rendimiento es lo suficientemente grande como para que un plan KVM de menor especificación supere constantemente a uno OpenVZ de mayor especificación. Cuando pagas por hosting VPS, la tecnología de virtualización importa más que las especificaciones impresas en la ficha del plan.

Mejor virtualización para WordPress

Elegir la mejor virtualización para un VPS de WordPress se reduce a tres factores: rendimiento bajo carga, escalabilidad cuando el tráfico crece, y aislamiento entre sitios.

KVM ofrece un rendimiento casi nativo con recursos verdaderamente dedicados. Tu sitio de WordPress no compite con vecinos por ciclos de CPU o ancho de banda de disco. Cuando llega un pico de tráfico — por ejemplo, una entrada de blog se hace viral o realizas una venta flash de WooCommerce — los recursos asignados a tu VM son tuyos. Sin excepciones. Sin degradación porque alguien más en el mismo servidor físico decidió ejecutar un trabajo cron intensivo en CPU.

La escalabilidad es sencilla con KVM. ¿Necesitas más RAM? ¿Más núcleos de CPU? El hipervisor ajusta las asignaciones sin reconstruir nada. Con OpenVZ, escalar significa trabajar dentro de las limitaciones de un núcleo compartido y los recursos que el proveedor no ha sobreaprovisionado ya a otros usuarios.

El aislamiento es donde KVM realmente se distancia de la competencia. Cada VM tiene su propio núcleo, su propia pila de red, su propio sistema de archivos completo. Si estás alojando múltiples instalaciones de WordPress con diferentes plugins, diferentes temas, y diferentes requisitos de versiones de PHP, KVM los mantiene realmente separados entre sí. Los contenedores OpenVZ comparten suficiente del sistema subyacente que los conflictos entre sitios no solo son teóricamente posibles, sino que ocurren con regularidad en servidores compartidos con alta carga.

Para cualquier sitio de WordPress que necesite rendimiento consistente bajo carga real, KVM es la elección correcta. OpenVZ puede funcionar para entornos de prueba o sitios de staging desechables donde el rendimiento no es crítico, pero para el hosting de WordPress en producción, no hay comparación.

Una consideración práctica: la mayoría de los proveedores de VPS han pasado a planes solo KVM en los últimos años precisamente porque las ventajas de rendimiento y aislamiento son tan claras. Si tu proveedor actual todavía ofrece OpenVZ, es señal de que trabajan con infraestructura más antigua. Al buscar un nuevo VPS de WordPress, confirma que la virtualización KVM es lo que obtienes antes de contratar.

Rendimiento de WordPress por tipo de sitio web

Para poner números reales detrás de la comparación de virtualización, aquí están los tiempos de carga total de GTmetrix para tres tipos diferentes de sitios de WordPress. La prueba fue deliberadamente desfavorable para KVM: el plan OpenVZ tenía 4 núcleos de CPU y 4 GB de RAM, mientras que el plan KVM tenía solo 1 núcleo y 4 GB de RAM. Todas las pruebas usaron el plugin de LiteSpeed Cache ejecutándose en OpenLiteSpeed.

Sitio personal: KVM fue un 10 % más rápido a pesar de tener tres núcleos de CPU menos. Los sitios personales tienden a ser ligeros, unas pocas páginas, algunas imágenes, consultas de base de datos mínimas. Aún así, la E/S de disco más rápida de KVM y el acceso a la CPU más eficiente hicieron una diferencia comprobable. Para un portafolio sencillo o un blog, cualquiera de las plataformas funcionaría, pero KVM sigue llevando ventaja.

Tienda de ecommerce: KVM entregó una mejora del 21 % en el tiempo de carga de página. Aquí es donde la brecha se vuelve seria. Las tiendas en línea construidas en WooCommerce golpean constantemente la base de datos: consultas de productos, sesiones de carrito, búsquedas de inventario, cálculos de precios dinámicos, llamadas a pasarelas de pago. La ventaja del 67 % en E/S de disco se traduce directamente en páginas de producto más rápidas y flujos de pago más rápidos. Para un sitio de ecommerce, operar en OpenVZ es perder dinero.

Sitio de agencia de diseño web: KVM fue un 5 % más rápido. Los sitios de portafolio de agencias suelen requerir mucho JavaScript y muchas solicitudes HTTP externas: mapas incrustados, feeds de redes sociales, scripts de analítica de terceros. El cuello de botella de rendimiento se desplaza parcialmente hacia el lado del cliente y las API externas, que es por qué la ventaja en el lado del servidor es menor. Pero KVM mantuvo la ventaja en todas las pruebas realizadas.

En conclusión: KVM supera a OpenVZ en todos los tipos de sitios de WordPress, con las mayores ventajas en sitios con uso intensivo de bases de datos como las tiendas de ecommerce. Incluso con una desventaja de 4:1 en núcleos, la mejor E/S y el acceso a CPU de KVM ofrecen cargas de página más rápidas en todos los casos.

Mejor servidor web para la velocidad de WordPress

La virtualización es la base. El servidor web es la siguiente capa y elegir el correcto es igualmente importante para la optimización de la velocidad de WordPress. Tres servidores web dominan el mundo del hosting de WordPress: Apache, NGINX y OpenLiteSpeed. Cada uno maneja el procesamiento de PHP, la entrega de archivos estáticos y la gestión de conexiones de maneras fundamentalmente diferentes.

Resumen del servidor web Apache

Apache es la vieja guardia de los servidores web. Ha impulsado la web desde 1995 y aún gestiona aproximadamente el 30 % de los sitios web a nivel global, lo que lo convierte en el segundo servidor web más popular después de NGINX. WordPress.org lista oficialmente a Apache como un entorno de servidor recomendado, y la mayoría de los proveedores de hosting compartido lo ejecutan por defecto.

La mayor ventaja de Apache es la accesibilidad. El archivo .htaccess te permite cambiar el comportamiento del servidor a nivel de directorio sin tocar la configuración principal del servidor. WordPress y cientos de sus plugins dependen de .htaccess para estructuras de enlaces permanentes, reglas de seguridad y directrices de almacenamiento en caché. Si alguna vez has pegado una regla de reescritura en una guía de WordPress, estabas configurando Apache.

El sistema de módulos es amplio y maduro. ¿Quieres añadir compresión gzip? Carga mod_deflate. ¿Necesitas reescritura de URL? mod_rewrite. ¿Soporte para HTTP/2? mod_http2. Los módulos pueden ser cargados y descargados dinámicamente en tiempo de ejecución, lo que significa que no necesitas recompilar el servidor para añadir funcionalidad.

La debilidad es la gestión de la concurrencia. El modelo prefork tradicional de Apache crea un proceso independiente para cada conexión entrante. Bajo tráfico pesado, esta arquitectura consume RAM de forma considerable. El MPM de eventos mejoró las cosas, pero Apache sigue siendo menos eficiente que las alternativas basadas en eventos al gestionar miles de conexiones simultáneas o entregar contenido estático como imágenes, CSS y archivos JavaScript.

Resumen del servidor web NGINX

NGINX superó a Apache como el servidor web más popular hace unos años. Ahora alimenta más del 34 % de los sitios web a nivel global y fue construido desde cero para resolver los problemas de concurrencia que arrastra Apache desde sus días de proceso por conexión.

La arquitectura es fundamentalmente diferente. NGINX utiliza un modelo asíncrono basado en eventos en el que un número reducido de procesos de trabajo gestiona miles de conexiones simultáneas. En lugar de dedicar un proceso o hilo a cada visitante, NGINX multiplexa conexiones entre los procesos de trabajo mediante E/S no bloqueante. El resultado es un consumo de memoria significativamente menor bajo tráfico intenso y un excelente rendimiento al servir archivos estáticos.

Para sitios de WordPress con alto tráfico, NGINX como proxy inverso frente a PHP-FPM es una configuración probada. Los activos estáticos se sirven extremadamente rápido sin tocar PHP en absoluto, mientras que las solicitudes dinámicas se transfieren al procesador PHP de forma eficiente.

El problema es la configuración. NGINX no admite archivos .htaccess. Cada cambio en la configuración del servidor requiere editar el archivo principal nginx.conf o archivos de configuración específicos del sitio y luego recargar el servicio. Para WordPress, esto significa que los plugins que dependen de reglas de reescritura .htaccess no funcionarán automáticamente. Necesitarás traducir manualmente esas reglas a la sintaxis de directiva de NGINX: una tarea que va de trivial a molesta, dependiendo del plugin. Algunos plugins populares de seguridad y SEO requieren un trabajo de configuración significativo de NGINX.

Resumen del servidor web OpenLiteSpeed

OpenLiteSpeed es la edición de código abierto del servidor web comercial LiteSpeed. Es como si Apache y NGINX tuvieran un hijo que heredara lo mejor de ambos y ninguno de sus defectos.

Utiliza una arquitectura basada en eventos similar a NGINX para un manejo eficiente de conexiones concurrentes. Pero lee los archivos .htaccess de Apache y las reglas de mod_rewrite de manera nativa. Obtienes rendimiento de clase NGINX sin los dolores de cabeza de la configuración al ejecutar WordPress. Los plugins que dependen de reglas .htaccess funcionan como corresponde, igual que lo harían en Apache.

La verdadera ventaja para el hosting de WordPress es el soporte integrado de LSCache. El plugin LiteSpeed Cache no es solo otro plugin de caché para WordPress compitiendo con WP Super Cache o W3 Total Cache. Se integra directamente con el servidor a un nivel que esos plugins no pueden tocar. Caché de páginas, caché de objetos, optimización de imágenes, minificación de CSS/JS, optimización de la base de datos, integración con CDN: todo gestionado a nivel del servidor en lugar de mediante soluciones alternativas en PHP.

Los sacrificios son manejables para la mayoría de los usuarios de WordPress. La comunidad de usuarios es menos numerosa que la de los ecosistemas consolidados de Apache o NGINX. OpenLiteSpeed solo se ejecuta en sistemas operativos similares a Unix (Linux, macOS), así que no hay servidores Windows. Y la edición de código abierto carece de algunas funciones disponibles en las ediciones comerciales LiteSpeed Enterprise y Standard, como el balanceo de carga avanzado y el clustering. Pero para ejecutar WordPress en un solo VPS, estas limitaciones rara vez importan en la práctica.

Comparación de benchmark de servidores web

Hablar de arquitectura solo llega hasta cierto punto. Ejecutamos los mismos tres tipos de sitios de WordPress a través de cada servidor web en un VPS KVM idéntico (un núcleo, 4 GB de RAM), midiendo el tiempo de carga total con GTmetrix. La misma instalación de WordPress, el mismo tema, los mismos plugins: solo cambió el servidor web entre las pruebas.

OpenLiteSpeed ganó todas las pruebas. Cargó páginas entre un 16 % y un 32 % más rápido que Apache, y entre un 14 % y un 38 % más rápido que NGINX en los tres tipos de sitios. El sitio personal mostró la menor brecha (las páginas más simples tienen menos espacio para optimización), mientras que la tienda de ecommerce mostró la mayor (las operaciones pesadas de PHP de WooCommerce se benefician enormemente del gestor de PHP integrado de LiteSpeed y del almacenamiento en caché a nivel de servidor).

No son pruebas de rendimiento sintéticas sobre cargas de trabajo artificiales. Son sitios WordPress reales, con temas y plugins reales, probados con una herramienta de rendimiento ampliamente utilizada. La combinación de arquitectura orientada a eventos, compatibilidad nativa con .htaccess y caché integrada proporciona a OpenLiteSpeed una clara ventaja para el hosting de WordPress que ni Apache ni NGINX pueden igualar con sus configuraciones predeterminadas.

Si estás configurando un nuevo VPS de WordPress y tienes la opción, elige OpenLiteSpeed. Obtienes la facilidad de uso de Apache, el perfil de rendimiento de NGINX y una integración de almacenamiento en caché que ningún competidor ofrece de forma nativa.

Cómo configurar WordPress en un VPS KVM

La teoría y las pruebas de rendimiento son útiles, pero viniste aquí para construir algo. Aquí está el recorrido práctico para configurar un VPS KVM con OpenLiteSpeed y WordPress. Cada paso se basa en el anterior. No te saltes pasos.

Instalar OpenLiteSpeed y WordPress

La mayoría de los proveedores de VPS que ofrecen planes KVM también proporcionan plantillas de aplicaciones preconstruidas o imágenes de un solo clic. Busca una plantilla basada en Ubuntu que incluya OpenLiteSpeed y WordPress. Usar una plantilla evita tener que instalar y configurar manualmente cada componente: el sistema operativo, el servidor web, PHP, MySQL y el propio WordPress.

En el panel de control de tu proveedor de VPS, navega a la sección de sistema operativo o plantillas de aplicaciones. Selecciona la plantilla de WordPress con OpenLiteSpeed. Aplica la plantilla a tu instancia de VPS y espera a que la instalación se complete. Esto suele tardar unos 10 minutos, dependiendo de la infraestructura de tu proveedor.

Si tu proveedor no ofrece una plantilla combinada, deberás instalar OpenLiteSpeed manualmente mediante el script de instalación oficial del repositorio de LiteSpeed, luego desplegar WordPress sobre él. El camino manual toma más tiempo e implica más trabajo en la línea de comandos, pero te proporciona un mayor control sobre las versiones de PHP, la configuración de MySQL y la optimización del servidor desde el principio.

Elijas la opción que elijas, verifica que la plantilla o la instalación manual incluya PHP 8.2+ (o la última versión estable), MariaDB o MySQL 8.x y el repositorio de OpenLiteSpeed configurado para actualizaciones de seguridad automáticas. Estos detalles son más importantes de lo que la mayoría de la gente piensa. Una versión de PHP desactualizada no solo pierde mejoras de rendimiento, sino que introduce vulnerabilidades de seguridad que los bots analizan activamente.

Conéctate a través de SSH y ejecuta el script de configuración

Después de que la plantilla termine de instalarse, necesitas finalizar la configuración del servidor a través de SSH. Conéctate a tu VPS mediante cualquier cliente SSH que prefieras: Terminal en Mac o Linux, PuTTY en Windows, o un terminal basado en navegador si tu proveedor dispone de uno integrado en su panel de control.

Inicia sesión con tus credenciales de root. Encontrarás los detalles de acceso SSH (dirección IP, nombre de usuario, puerto y contraseña) en la vista general o la sección de acceso del panel de control de tu VPS. Una vez que hayas iniciado sesión, un script de configuración interactivo debería ejecutarse automáticamente si utilizaste una plantilla.

El script pregunta por tu nombre de dominio o dirección IP de VPS, luego presenta una serie de indicaciones de configuración. La mayoría son preguntas simples de sí/no: ¿activar actualizaciones de seguridad automáticas? ¿Configurar reglas de cortafuegos? ¿Configurar espacio de intercambio? Los valores predeterminados funcionan correctamente para implementaciones estándar de WordPress. Responde a las preguntas y deja que el script termine. Cuando termine, verás una confirmación de que OpenLiteSpeed está instalado y el servidor web está funcionando.

Instala y configura WordPress

Con el servidor web activo, abre un navegador y navega a tu nombre de dominio o dirección IP de VPS. Llegarás al asistente de instalación estándar de WordPress, el mismo que aparece en cualquier instalación de WordPress.

Selecciona tu idioma, luego completa el título del sitio, nombre de usuario del administrador, correo electrónico del administrador y una contraseña segura. Guarda estas credenciales en un lugar seguro. Haz clic en «Instalar WordPress» y espera unos segundos a que la configuración se complete.

WordPress ya está en vivo. El plugin LiteSpeed Cache se instala automáticamente si usaste la plantilla de OpenLiteSpeed. Verifica que todo funcione: carga la página de inicio de tu sitio en un navegador, comprueba que el panel de administración se carga en /wp-admin, y confirma que el plugin LiteSpeed Cache aparece en el menú de Plugins del panel de control. Si algo se ve roto en esta etapa, casi siempre se trata de un problema de DNS: asegúrate de que el registro A de tu dominio apunte a la dirección IP de tu VPS.

Administra tu servidor y base de datos

OpenLiteSpeed incluye Web Admin, una interfaz gráfica basada en navegador para la gestión del servidor. Accede a él en https://tu-ip-vps:7080. Probablemente necesitarás abrir antes este puerto en tu cortafuegos. Por SSH, ejecuta:

ufw allow 7080

El nombre de usuario predeterminado de Web Admin es Admin (A mayúscula). Encuentra la contraseña con:

sudo cat /home/ubuntu/.litespeed_password

Desde el panel de Web Admin, puedes configurar hosts virtuales para múltiples dominios, gestionar certificados SSL, ajustar la configuración de PHP (límites de memoria, tiempo máximo de ejecución, tamaños de carga), y monitorizar métricas de rendimiento del servidor en tiempo real.

Para la gestión de bases de datos MySQL, la plantilla también instala phpMyAdmin. Accede en http://tu-ip-vps/phpmyadmin usando root como nombre de usuario. Obtén la contraseña de la base de datos mediante:

sudo cat /home/ubuntu/.db_password

Usa phpMyAdmin para operaciones de base de datos como optimizar tablas, ejecutar consultas manuales, gestionar usuarios y realizar copias de seguridad. Para uso en producción, consulta la documentación oficial de LiteSpeed para los pasos sobre cómo habilitar HTTPS con Let’s Encrypt y reforzar tu configuración SSL.

Configura el plugin LiteSpeed Cache

Aquí es donde las decisiones de virtualización y servidor web dan sus frutos. El plugin LiteSpeed Cache para WordPress está preinstalado mediante la plantilla de OpenLiteSpeed y aparece en tu panel de WordPress bajo Plugins.

Abre el panel de configuración del plugin. Para la mayoría de los sitios de WordPress, la configuración predeterminada de almacenamiento en caché funciona bien de inmediato. El ajuste que deberías activar sin falta desde el primer día es la caché de objetos. La caché de objetos almacena los resultados de las consultas de base de datos en memoria (generalmente mediante Redis o Memcached), lo que significa que WordPress no necesita volver a ejecutar las mismas consultas de MySQL para cada visualización de página. Para sitios de WooCommerce, esto por sí solo puede reducir a la mitad el tiempo de carga de la página.

Más allá del almacenamiento en caché de objetos, el plugin gestiona las cabeceras de almacenamiento en caché del navegador, la minificación y combinación de CSS y JavaScript, la carga diferida de imágenes, la conversión de imágenes WebP y la optimización de tablas de bases de datos. Todo esto se ejecuta a nivel de servidor web mediante el motor de caché nativo de LiteSpeed, no mediante soluciones basadas en PHP de las que depende la mayoría de los plugins de caché. La diferencia en la velocidad de ejecución entre el almacenamiento en caché a nivel de servidor y a nivel de PHP es drástica.

Dedica un tiempo a explorar los ajustes, pero no te compliques en exceso con la configuración inicial. Habilita el almacenamiento en caché de páginas, habilita el almacenamiento en caché de objetos, activa la minificación de CSS/JS y deja todo lo demás en los valores predeterminados. Puedes ajustar más adelante, una vez que tu sitio esté estable y dispongas de datos de tráfico reales.

Una cosa que vale la pena hacer de inmediato: realiza una prueba de velocidad antes y después. Usa GTmetrix o Google PageSpeed Insights para medir el tiempo de carga de tu sitio antes de habilitar la caché, y luego nuevamente después. Ver cómo bajan los valores reales te proporciona una referencia y confirma que la caché está funcionando. Si los números no mejoran, verifica que el plugin esté activo (comprueba la cabecera de respuesta X-LiteSpeed-Cache en las herramientas de desarrollo del navegador) y que tu servidor OpenLiteSpeed tenga el módulo de caché habilitado en Web Admin.

Resultados de rendimiento de LiteSpeed Cache

Probar ambos planes — KVM y OpenVZ — con LiteSpeed Cache activado y desactivado muestra exactamente cuánto contribuye cada capa a la optimización de velocidad de WordPress.

Sitio personal: KVM con LiteSpeed Cache habilitado fue un 10 % más rápido que OpenVZ con el mismo plugin activo. Lo interesante es lo siguiente: KVM sin ningún plugin de caché fue aún un 4 % más rápido que OpenVZ con LiteSpeed Cache activado. La ventaja de virtualización por sí sola superó a una pila completa de caché en la plataforma con peores especificaciones. Esto revela la importancia de la infraestructura subyacente.

Tienda de eCommerce: KVM entregó tiempos de carga un 8 % más rápidos con la caché habilitada y un 11 % más rápidos con la caché desactivada. La naturaleza intensiva en base de datos de WooCommerce hace que la ventaja de E/S de disco de KVM sea especialmente notable. Cada página de producto requiere múltiples consultas a la base de datos y un almacenamiento más rápido se traduce en resultados de consultas más rápidos, lo que se traduce en páginas más rápidas.

Sitio web de agencia: KVM mostró una mejora del 5 % con LiteSpeed Cache activado y un 3 % sin él. La menor diferencia refleja que los sitios de portafolio de agencias suelen estar condicionados por la ejecución de JavaScript externo y las llamadas a APIs de terceros, más que por el procesamiento de PHP en el servidor. Aun así, KVM no perdió una sola prueba.

El patrón consistente en todas las pruebas: KVM + OpenLiteSpeed + LiteSpeed Cache es la combinación más rápida disponible para el hosting de WordPress. La ventaja total de rendimiento varía entre un 5 % y un 21 % dependiendo de cuán intensiva sea la base de datos de tu sitio. Para una tienda de ecommerce en la que la velocidad de la página impacta directamente en las tasas de conversión y los ingresos, esa brecha del 21 % no es un ejercicio teórico, sino dinero real.

Preguntas frecuentes: WordPress en un VPS KVM