Por qué una página se siente lenta cuando todas las métricas del servidor dicen que es rápida

Alguien dice que tu sitio es lento. Abres el panel de control y todo está en verde. Los tiempos de respuesta en cientos de milisegundos bajos, sin errores, sin saturación, nada por encima del umbral en ninguna parte.

Ambos tienen razón, y la razón no es sutil una vez que lo ves: tus métricas del servidor y tu visitante están midiendo dos cosas diferentes, y el solapamiento entre ellas es menor de lo que casi nadie espera.

Dos relojes, iniciados en momentos diferentes

El reloj del servidor comienza cuando llega una solicitud y se detiene cuando termina de escribir una respuesta. Ese intervalo es el que tu monitoreo reporta, y es una medición real de algo real.

El reloj del visitante comienza cuando hace clic, y no se detiene hasta que la página ha dibujado algo que vinieron a buscar. Entre esos dos momentos se encuentran: una búsqueda DNS, una conexión TCP, un apretón de manos TLS, el trabajo de tu servidor, la respuesta viajando de vuelta, el análisis de HTML, las hojas de estilo, las fuentes y los scripts que HTML luego solicita, cada uno de los cuales repite la mayoría de lo anterior, y finalmente la representación.

Tu servidor estuvo involucrado en un solo paso de eso. Una página puede pasar 80 milisegundos en tu servidor y cuatro segundos volviéndose útil, y nada en tu monitoreo de aplicación es incorrecto cuando dice 80 milisegundos.

El número que describe el servidor, y los que describen la experiencia

El número del lado del servidor es Time to First Byte, que Google describe como la medición de “el tiempo entre comenzar a navegar a una página y cuando el primer byte de una respuesta comienza a llegar”. Su orientación es que “la mayoría de los sitios deben esforzarse por tener un TTFB de 0.8 segundos o menos”.

Pero son explícitos sobre sus límites: “Como TTFB no es una métrica de Core Web Vitals, no es absolutamente necesario que los sitios cumplan con el umbral ‘bueno’ de TTFB, siempre que no impida su capacidad de puntuar bien en las métricas que importan.”

Las métricas que importan son las tres Core Web Vitals, y cada una responde una pregunta que una persona realmente reconocería.

Largest Contentful Paint es cuando la cosa más grande en la pantalla termina de dibujarse, lo que es el proxy más cercano de máquina para “la página apareció”. El objetivo es que “LCP debe ocurrir dentro de 2.5 segundos después de que la página comience a cargarse”.

Interaction to Next Paint es cuánto tiempo tarda la página en responder visiblemente después de que alguien interactúe con ella: “las páginas deben tener un INP de 200 milliseconds o menos”. Reemplazó First Input Delay como una métrica estable de Core Web Vitals en 2024, y el cambio importa, porque FID medía solo el retraso antes de que comenzara el procesamiento mientras que INP mide todo el camino hasta la siguiente pintura. Una página que aceptó tu clic al instante y luego se congeló puntuó bien en la métrica anterior.

Cumulative Layout Shift no trata de velocidad en absoluto. Mide cuánto se mueve la página mientras se carga, y el objetivo es “0.1 o menos”. Está en esta lista porque una página que salta bajo tu dedo se siente rota de una manera que se lee para la persona como lenta, incluso cuando no lo era.

El detalle que resuelve la mayoría de estos argumentos

Core Web Vitals se evalúan en “el 75th percentile de cargas de página, segmentado en dispositivos móviles y de escritorio”.

No el promedio. El 75th percentile, lo que significa que una de cada cuatro visitas es peor que el número que estás mirando, y es deliberado: un promedio está dominado por las personas que ya estaban pasándolo bien. Tus propias visitas están en esa mayoría cómoda casi por construcción, ya que estás cerca de tus servidores, en una buena conexión, en una máquina rápida, con una caché caliente.

Entonces, cuando un visitante dice que el sitio es lento y tu panel de control dice que es rápido, la lectura honesta no es que uno de ustedes se equivoque. Es que estás mirando la media de una distribución cuya cola es la queja completa.

Débil

"El sitio es lento." Verificado el panel de control, tiempo de respuesta p50 90ms, cerrando como no reproducible.

Mejor

"Lento en la página de producto, aproximadamente 6 segundos antes de que aparezca algo, en datos móviles." LCP es la métrica; TTFB fue bien, por lo que el tiempo va en alguna parte después de que llega la respuesta.

Dónde va realmente el tiempo

Una vez que aceptas que la brecha es real, hay solo algunos lugares donde se esconde, y son los mismos pocos cada vez.

Recursos de bloqueo de representación. El HTML llegó rápidamente y luego pidió una hoja de estilos, y el navegador no pintará hasta que la tenga. Cada solicitud de bloqueo en el encabezado se suma al tiempo antes de que aparezca algo.

Fuentes. Una fuente web que no está precargada puede dejar el texto invisible o rediseñado mucho después de que el diseño esté terminado, lo que tanto retrasa la pintura más grande como, si cambia de flujo, alimenta el cambio de diseño.

Imágenes sin dimensiones. La causa más común de cambio de diseño. El navegador no puede reservar el espacio, por lo que todo lo que está debajo se mueve cuando llega la imagen.

JavaScript, en un dispositivo lento. Esto es invisible en una máquina de desarrollo por construcción. Analizar y ejecutar un bundle grande cuesta una fracción de segundo en una computadora portátil y varios segundos en un teléfono de rango medio, y la página no responde a toques durante todo el proceso.

La distancia. Un visitante al otro lado del mundo paga el viaje de ida y vuelta varias veces antes de que ni siquiera se le pida a tu servidor rápido, que es la misma razón por la que una degradación ascendente te cae a ti en lugar de a quienquiera que la causó.

Qué pedir en lugar de “¿puedes ser más específico?”

“Es lento” no se puede actuar, pero las tres cosas que lo hacen accionable son todas fáciles de pedir, y ninguna de ellas requiere que el reportero entienda nada de lo anterior.

• Qué página, y qué estaban esperando. Lento en aparecer en absoluto, lento en responder después de un toque, o moviéndose mientras se cargaba. Esas son tres métricas diferentes y tres causas diferentes.
• En qué, y en qué conexión. Un Android de cinco años en datos móviles y un escritorio en fibra no son el mismo sitio.
• Aproximadamente cuánto tiempo, y si siempre es así. La diferencia entre “siempre alrededor de seis segundos” y “a veces se cuelga” es la diferencia entre una página pesada y una falla intermitente, y no comparten soluciones.

Y el que elimina toda adivinanza es un registro de las solicitudes tal como ocurrieron en su máquina, porque el registro de red muestra dónde fueron los segundos en lugar de donde asumes que fueron.

Qué extraer de esto

Un panel de control verde no es evidencia de que el sitio sea rápido. Es evidencia de que la parte que instrumentaste es rápida, y esa parte es un paso en una secuencia que el visitante experimenta completa.

Mide lo que experimentan, en el percentil donde viven los reclamos en lugar de en el promedio, y trata tu propia experiencia de tu propio sitio como el punto de datos menos representativo al que tienes acceso.