Cómo comprobar la velocidad de un sitio web

La vía rápida: ejecutar una prueba con un navegador real

Introduce la URL en una prueba de velocidad de página y deja que cargue la página en un navegador real en lugar de estimarla. Un buen informe te da una captura de pantalla de lo que se renderizó, los tiempos generales, y un desglose por petición que muestra qué imagen, script o llamada de terceros fue lenta. Ese desglose es lo que convierte "la página va lenta" en "este archivo de fuente concreto bloquea el renderizado durante 1,8 segundos".

Ejecútala justo después de un despliegue, después de una actualización de plugin o tema, y antes de comprometerte con un cambio de hosting o de CDN. Esos son los momentos en que cambia la velocidad y nadie se da cuenta.

Medirlo tú mismo desde la línea de comandos

Para la parte del servidor de la historia no necesitas un navegador en absoluto. curl puede imprimir su propio desglose de tiempos:

curl -o /dev/null -sS -w   "dns:%{time_namelookup}s connect:%{time_connect}s tls:%{time_appconnect}s ttfb:%{time_starttransfer}s total:%{time_total}s\n"   https://example.com/

Esto mide una sola petición solo del documento HTML, así que siempre parecerá más rápido que la página real. Precisamente por eso es útil: aísla el servidor del navegador. Si ttfb es alto aquí, ninguna optimización de imágenes va a ayudar. Si ttfb es bajo y la página se sigue sintiendo lenta, el problema está en lo que tiene que hacer el navegador después de que llegue el HTML.

Qué significan TTFB, LCP y la carga completa

• Tiempo hasta el primer byte (TTFB). Cuánto tardó el servidor en empezar a responder, incluyendo DNS, establecimiento de conexión, TLS y el propio procesamiento del servidor. Un TTFB alto señala al hosting, a las consultas de base de datos o al código del backend, no a los recursos de la página.
• Largest contentful paint (LCP). Cuándo terminó de renderizarse el elemento visible más grande de la ventana, normalmente una imagen destacada, el fotograma de un vídeo o un bloque grande de texto. Es el número más cercano a lo que un visitante llamaría "cuándo apareció la página". Google trata 2,5 segundos o menos como bueno.
• Carga / tiempo de carga completa. Cuándo terminó el navegador de cargar el documento y sus recursos bloqueantes. Casi todo lo que puede ver el visitante normalmente ya está listo mucho antes de esto.
• Tiempo total hasta asentarse. El tiempo de carga más lo que siga ejecutándose después, como scripts que obtienen datos una vez que la página parece terminada. Una página puede parecer acabada y seguir ocupada, y ese trabajo compite con el primer desplazamiento o clic del visitante.
• Peticiones y bytes transferidos. Cuántos archivos obtuvo la página y cuánto se descargó. Estas son las palancas detrás de casi todos los números de arriba.

Léelos juntos. Un TTFB bajo con un LCP alto significa que el navegador está haciendo demasiado: demasiadas peticiones, scripts que bloquean el renderizado, o una imagen destacada enorme. Un TTFB alto con todo lo demás normal significa que el cuello de botella es el servidor, incluso antes de que entre en juego el navegador.

Por qué una prueba desde un sitio engaña

Es normal probar la misma URL dos veces y obtener dos resultados distintos, y ninguno está mal. Tres cosas explican la mayor parte de la dispersión:

• La distancia. Una prueba ejecutada cerca del servidor tiene un camino de red más corto que una ejecutada en otro continente. Si tus visitantes están en Europa y pruebas desde la misma ciudad que tu servidor, estás midiendo el mejor caso, no el típico.
• El perfil del dispositivo. Una prueba puede emular un dispositivo móvil con una ventana más pequeña, un user agent distinto y una conexión limitada. Una página ajustada para escritorio puntúa muy distinto bajo emulación móvil, a propósito.
• La caché y el calentamiento. La primera petición puede toparse con una caché fría en la CDN o en la aplicación; la segunda se sirve en caliente. Ejecuta una página dos o tres veces y usa el patrón, no la única ejecución más rápida.

Aun así merece la pena ejecutar una sola prueba. Solo significa que un número lleva significado únicamente junto con las condiciones bajo las que se midió.

Cómo leer una cascada

La cascada es la línea de tiempo por petición, una barra por archivo, ordenadas por cuándo empezaron. Cuatro formas aparecen una y otra vez:

1. Una primera barra larga antes de que empiece nada más. Eso es el TTFB del HTML, y todo lo demás se pone en cola detrás.
2. Una escalera donde cada petición empieza solo cuando termina la anterior. Es una cadena de dependencias, normalmente un script que carga otro script que carga el contenido real. Las cadenas son la forma más cara del gráfico.
3. Una barra ancha en medio de un dominio de terceros. Anuncios, widgets de chat, analítica y fuentes suelen estar aquí, y un tercero lento retrasa tu propia página si se carga de forma síncrona.
4. Un racimo denso de barras diminutas. Docenas de archivos pequeños, cada uno con su propio coste de conexión. Menos archivos, más grandes y en caché suelen ganar a muchos pequeños.

Las barras en rojo o con códigos 4xx y 5xx merecen atención aunque la página parezca bien, porque una petición fallida sigue costando tiempo antes de fallar.

Detectar una ralentización que nadie fue a buscar

Una sola prueba te dice cómo se comportó la página una vez, desde un sitio, en un perfil de dispositivo. Eso es lo que quieres al depurar algo concreto. No es lo que quieres cuando el objetivo es simplemente notar una ralentización: las páginas se hacen más pesadas una actualización cada vez, y nadie ejecuta una prueba manual un martes tranquilo. La monitorización programada de velocidad de página ejecuta la misma prueba desde las mismas ubicaciones con un intervalo, guarda el historial, y avisa cuando los números cruzan un umbral. Ejecuta una ahora con la prueba de velocidad de página, y consulta tiempo de respuesta del servidor si la parte lenta resulta ser el servidor.