"La web va lenta" es la frase que más veces recibimos en soporte, y casi siempre llega sin ningún dato. Solo hay tres sospechosos: tu conexión, la web y el servidor. Las pruebas van en orden porque cada una descarta a uno, y entre todas son unos 20 minutos.
**Prueba 0: ¿le pasa a todo el mundo o solo a ti?**
Abre la web con datos móviles, sin wifi, y pásala por una herramienta externa tipo WebPageTest. Mira también la página de estado de tu proveedor.
Si solo va lenta en tu equipo, los culpables habituales son la caché DNS antigua, una línea olvidada en el archivo hosts (clásico después de una migración) o las DNS de tu operador. Limpia la caché DNS, revisa el hosts y prueba con unas DNS públicas.
**Prueba 1: ¿tarda en empezar o en terminar? (TTFB)**
Esta es la prueba que separa "problema de servidor" de "problema de web". El TTFB es lo que tarda el servidor en mandar el primer byte.
En Chrome: F12 → pestaña Red → recarga → primera petición (el HTML) → pestaña Tiempos → "Esperando respuesta del servidor".
Por consola:
“`
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" "https://tudominio.com/?nocache=12345"
“`
En Windows, `curl.exe` y `NUL` en vez de `/dev/null`.
Cuidado con una trampa en la que cae casi todo el mundo: si tienes caché (LiteSpeed Cache, por ejemplo), el TTFB que mides es falsamente bueno. Cambia el parámetro `?nocache=` en cada medición y quédate con la mediana de 3 o 4.
| TTFB | Diagnóstico | Qué hacer |
|—|—|—|
| Menos de 300 ms y la carga total lenta | Es la web: imágenes, scripts, fuentes | Optimizar la web |
| 300-600 ms | Zona gris | Optimizar y repetir en hora punta |
| Más de 600 ms y el resto normal | Servidor o aplicación | Pasa a la prueba 2 |
| TTFB alto y carga total alta | Probablemente las dos cosas | Empieza por el TTFB |
Referencia: Lighthouse marca como lento un TTFB por encima de 600 ms y Google da por bueno hasta 800 ms con usuarios reales. Con fibra y servidor en España, 600 ms ya es mucho.
**Prueba 2: ¿es la red o la máquina?**
Lanza unos 50 pings y mira la media, mejor por cable o wifi que con datos móviles. Orientación: menos de 30 ms para un servidor en la península, 30-60 ms para centro de Europa, más de 100 ms y el servidor está lejos de ti.
Para la ruta, traceroute o WinMTR. El error típico al leerlo: ver un salto intermedio con pérdida y dar por hecho que ahí está el problema. Los routers intermedios despriorizan el ICMP y pueden marcar pérdida sin afectar al tráfico real. Lo que importa es la pérdida que llega hasta el último salto. Si el servidor marca 0%, la red está bien.
Y si usas Cloudflare con el proxy activado, el ping no está midiendo tu servidor sino el nodo de Cloudflare más cercano. Para medir el origen, haz ping a la IP del servidor o desactiva el proxy un momento.
Red bien y TTFB alto: el problema está en la máquina.
**Prueba 3: ¿es el hosting o es tu WordPress?**
Sube un `prueba.html` con una sola línea a la carpeta pública y mide su TTFB. Al no ejecutar PHP ni tocar la base de datos, te da la velocidad pura del servidor.
– HTML rápido y WordPress lento: es la aplicación. Un plugin, el tema o una consulta. Búscalo con X-Ray en cPanel, que te da tiempos por función y por plugin.
– HTML también lento: el servidor está saturado o sin recursos.
Acuérdate de borrar el archivo al terminar.
**Cinco señales de que sí es el hosting**
-
Error `508 Resource Limit Is Reached` en los picos, confirmable en "Uso de recursos" de cPanel.
-
El HTML plano tiene el TTFB alto.
-
De madrugada vuela y en hora punta se arrastra, sin haber tocado nada en la web.
-
Errores de memoria agotada que siguen con el `memory_limit` al máximo del plan.
-
Escritorio o checkout lentos y X-Ray no señala ningún plugin. Ojo aquí: antes de culpar al servidor, descarta la pasarela de pago y la API del transportista, que son responsables de más checkouts lentos de lo que parece.
**Según el diagnóstico**
– **Conexión:** limpiar DNS, revisar el hosts, hablar con tu operador.
– **Web:** caché bien configurada, imágenes optimizadas y localizar el plugin lento.
– **Hosting:** saturación constante es cuestión de CPU y disco; picos con 508 es cuestión de concurrencia, que es otro problema distinto; y si necesitas recursos reservados y control total, VPS.
**La plantilla que nos ahorra medio día de ida y vuelta**
Si al final abres un ticket, con esto el diagnóstico es directo:
– URL afectada, fecha y hora exacta con zona horaria, si es continuo o intermitente, y tu IP pública
– Prueba 0: ¿lenta con datos móviles? ¿lenta desde una herramienta externa?
– Prueba 1: TTFB (mediana de 3) y tiempo de carga total
– Prueba 2: ping medio y pérdida de 50 paquetes, WinMTR exportado con "Export TEXT" (5 minutos si es constante, 15-30 si es intermitente), y si tienes Cloudflare activo
– Prueba 3: TTFB del HTML plano y de WordPress medidos en el mismo momento
– Errores vistos (508, 500, pantalla en blanco, memoria agotada) y cambios recientes: plugins, tema, tráfico, campañas
¿Cuál es la prueba que más veces os ha sorprendido? Por aquí la 3: el número de veces que el HTML plano vuela y el "problema de servidor" era un plugin es para hacer estadística.
Source: r/NicaliaHosting · by /u/Nicalia-Hosting-SPA