Por Fran Navoz en Hosting, Productos y servicios, WordPress
30 de septiembre de 2026
Cuando una web va lenta, lo primero que hace casi todo el mundo es echarle la culpa al hosting y buscar otro. A veces acierta. Otras se muda, paga la migración, pasa un fin de semana cambiando DNS y descubre que la web va igual de lenta en el sitio nuevo, porque el problema eran cuatro imágenes de 3 MB o la wifi de su oficina.
Aquí no vas a encontrar una lista de diez causas. Tienes un orden de pruebas en el que cada una descarta a un sospechoso, y se hace en unos veinte minutos con lo que ya tienes instalado en el ordenador.
Solo hay tres sitios donde se puede perder el tiempo de carga: tu conexión, tu web o el servidor donde está alojada. El problema es que casi todos probamos igual, desde casa, a la misma hora, con el mismo navegador y con las mismas extensiones. Así no se puede separar una cosa de otra, porque cualquier fallo de tu lado contamina todas las mediciones que hagas después.
Por eso las pruebas van en orden. Si te saltas la primera, las siguientes pueden darte un resultado que parece del servidor y que en realidad es de tu router.
Te lleva un minuto. Apaga la wifi del móvil y abre la web con datos móviles. Luego pásala por una herramienta de medición externa como WebPageTest, que carga la página desde un servidor que no tiene nada que ver contigo. Y ya que estás, echa un vistazo a la página de estado de los servicios por si hay una incidencia general en marcha.
Si solo te pasa a ti, lo más habitual es que tu ordenador tenga guardada una dirección antigua del dominio. Pasa mucho después de una migración o de un cambio de DNS, y se arregla en un par de minutos:
Esta prueba sola resuelve una parte de los casos, y sin gastar un euro.
Esta es la prueba que separa de verdad tu web del servidor. Cuando pides una página, el servidor primero tiene que generarla, y el tiempo que tarda en enviarte el primer byte se llama TTFB (time to first byte). Todo lo que viene después, imágenes, scripts, fuentes, es lo que pesa tu web.
Para medirlo abre la web en Chrome, pulsa F12, ve a la pestaña Red y recarga. Haz clic en la primera petición de la lista, que es el documento HTML, y en la pestaña Tiempos fíjate en «Esperando respuesta del servidor». Ese es tu TTFB.
Si prefieres la consola, este comando te da el mismo dato en segundos (en Windows 10 y 11 escribe curl.exe y cambia /dev/null por NUL):
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" "https://tudominio.com/?nocache=12345"Ojo con esto, porque es donde casi todo el mundo se equivoca al medir. Si tienes un plugin de caché como LiteSpeed Cache, la página que ves ya viene hecha y el TTFB sale bajo aunque el servidor vaya ahogado. Para medir el servidor de verdad necesitas una página sin caché: añade un parámetro inventado a la URL (?nocache= con un número distinto cada vez) o mide con la sesión de WordPress iniciada. Haz tres o cuatro mediciones y quédate con la mediana.
| Lo que ves | Quién tiene la culpa | Qué haces |
|---|---|---|
| TTFB por debajo de 300 ms y la página tarda en terminar | Tu web: imágenes, scripts, fuentes | No es el hosting. Optimiza la web |
| TTFB entre 300 y 600 ms | Zona gris: mejorable, pero no es la causa principal si la carga total es alta | Optimiza la web primero y repite la medición en hora punta |
| TTFB por encima de 600 ms, el resto normal | Servidor o aplicación | Prueba 2 |
| TTFB alto y carga total alta | Probablemente los dos | Empieza por el TTFB: prueba 2 |
Los 600 ms son el umbral a partir del cual Lighthouse, la herramienta de auditoría de Chrome, te marca la respuesta del servidor como lenta. Google considera «bueno» un TTFB de hasta 800 ms medido con usuarios reales, pero ahí entran conexiones móviles lentas. Si mides con fibra desde España, 600 ms ya es mucho.
Si has caído en la primera fila, te lo decimos claro: cambiar de hosting no te lo va a arreglar.
Tu servidor responde rápido y el tiempo se va en descargar lo que tu web le pide al navegador. Empieza por configurar bien LiteSpeed Cache o, si usas otro plugin, WP Rocket. Si tienes tienda, tenemos guías específicas para WooCommerce lento y PrestaShop lento.
Un TTFB alto puede venir de dos sitios. O el servidor tarda en generar la página, o los datos tardan en ir y volver porque el servidor está lejos o hay un tramo de red con problemas. Estas pruebas lo separan.
Primero necesitas saber a qué IP apunta tu dominio o cuál es la IP de tu servidor. Después haz un ping de unas 50 respuestas y mira la media.
Con fibra desde España, un servidor alojado en la península suele responder por debajo de 30 ms. Uno en el centro de Europa se mueve entre 30 y 60 ms, y si pasas de 100 ms lo más probable es que tu web esté al otro lado del Atlántico, aunque te la vendieran como alojamiento en España. Haz el ping con cable o con la wifi de casa, no con datos móviles, que añaden latencia por su cuenta y te desmontan la comparación.
Para que tengas una referencia, nuestros servidores están en un centro de datos de Barcelona.
Si la latencia es rara o da saltos, el siguiente paso es ver el recorrido completo con un traceroute o, mejor todavía, con WinMTR, que repite la prueba de forma continua y te da porcentajes de pérdida en cada salto.
Aquí hay un malentendido que genera muchos tiques. Si ves un 40% de pérdida en un salto intermedio pero el último salto, que es tu servidor, está en 0%, no hay ningún problema. Muchos routers dan poca prioridad a los paquetes de diagnóstico mientras siguen moviendo el tráfico normal sin pestañear. La pérdida que importa es la que empieza en un salto y se arrastra hasta el final.
Con el proxy de Cloudflare activado (la nube naranja), el ping y el traceroute llegan al nodo de Cloudflare más cercano a ti y no a tu servidor. Te saldrá una latencia estupenda que no dice nada de tu hosting. Para medir el origen, haz ping directamente a la IP de tu servidor o desactiva el proxy un rato mientras pruebas. En nuestra guía para configurar Cloudflare tienes dónde se cambia.
Si la latencia es buena, no hay pérdidas hasta el final y aun así el TTFB sigue alto, la red queda descartada. El problema está dentro de la máquina y toca la prueba 3.
Esta prueba casi nadie la cuenta y es la más reveladora de todas. Crea un archivo llamado prueba.html con una sola línea de texto, súbelo a la carpeta pública de tu web y mide su TTFB igual que en la prueba 1.
Un HTML plano no ejecuta PHP ni toca la base de datos. El servidor solo tiene que leer un archivo y enviarlo, así que su TTFB te dice lo rápido que responde la máquina sin tu aplicación de por medio.
Si has caído en el primer caso, hay herramientas para encontrar al culpable. Con X-Ray, desde cPanel, ves qué funciones y qué plugins se comen el tiempo de cada petición. El modo debug de WordPress te saca los errores que se están tragando en silencio, y si ves avisos de memoria agotada puedes subir el límite modificando el php.ini. Y si te interesa entender qué hace el servidor web con tus peticiones, lo contamos en qué es LiteSpeed Web Server.
Cuando acabes, borra el archivo prueba.html.
Hasta aquí has ido descartando. Si has llegado con el servidor como principal sospechoso, estas son las señales que lo confirman. Cada hosting pone límites de CPU, RAM, procesos simultáneos y velocidad de disco a cada cuenta (aquí tienes los que asignamos a cada plan), y casi todos estos síntomas son alguno de esos límites tocando techo:
memory_limit al máximo que te permite tu plan. Ahí ya no es configuración, es que el plan no da más RAM.Y si tu diagnóstico ha salido «es mi web», ninguna de estas cinco te aplica. Cambiar de proveedor no te va a servir.
Llegados aquí, solo hay tres salidas posibles:
Si vienes de otro proveedor con cPanel, la migración es gratuita si la pides en los 30 días siguientes a contratar, así que no tienes que hacer tú el traslado.
Da igual con qué proveedor estés: si abres un tique diciendo «mi web va lenta», lo primero que te van a pedir son estos datos, y cada ida y vuelta es un día perdido. Rellénala antes de abrir el ticket y lo tendrás resuelto mucho antes.
INFORME DE LENTITUD URL afectada: Fecha y hora exacta del problema (con zona horaria): ¿Es contínuo o intermitente? ¿A qué horas pasa? Mi IP pública de origen: PRUEBA 0 · ¿Solo a mí? ¿Va lenta con datos móviles, sin wifi? (sí / no) ¿Va lenta en una herramienta externa? (sí / no, cuál) PRUEBA 1 · TTFB (página sin caché, mediana de 3 mediciones) TTFB de la página: ms Tiempo de carga total: s PRUEBA 2 · Red Ping al servidor (50 paquetes): media ms · pérdida % WinMTR de al menos 5 minutos (adjunto el TXT exportado) ¿Cloudflare con proxy activo? (sí / no) PRUEBA 3 · Máquina TTFB de un HTML plano en el mismo servidor: ms TTFB de WordPress en el mismo momento: ms Errores que aparecen (508, 500, pantalla en blanco, memoria agotada): Cambios recientes en la web (plugins, tema, tráfico, campañas):
Con el WinMTR, déjalo corriendo al menos cinco minutos (unos 300 paquetes) si el problema es constante, y entre 15 y 30 minutos si va y viene. Luego usa «Export TEXT» y adjunta el archivo al tique. En la guía de WinMTR tienes el paso a paso.
Si ya eres cliente y después de las pruebas sigues sin tenerlo claro, ábrenos un ticket. Nuestro equipo de sistemas la revisa y te dice dónde está el problema, aunque la respuesta sea que el servidor va bien y lo que sobra son tres plugins.
Fran Navoz