Leer la forma de la cascada
Las seis siluetas características de un waterfall, qué problema indica cada una, y cómo diagnosticar una carga entera mirando la forma antes que ningún número.
La lectura más rápida y más informativa del panel de red no está en ninguna columna: está en la silueta que dibujan las barras vistas en conjunto. Una cascada escalonada significa una cosa muy concreta, un bloque de barras que empiezan a la vez significa otra, un muro de barras de espera larga significa una tercera. Esas formas se reconocen en tres segundos y cada una apunta a un tipo de problema distinto. Aprender a leerlas es lo que convierte el panel de red de una lista en un diagnóstico.
- Reconocer las seis siluetas características de un waterfall y su causa.
- Diagnosticar una cadena de dependencias a partir del escalonado.
- Distinguir un límite de conexiones de una saturación de ancho de banda.
- Identificar los huecos donde no hay actividad de red y qué los produce.
Las formas de dependencia y de paralelismo
Forma 1: la escalera
Silueta. Cada barra empieza aproximadamente donde termina la anterior. El conjunto dibuja una diagonal descendente limpia.
Qué significa. Una cadena de dependencias: cada recurso no se puede pedir hasta que el anterior ha llegado y se ha procesado. El documento carga un script, el script pide un módulo, el módulo pide datos, los datos determinan qué imagen pedir.
Por qué es el peor patrón. La duración total es la suma de todas las latencias, no el máximo. Cinco eslabones con doscientos milisegundos de ida y vuelta cada uno son un segundo, y en móvil con latencias mayores puede ser el triple. Y no hay ninguna optimización de tamaño que lo arregle: aunque cada recurso pesara cien bytes, la escalera seguiría durando lo mismo.
Qué se hace. Romper eslabones. Descubrir los recursos antes con preload, incrustar lo crítico en el documento, colapsar dos peticiones en una, o mover la decisión al servidor. La longitud de la cadena crítica es la métrica que hay que reducir, no el número de peticiones ni los bytes.
Cómo confirmarlo. Recorriendo las peticiones con la tecla de mayúsculas pulsada, la cadena de iniciadores se ilumina y se ve exactamente qué depende de qué.
Forma 2: el bloque simultáneo
Silueta. Muchas barras que empiezan casi en el mismo instante y se extienden en paralelo.
Qué significa. Depende de qué haya dentro de las barras, y aquí es donde hay que mirar el desglose.
Si las barras son cortas y todas del mismo tamaño, buen paralelismo. Es la forma sana y no hay nada que hacer.
Si las barras son largas y la mayor parte de cada una es descarga, el ancho de banda está saturado: todas compiten por el mismo canal y todas van despacio. Esto se reconoce porque al reducir el número de peticiones simultáneas, cada una acelera.
Si las barras son largas y la mayor parte es espera, el servidor está saturado: aceptó todas las conexiones y está tardando en responder a todas.
Cómo distinguir los dos últimos. La columna de tamaño. Si la suma de bytes en vuelo es grande, es ancho de banda. Si son respuestas pequeñas que tardan, es el servidor.
Forma 3: el escalón de seis
Silueta. Seis barras arrancan a la vez, y cuando la primera termina arranca la séptima, y así sucesivamente. El resultado es un patrón de bloques de seis.
Qué significa. El límite de conexiones simultáneas por origen de la primera generación del protocolo, que son seis. Las peticiones séptima en adelante esperan en cola a que se libere una conexión.
Es inconfundible una vez lo has visto, y la columna de protocolo lo confirma en un segundo.
Qué se hace. Migrar a la segunda generación del protocolo, que multiplexa muchas peticiones sobre una sola conexión y elimina el límite por completo. Es, con diferencia, la intervención de red con mejor relación entre esfuerzo y resultado que existe, y en muchos casos es una casilla en la configuración del servidor o del CDN.
La solución antigua —repartir los recursos entre varios subdominios— sigue funcionando y es contraproducente con el protocolo moderno, porque cada dominio adicional paga su propio establecimiento de conexión.
Las formas de espera y de silencio
Forma 4: el muro de espera
Silueta. Todas las barras tienen un tramo de espera larguísimo y un tramo de descarga minúsculo. Visualmente, un bloque de color uniforme seguido de una línea fina.
Qué significa. El servidor tarda en responder. Los bytes son pocos y llegan rápido cuando llegan; el problema es que tardan en empezar.
Cómo acotar. Compara con un recurso estático del mismo origen. Si el estático responde rápido, el problema está en el trabajo que hace el servidor para esa ruta concreta: una consulta sin índice, una llamada a otro servicio, un cálculo pesado. Si el estático también tarda, es infraestructura: el servidor está lejos, está saturado, o hay un intermediario lento.
Qué se hace. Nada en el frontend. Es una conversación con backend o con infraestructura, y el dato del desglose es lo que la hace productiva.
Forma 5: los huecos
Silueta. Zonas del waterfall donde no hay ninguna barra. La red está en silencio.
Qué significa. Es la forma más informativa de todas porque el problema no está en la red. Si el navegador no está pidiendo nada, es porque está haciendo otra cosa: parseando y ejecutando un script grande, calculando estilos, haciendo layout, o esperando a que un temporizador se dispare.
Qué se hace. Cambiar de panel. Un hueco en el waterfall es la señal inequívoca de que el diagnóstico continúa en el análisis del hilo principal, y seguir optimizando red es tiempo perdido.
El caso particular de los huecos al principio. Un hueco entre el documento y la primera oleada de subrecursos indica que el parser se detuvo, normalmente en un script bloqueante sin defer ni async colocado en la cabecera.
Forma 6: la cola larga
Silueta. El grueso de las peticiones termina pronto y después hay una serie dispersa que se extiende durante segundos.
Qué significa. Actividad posterior a la carga: analítica, píxeles de seguimiento, precarga especulativa, sondeo periódico, carga diferida de imágenes.
Por qué importa menos de lo que parece. Esas peticiones no bloquean nada visible y su efecto sobre la experiencia es indirecto: consumen ancho de banda y tiempo de hilo principal que podrían ir a otra cosa. El número de “terminado” de la barra de resumen se dispara por su culpa y asusta más de lo que debería.
Cuándo sí importa. Si esa cola compite con recursos que sí son visibles —porque la analítica se carga antes que las imágenes del contenido— entonces el problema es de prioridades y sí hay que actuar.
Hay un orden de lectura del waterfall que ahorra muchísimo tiempo y que casi nadie sigue, porque el instinto es empezar ordenando por duración y mirar la petición más lenta. Ese instinto falla por una razón concreta: la petición más lenta casi nunca es la más importante. Un fichero de vídeo que tarda ocho segundos en descargarse mientras la página funciona perfectamente no es un problema; una petición de doscientos milisegundos que bloquea el renderizado de todo el contenido sí lo es. La duración no dice nada sobre el impacto. El orden correcto tiene tres pasos y ninguno mira números al principio. Paso uno: mira la primera barra. La petición del documento contiene el tiempo hasta el primer byte del servidor, y si ese número es alto, todo lo demás está desplazado y no hay nada que optimizar en el frontend hasta que se arregle. Es un vistazo y descarta o confirma la mitad de las hipótesis posibles. Paso dos: mira la silueta del conjunto, sin leer nada, buscando cuál de las seis formas de esta lección reconoces. La forma te dice qué tipo de problema tienes, y por tanto qué columna mirar después: escalera manda a la cadena de iniciadores, bloque largo manda a los tamaños, muro de espera manda a hablar con backend, huecos mandan a otro panel. Paso tres, y solo entonces, mira los números de la columna que la forma te ha indicado. Hacerlo en este orden significa que cuando llegas a los números ya sabes qué estás buscando, y eso convierte una tabla de sesenta filas en tres cifras relevantes. Hacerlo al revés —ordenar por duración y empezar a leer— produce media hora de mirar peticiones sin criterio y, con suerte, la conclusión de que la más lenta es un vídeo que a nadie le importaba.