Hosting WordPress con NVMe: qué diferencia hay respecto al SSD convencional y por qué importa
Cuando un proveedor de hosting dice «SSD» sin más, puede estar hablando de cualquier cosa: desde discos SATA de consumo de hace cinco años hasta NVMe de última generación con interfaces PCIe 4.0. La diferencia entre ambos extremos es un factor de rendimiento de entre 5x y 30x en operaciones de lectura aleatoria, que es exactamente el tipo de operación que más hace WordPress.
Qué significa NVMe técnicamente
NVMe (Non-Volatile Memory Express) es un protocolo de comunicación diseñado desde cero para almacenamiento flash. Los SSD SATA usan el protocolo AHCI, que fue diseñado originalmente para discos duros mecánicos en los años 2000 y tiene una cola de comandos máxima de 32 entradas. NVMe soporta hasta 65.535 colas con 65.535 comandos cada una, lo que permite paralelizar masivamente las operaciones de I/O.
En cifras concretas: un SSD SATA moderno entrega entre 90.000 y 100.000 IOPS en lectura aleatoria de bloques de 4KB. Un NVMe PCIe 3.0 entrega entre 400.000 y 600.000 IOPS. Un NVMe PCIe 4.0 supera el millón de IOPS. La latencia media por operación pasa de 70-100 microsegundos en SATA a menos de 20 microsegundos en NVMe.
Por qué WordPress es especialmente sensible a la latencia de I/O
WordPress genera muchas lecturas aleatorias de archivos pequeños en cada petición. Al cargar una página, PHP tiene que leer el núcleo de WordPress (varios archivos en /wp-includes/), el tema activo (/wp-content/themes/), cada plugin activo (/wp-content/plugins/) y eventualmente archivos de caché. Con 20 plugins activos una petición sin OPcache puede generar 300 o más operaciones de I/O.
Con OPcache activo ese número cae drásticamente porque el bytecode compilado vive en RAM. Pero incluso con OPcache, la primera carga después de un reinicio del servidor o después de invalidar la caché tiene que leer todo del disco. Y en un servidor bajo carga donde hay múltiples procesos PHP ejecutándose en paralelo, la cola de I/O al disco es el recurso compartido que determina el throughput máximo.
Latencia de red vs latencia de disco: qué frena más
En un servidor bien ubicado geográficamente, la latencia de red entre el servidor y un usuario en España es de 5 a 15ms. La latencia de una operación de lectura en disco SATA es de 0.07 a 0.1ms. En NVMe es de 0.015 a 0.02ms. Parece que el disco no es el problema porque la red es órdenes de magnitud más lenta.
Pero hay que entender la diferencia entre latencia secuencial y throughput bajo carga. Cuando 50 usuarios cargan tu web al mismo tiempo, el servidor ejecuta 50 procesos PHP en paralelo que todos compiten por acceder al disco. La latencia de cada operación individual se multiplica por la cola de espera. Un disco SATA con 100ms de latencia bajo carga se convierte en el cuello de botella. Un NVMe con 1 millón de IOPS absorbe esa carga sin degradar el tiempo de respuesta.
RAID 10 sobre NVMe: redundancia sin sacrificar velocidad
En ISPACTIVO usamos configuraciones RAID 10 sobre NVMe. RAID 10 combina mirroring (RAID 1) y striping (RAID 0): los datos se escriben en dos discos simultáneamente para redundancia, y se leen en paralelo de ambos para velocidad. El resultado es que la velocidad de lectura escala con el número de discos y la tolerancia a fallos es alta: el array soporta la pérdida de hasta la mitad de los discos si no son del mismo par.
Frente a RAID 5 o RAID 6, que requieren calcular paridad en cada escritura, RAID 10 tiene menor latencia de escritura. Para un servidor de hosting donde las lecturas dominan el perfil de I/O, RAID 10 sobre NVMe es la combinación óptima entre rendimiento y fiabilidad.
El impacto en métricas reales de WordPress
En pruebas con la misma instalación WordPress (tema Astra, 15 plugins típicos, sin caché de página), la migración de SSD SATA a NVMe reduce el TTFB medio de 280ms a 95ms en condiciones de carga baja. Bajo carga de 100 usuarios concurrentes, la diferencia es más dramática: el TTFB en SATA sube a más de 800ms por la saturación de I/O, mientras que en NVMe se mantiene en 150-180ms.
Esas cifras son las que marcan la diferencia en Core Web Vitals, concretamente en LCP (Largest Contentful Paint) y en el TTFB que Google mide para el ranking. Un TTFB por encima de 600ms empieza a impactar negativamente en la puntuación de Page Experience.
Por qué no todos los proveedores usan NVMe aunque lo anuncien
Hay un matiz importante: en entornos de virtualización, el tipo de disco del host físico no garantiza que la VM tenga acceso directo al NVMe. Algunos proveedores usan virtualización con almacenamiento en red (NAS o SAN), donde el disco NVMe del servidor físico está separado de las VMs por una capa de red. En ese caso la latencia real para la VM puede ser similar a la de un disco SATA o incluso peor, dependiendo de la congestión de la red de almacenamiento.
En nuestros planes de hosting los discos NVMe están locales en el mismo servidor físico, sin capas de red intermedias. Es la única forma de aprovechar completamente la baja latencia que ofrece el protocolo NVMe. Hosting WordPress con NVMe.
