WordPress en VPS: guía completa de instalación con Nginx y MariaDB (2026)

Por qué WordPress se vuelve lento en hosting compartido

En hosting compartido, decenas o cientos de sitios comparten la misma CPU, la misma memoria y el mismo disco de un servidor físico. Cuando un vecino recibe un pico de tráfico o ejecuta una consulta pesada, tu sitio se ralentiza aunque tú no hayas cambiado nada. Este efecto tiene nombre en la industria: vecino ruidoso (noisy neighbour). No es una falla del proveedor, es el modelo de negocio: el precio bajo sale de repartir un servidor entre muchos clientes.

WordPress agrava el problema porque, sin caché, cada visita ejecuta PHP y lanza entre 20 y 60 consultas a la base de datos para armar una página que muchas veces es idéntica para todos los visitantes. En hosting compartido rara vez puedes controlar cuántos procesos PHP simultáneos tienes asignados, ni activar una caché a nivel de servidor, ni ajustar la memoria de MariaDB. Cuando llegan diez visitas al mismo tiempo, las peticiones hacen cola y el TTFB (Time To First Byte, el tiempo que tarda el servidor en devolver el primer byte de la respuesta) se dispara.

Ese TTFB es el que arruina las métricas. Google considera bueno un TTFB de 0,8 segundos o menos en el percentil 75 de las visitas reales, y pobre por encima de 1,8 segundos (web.dev, documentación oficial de Google). Como el TTFB ocurre antes de que el navegador pueda dibujar nada, funciona como un suelo: si tu servidor tarda 1,5 segundos en responder, tu LCP nunca bajará de 1,5 segundos por muy optimizadas que estén las imágenes. Lo explicamos en detalle en qué es el LCP (Largest Contentful Paint).

Hosting compartido y VPS: qué cambia en la práctica

La diferencia entre hosting compartido y VPS no es "más rápido" en abstracto: es qué palancas de rendimiento puedes tocar. Un VPS (Virtual Private Server, o servidor privado virtual) es una máquina virtual con CPU, RAM y disco asignados solo a ti, con acceso de administrador (root) al sistema operativo. Esta tabla resume lo que cambia de verdad al mudarte:

Los objetivos de TTFB de la última columna no son una promesa automática: dependen de que actives caché y de que tu tema y tus plugins no hagan trabajo innecesario. Un VPS mal configurado puede ser más lento que un buen hosting compartido. Lo que el VPS te da es el permiso para arreglarlo.

Cuándo migrar a un VPS (y cuándo no te hace falta)

Migrar a un VPS tiene sentido cuando el hosting compartido ya es el cuello de botella, no antes. Estas son las señales concretas que justifican el cambio:

• Tu TTFB supera los 0,8 segundos de forma consistente en PageSpeed Insights, incluso con un plugin de caché instalado.
• El proveedor te avisa por exceso de recursos (CPU, procesos concurrentes, entry processes) o te suspende en los picos.
• Necesitas una versión de PHP concreta, una extensión que el panel no ofrece, o herramientas como WP-CLI, Composer, Node o un cron real.
• Tienes WooCommerce con catálogo grande: las páginas de carrito, checkout y cuenta no se pueden cachear, así que se ejecutan siempre en PHP y necesitan CPU de verdad.
• Administras varios sitios de clientes y quieres consolidarlos con reglas, copias y monitoreo propios.

Y aquí va el consejo que casi nadie da: si tienes un blog con 500 visitas al mes, un sitio institucional de cinco páginas o una landing que ya carga en 1,5 segundos, no necesitas un VPS. Un buen hosting compartido con un plugin de caché decente te dará el mismo resultado sin obligarte a mantener un servidor. La contrapartida real del VPS es que las actualizaciones de seguridad, los respaldos y el monitoreo pasan a ser tu responsabilidad. Si nadie en tu equipo va a ocuparse de eso, un VPS mal mantenido es peor que un compartido regular. Si quieres el comparativo completo entre las tres opciones, lo tienes en hosting compartido vs VPS vs dedicado.

Qué necesitas antes de empezar

Para seguir esta guía completa necesitas cuatro cosas, y ninguna es cara. Este es el punto de partida exacto:

Sobre la versión del sistema: Ubuntu 22.04 LTS también sirve, pero su mantenimiento de seguridad estándar termina en mayo de 2027, y sus repositorios traen PHP 8.1, así que necesitarías un repositorio externo para instalar una versión moderna de PHP (ciclo de vida de Ubuntu, Canonical). Si estás creando el servidor hoy, elige 24.04.

Sobre el tamaño: WordPress recomienda oficialmente PHP 8.3 o superior, MariaDB 10.11+ o MySQL 8.0+, y HTTPS obligatorio en toda instalación (requisitos oficiales de WordPress). Con 2 GB de RAM cumples ese stack completo con margen. Los planes VPS de Terranode arrancan en 1 vCPU con 2 GB de RAM y 30 GB NVMe por 5,00 USD al mes, con virtualización KVM y puerto de 10 Gbps; el salto natural cuando el sitio crece es a 2 vCPU y 4 GB. Puedes ver capacidades y regiones disponibles en la página de VPS.

Un apunte sobre el puerto de 10 Gbps, para no venderte humo: el ancho de banda del puerto no reduce por sí solo el TTFB de una petición aislada —eso depende de la latencia y del tiempo que tarde el servidor en generar la página—. Donde sí marca diferencia es cuando muchos visitantes descargan a la vez, cuando sirves imágenes o vídeo pesados, y cuando restauras o migras copias de varios gigabytes: con un puerto saturado el navegador espera aunque el servidor ya haya respondido. Un puerto de 10 Gbps garantiza que la red nunca sea tu cuello de botella; el resto lo pone la configuración.

Paso 1: conectar al VPS por SSH y asegurar el acceso

El primer paso es entrar al servidor por SSH y dejar de usar root para el trabajo diario. SSH (Secure Shell) es el protocolo que te da una terminal remota cifrada en el servidor. Con la IP y la contraseña que te entregó el proveedor:

ssh [email protected]

Lo primero, actualizar el sistema y crear un usuario con permisos de administrador. Trabajar como root permanentemente es la forma más fácil de borrar algo importante por accidente:

apt update && apt upgrade -y

adduser terra
usermod -aG sudo terra

Ahora, desde tu computadora (no desde el servidor), genera una clave SSH si no tienes una y cópiala al servidor. Una clave SSH sustituye la contraseña por un par de archivos criptográficos: es más cómodo y muchísimo más difícil de atacar por fuerza bruta.

ssh-keygen -t ed25519 -C "[email protected]"
ssh-copy-id [email protected]

Comprueba que puedes entrar con el usuario nuevo (ssh [email protected]) antes de desactivar el acceso por contraseña. Si te equivocas de orden, te quedas fuera del servidor. Ya validado, edita /etc/ssh/sshd_config:

sudo nano /etc/ssh/sshd_config

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

sudo systemctl restart ssh

Por último, el cortafuegos. UFW (Uncomplicated Firewall) es la interfaz sencilla del firewall de Ubuntu; abre solo lo que necesitas:

sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable
sudo ufw status

Con esto quedan abiertos el puerto 22 (SSH), el 80 (HTTP) y el 443 (HTTPS), y cerrado todo lo demás. Si quieres endurecer el acceso frenando los intentos automatizados de login, el siguiente paso natural es Fail2ban.

Paso 2: instalar Nginx

Nginx es el servidor web que recibirá las peticiones de los visitantes y decidirá qué hacer con ellas: entregar un archivo estático, pasarle la petición a PHP o servir una copia cacheada. Se instala desde los repositorios oficiales de Ubuntu, que en 24.04 incluyen la rama 1.24:

sudo apt install nginx -y
sudo systemctl enable --now nginx

Verifica que arrancó y que responde:

systemctl status nginx
curl -I http://localhost

Si ves HTTP/1.1 200 OK, Nginx está sirviendo. Abriendo la IP del servidor en el navegador deberías ver la página "Welcome to nginx". Esa página vive en /var/www/html y la reemplazaremos por WordPress más adelante.

Una diferencia importante con Apache que conviene tener clara desde el principio: Nginx no lee archivos .htaccess. Todas las reglas de reescritura, redirecciones y bloqueos que en Apache viven en ese archivo, aquí se escriben en el server block y se aplican al recargar la configuración. Es más rápido —Nginx no busca archivos de configuración en cada carpeta en cada petición— pero significa que algunos plugins de WordPress que "se configuran solos" te pedirán pegar unas líneas a mano.

Paso 3: instalar MariaDB y crear la base de datos

MariaDB es el sistema de base de datos donde WordPress guarda entradas, páginas, comentarios, usuarios y opciones. Es una bifurcación de MySQL creada por los desarrolladores originales, compatible a nivel de comandos y protocolo, y es la versión que trae Ubuntu por defecto. Ubuntu 24.04 incluye MariaDB 10.11, que cumple exactamente el mínimo recomendado por WordPress.

sudo apt install mariadb-server -y
sudo systemctl enable --now mariadb
sudo mysql_secure_installation

El asistente mysql_secure_installation hace cuatro cosas que deberías aceptar todas: define contraseña de root, elimina los usuarios anónimos, prohíbe el login remoto de root y borra la base de datos de prueba. Con eso cierras los agujeros clásicos de una instalación recién hecha.

Ahora crea la base de datos y el usuario que usará WordPress. Entra a la consola de MariaDB:

sudo mariadb

CREATE DATABASE wordpress DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'wp_user'@'localhost' IDENTIFIED BY 'PON-AQUI-UNA-CLAVE-LARGA-Y-ALEATORIA';
GRANT ALL PRIVILEGES ON wordpress.* TO 'wp_user'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Tres detalles importantes de ese bloque. utf8mb4 es el juego de caracteres que soporta cualquier carácter Unicode, incluidos emojis y acentos: sin él, tarde o temprano aparece un texto corrupto. 'wp_user'@'localhost' limita ese usuario a conexiones desde el propio servidor, así que nadie puede conectarse a tu base desde internet. Y **GRANT ALL ... ON wordpress.*** le da permisos solo sobre esa base, no sobre todas: si mañana alojas un segundo sitio, cada uno tendrá su usuario y su base aisladas.

Para un VPS de 2 GB conviene ajustar la memoria que MariaDB reserva para su caché de datos. Crea /etc/mysql/mariadb.conf.d/99-terranode.cnf:

[mysqld]
innodb_buffer_pool_size = 512M
innodb_log_file_size = 128M
max_connections = 60
table_open_cache = 400

sudo systemctl restart mariadb

innodb_buffer_pool_size es el parámetro que más impacto tiene: es la cantidad de RAM que MariaDB usa para mantener tablas e índices en memoria en vez de leerlos del disco. La regla práctica en un servidor dedicado a WordPress es asignarle entre el 25 % y el 40 % de la RAM total, dejando espacio para PHP-FPM y Nginx. Si quieres entender mejor qué hace esta pieza, tenemos una introducción en qué es MySQL y para qué sirve.

Paso 4: instalar PHP 8.3 y los módulos que WordPress necesita

WordPress es una aplicación PHP, así que necesitas un intérprete de PHP y varias extensiones. Usaremos PHP 8.3, que es la versión por defecto de Ubuntu 24.04 y la que WordPress recomienda oficialmente. Una nota de honestidad sobre versiones: PHP 8.2 funciona perfectamente con WordPress, pero solo recibe parches de seguridad hasta el 31 de diciembre de 2026, mientras que PHP 8.3 los recibe hasta el 31 de diciembre de 2027 y PHP 8.4 hasta el 31 de diciembre de 2028 (versiones soportadas, php.net). Si estás instalando hoy, no arranques en una rama que caduca el año que viene.

sudo apt install php8.3-fpm php8.3-mysql php8.3-curl php8.3-gd php8.3-mbstring \
  php8.3-xml php8.3-zip php8.3-intl php8.3-bcmath php8.3-imagick php8.3-opcache -y

Cada módulo cubre una función concreta de WordPress:

Ahora ajusta los límites de PHP. Edita /etc/php/8.3/fpm/php.ini:

memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 300
max_input_vars = 3000

opcache.enable = 1
opcache.memory_consumption = 192
opcache.interned_strings_buffer = 16
opcache.max_accelerated_files = 20000
opcache.revalidate_freq = 60

upload_max_filesize y post_max_size son los que evitan el clásico "el archivo excede el tamaño máximo" al subir una imagen o instalar un tema; deben ir siempre en pareja. max_input_vars en 3000 previene que se pierdan opciones al guardar en temas con paneles enormes.

sudo systemctl restart php8.3-fpm
php -v

Paso 5: descargar y configurar WordPress

Con el servidor web, la base de datos y PHP listos, toca instalar WordPress. Lo descargamos directamente de wordpress.org en su versión en español, lo colocamos en la carpeta del sitio y ajustamos permisos:

cd /tmp
curl -O https://es.wordpress.org/latest-es_ES.tar.gz
tar -xzf latest-es_ES.tar.gz

sudo mkdir -p /var/www/tudominio.com
sudo cp -a /tmp/wordpress/. /var/www/tudominio.com/

Los permisos importan más de lo que parece: si los archivos no pertenecen al usuario que ejecuta PHP, WordPress no podrá actualizarse ni subir imágenes; si son demasiado abiertos, cualquier proceso del servidor puede modificarlos.

sudo chown -R www-data:www-data /var/www/tudominio.com
sudo find /var/www/tudominio.com -type d -exec chmod 755 {} \;
sudo find /var/www/tudominio.com -type f -exec chmod 644 {} \;

Ahora el archivo de configuración. Copia la plantilla y edítala:

cd /var/www/tudominio.com
sudo -u www-data cp wp-config-sample.php wp-config.php
sudo -u www-data nano wp-config.php

Rellena los datos de la base de datos que creaste en el paso 3:

define( 'DB_NAME', 'wordpress' );
define( 'DB_USER', 'wp_user' );
define( 'DB_PASSWORD', 'LA-CLAVE-LARGA-QUE-CREASTE' );
define( 'DB_HOST', 'localhost' );
define( 'DB_CHARSET', 'utf8mb4' );
define( 'DB_COLLATE', '' );

Sustituye el bloque de claves de seguridad (AUTH_KEY, SECURE_AUTH_KEY, etc.) por uno generado al azar. WordPress ofrece un endpoint que las genera; puedes obtenerlas desde el propio servidor:

curl https://api.wordpress.org/secret-key/1.1/salt/

Y añade tres líneas antes del comentario / That's all, stop editing! /:

define( 'DISALLOW_FILE_EDIT', true );
define( 'WP_DEBUG', false );
define( 'WP_MEMORY_LIMIT', '256M' );

DISALLOW_FILE_EDIT desactiva el editor de código del panel de WordPress. Es una de las medidas de seguridad más rentables que existen: si alguien roba una cuenta de administrador, sin ese editor no puede inyectar PHP desde el navegador. Encontrarás más medidas de este tipo en la guía de cómo mejorar la seguridad de tu sitio WordPress.

Paso 6: configurar Nginx para WordPress (server block completo)

El server block es el archivo donde le dices a Nginx qué dominio atiende, dónde están los archivos y cómo tratar las peticiones PHP. Crea /etc/nginx/sites-available/tudominio.com:

sudo nano /etc/nginx/sites-available/tudominio.com

server {
    listen 80;
    listen [::]:80;
    server_name tudominio.com www.tudominio.com;

    root /var/www/tudominio.com;
    index index.php index.html;

    client_max_body_size 64M;

    # Enlaces permanentes de WordPress: si el archivo no existe, lo resuelve index.php
    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    # Ejecutar PHP a través de PHP-FPM por socket Unix
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        fastcgi_read_timeout 300;
    }

    # Estáticos: cacheados en el navegador y sin registrar en el log
    location ~* \.(jpg|jpeg|png|gif|webp|avif|svg|ico|css|js|woff2)$ {
        expires 30d;
        add_header Cache-Control "public, no-transform";
        access_log off;
    }

    location = /favicon.ico { log_not_found off; access_log off; }
    location = /robots.txt  { allow all; log_not_found off; access_log off; }

    # Bloquear archivos ocultos, salvo la validación de Let's Encrypt
    location ~ /\.(?!well-known).* { deny all; }

    # Nunca ejecutar PHP subido a la carpeta de medios
    location ~* /wp-content/uploads/.*\.php$ { deny all; }

    # xmlrpc.php: vector clásico de fuerza bruta. Bloquéalo si no usas la app móvil ni Jetpack
    location = /xmlrpc.php { deny all; access_log off; log_not_found off; }

    # Compresión
    gzip on;
    gzip_vary on;
    gzip_comp_level 5;
    gzip_min_length 256;
    gzip_proxied any;
    gzip_types text/plain text/css text/xml application/json application/javascript
               application/rss+xml application/xml image/svg+xml;
}

Las dos líneas que más problemas evitan son try_files $uri $uri/ /index.php?$args;, que es lo que hace funcionar los enlaces permanentes bonitos (sin ella todas las URLs internas dan 404), y el bloqueo de PHP dentro de wp-content/uploads, que impide que un archivo malicioso subido como imagen se ejecute como código.

Activa el sitio, quita el sitio por defecto y recarga:

sudo ln -s /etc/nginx/sites-available/tudominio.com /etc/nginx/sites-enabled/
sudo rm /etc/nginx/sites-enabled/default
sudo nginx -t
sudo systemctl reload nginx

nginx -t valida la sintaxis antes de aplicar los cambios. Hazlo siempre antes de recargar: si hay un error y recargas a ciegas, el servicio puede quedarse abajo y el sitio caído.

Antes de continuar, apunta el dominio al servidor: en el panel de DNS crea un registro A para tudominio.com con la IP del VPS, y otro registro A (o un CNAME) para www. La propagación suele tardar entre minutos y un par de horas. Cuando ping tudominio.com responda con la IP de tu VPS, puedes visitarlo en el navegador y completar el asistente de instalación de WordPress: idioma, título del sitio, usuario administrador y contraseña.

Paso 7: certificado SSL gratis con Certbot

HTTPS no es opcional: WordPress lo marca como requisito en toda instalación, los navegadores muestran advertencias sin él y Google lo espera. Certbot es el cliente oficial que obtiene e instala certificados de Let's Encrypt, una autoridad certificadora sin ánimo de lucro que emite certificados gratuitos con validez de 90 días, pensados para renovarse automáticamente cada 60 (FAQ de Let's Encrypt).

La propia EFF, que desarrolla Certbot, recomienda instalarlo por snap para tener siempre la versión más reciente:

sudo snap install core && sudo snap refresh core
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

Con el dominio ya apuntando al servidor, pide el certificado:

sudo certbot --nginx -d tudominio.com -d www.tudominio.com

Certbot verifica que controlas el dominio, emite el certificado, modifica tu server block para añadir el bloque HTTPS y ofrece redirigir todo el tráfico de HTTP a HTTPS: acepta esa redirección. Comprueba que la renovación automática está programada:

sudo certbot renew --dry-run
systemctl list-timers | grep certbot

Después de activar SSL, entra al panel de WordPress y confirma en Ajustes > Generales que la dirección del sitio empieza por https://. Si el sitio venía de una migración, quedará contenido mixto (imágenes enlazadas con http://) que verás como advertencia en el navegador; se corrige con una búsqueda y reemplazo en la base de datos.

Paso 8: optimización de rendimiento (FastCGI cache, PHP-FPM y compresión)

Aquí es donde el VPS se despega del hosting compartido. La optimización que más impacto tiene con diferencia es el FastCGI cache de Nginx: guarda el HTML ya generado de cada página y lo sirve directamente en las siguientes visitas, sin ejecutar PHP ni consultar la base de datos. Una página que tardaba 400 ms en generarse pasa a entregarse desde memoria o disco en pocos milisegundos.

Primero, declara la zona de caché dentro del bloque http { ... } de /etc/nginx/nginx.conf:

fastcgi_cache_path /var/cache/nginx/wordpress levels=1:2 keys_zone=WORDPRESS:100m
                   inactive=60m max_size=1g;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
fastcgi_cache_use_stale error timeout invalid_header updating http_500 http_503;
fastcgi_ignore_headers Cache-Control Expires Set-Cookie;

Luego, dentro de tu server block, define cuándo no hay que cachear y activa la caché en el bloque PHP:

set $skip_cache 0;

# Nunca cachear peticiones POST ni con parámetros de consulta
if ($request_method = POST) { set $skip_cache 1; }
if ($query_string != "")    { set $skip_cache 1; }

# Nunca cachear el panel, el login, feeds ni sitemaps
if ($request_uri ~* "/wp-admin/|/wp-json/|/xmlrpc.php|wp-.*\.php|/feed/|sitemap(_index)?\.xml") {
    set $skip_cache 1;
}

# Nunca cachear a usuarios con sesión iniciada o que comentaron
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in") {
    set $skip_cache 1;
}

# WooCommerce: carrito, pago y cuenta son personales, nunca se cachean
if ($request_uri ~* "/(carrito|finalizar-compra|mi-cuenta)/") { set $skip_cache 1; }

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_read_timeout 300;

    fastcgi_cache_bypass $skip_cache;
    fastcgi_no_cache     $skip_cache;
    fastcgi_cache        WORDPRESS;
    fastcgi_cache_valid  200 301 302 60m;
    add_header X-FastCGI-Cache $upstream_cache_status;
}

sudo mkdir -p /var/cache/nginx/wordpress
sudo chown -R www-data:www-data /var/cache/nginx
sudo nginx -t && sudo systemctl reload nginx

La cabecera X-FastCGI-Cache te dice si una página se sirvió desde caché (HIT), se generó en el momento (MISS) o quedó excluida (BYPASS). Compruébalo así:

curl -I https://tudominio.com/ | grep -i x-fastcgi-cache

Instala además el plugin Nginx Helper en WordPress y actívale el purgado por HIT/MISS: sin él, cuando publiques o edites una entrada, los visitantes seguirán viendo la versión cacheada durante hasta 60 minutos. Si ya usabas un plugin de caché de página como WP Super Cache o W3 Total Cache, desactívalo: dos capas de caché de página encima una de otra generan inconsistencias muy difíciles de depurar. Ampliamos este tema en Nginx caching y rendimiento del servidor.

Ajuste de PHP-FPM. El pool controla cuántas peticiones PHP simultáneas puede atender el servidor. Es lo que define si tu sitio aguanta un pico o encola visitas. Edita /etc/php/8.3/fpm/pool.d/www.conf:

pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6
pm.max_requests = 500

El número que hay que calcular es pm.max_children: se obtiene dividiendo la RAM disponible para PHP entre lo que consume un proceso. En un WordPress típico cada proceso PHP usa entre 40 y 80 MB. En un VPS de 2 GB, reservando alrededor de 700 MB para el sistema, MariaDB y Nginx, quedan unos 1,3 GB; a 60 MB por proceso salen unos 20 procesos. En un VPS de 4 GB el número ronda los 45. Ponerlo demasiado alto es peor que dejarlo bajo: el servidor empieza a usar swap y todo se vuelve lentísimo.

sudo systemctl restart php8.3-fpm

Compresión. El bloque gzip del paso 6 ya reduce el HTML, CSS y JavaScript entre un 60 % y un 80 % antes de enviarlos. Brotli comprime algo mejor que gzip, pero no viene incluido en el paquete de Nginx de Ubuntu: requiere compilar el módulo ngx_brotli o usar un CDN que lo aplique. Si estás empezando, gzip bien configurado cubre la mayor parte del beneficio.

Copias de seguridad. Antes de dar por terminada la instalación, programa un respaldo. En un VPS no administrado nadie lo hará por ti. Lo mínimo es un volcado diario de la base y una copia semanal de los archivos:

sudo mysqldump --single-transaction wordpress | gzip > /root/backups/wp-$(date +%F).sql.gz

Súbelo fuera del servidor: una copia guardada solo en el mismo disco que estás respaldando no es una copia. Puedes automatizarlo con rsync y cron.

Cómo medir el impacto en Core Web Vitals

Para saber si la migración funcionó, mide tres cosas antes y después: TTFB, LCP y estado de la caché. Estos son los umbrales oficiales de Google, medidos en el percentil 75 de las visitas reales:

Fuente: web.dev/articles/ttfb y web.dev/articles/lcp, documentación oficial de Google.

La medida más rápida y honesta del TTFB de tu servidor la da curl, porque mide solo la respuesta del servidor sin el ruido del navegador:

curl -o /dev/null -s -w "DNS: %{time_namelookup}s | Conexión: %{time_connect}s | TTFB: %{time_starttransfer}s | Total: %{time_total}s\n" https://tudominio.com/

Ejecútalo dos veces seguidas: la primera puede ser un MISS de caché y la segunda un HIT. La diferencia entre ambas te dice exactamente cuánto trabajo te está ahorrando el FastCGI cache.

Para el LCP usa PageSpeed Insights, que combina dos tipos de datos y conviene no confundir. Los datos de laboratorio (Lighthouse) reflejan el cambio de inmediato: si tu servidor mejoró, lo verás en la siguiente ejecución. Los datos de campo vienen del informe CrUX, que se calcula sobre una ventana móvil de 28 días de usuarios reales de Chrome, así que la mejora tarda semanas en verse completa ahí y en Search Console. No te alarmes si el laboratorio mejora y el campo todavía no.

Un matiz que evita frustraciones: el servidor solo controla el primer tramo del LCP. Si tu TTFB baja de 1,5 s a 0,1 s pero tu imagen de portada pesa 2 MB sin comprimir, el LCP seguirá siendo malo. El VPS elimina el suelo impuesto por el servidor; el resto lo ponen las imágenes en formato WebP o AVIF, el fetchpriority="high" en la imagen principal, y no aplicar lazy loading al elemento más grande de la primera pantalla. La lista completa de causas está en qué es el LCP y cómo mejorarlo, y los criterios con los que Google fija cada umbral, en umbrales de Core Web Vitals.