Anatomía del panel de red: las columnas que importan
Qué se graba y qué no, la barra de resumen, las cinco columnas que hay que añadir a mano, y las líneas verticales que marcan los hitos de la carga.
El panel de red se usa mayoritariamente para comprobar que una llamada devuelve doscientos, y con la configuración por defecto poco más se puede hacer, porque las columnas que muestra no son las que responden a las preguntas interesantes. Con cinco columnas añadidas y sabiendo leer la barra de resumen y las líneas verticales, el mismo panel pasa a contar la historia completa de cómo se cargó una página.
- Configurar las columnas del panel para que muestren protocolo, prioridad y dominio.
- Leer la barra de resumen y distinguir los cuatro números que da.
- Interpretar las líneas verticales de hitos y qué significan.
- Distinguir el tamaño transferido del descomprimido y usar esa diferencia.
Qué se graba
El panel registra las peticiones mientras está grabando, y por defecto empieza a grabar cuando lo abres. Las peticiones ocurridas antes de abrirlo no aparecen, lo que produce el desconcierto habitual de abrir el panel y ver una lista vacía en una página ya cargada: hay que recargar.
Se registran las peticiones del documento, de los subrecursos, las de fetch y de la API antigua, las de los service workers, las conexiones de WebSocket con sus mensajes, y los eventos enviados por el servidor.
No se registran las peticiones de las extensiones al mundo exterior, ni las que el navegador hace por su cuenta —comprobaciones de seguridad, sincronización— ni las de otras pestañas.
Y hay un caso importante que sí aparece pero significa otra cosa: las respuestas servidas por un service worker desde su caché figuran en la lista aunque no hayan tocado la red, marcadas con un indicador propio y con un tamaño especial en lugar de bytes transferidos.
La conservación del registro entre navegaciones está desactivada por defecto. Para depurar redirecciones, envíos de formulario que navegan y flujos de autenticación con varios saltos, hay que activarla antes; si no, toda la secuencia se pierde y solo verás el último documento.
Las columnas que hay que añadir
El menú contextual de la cabecera de la tabla permite elegir qué columnas se muestran. Las cinco que cambian el panel.
Protocolo. Dice si la petición fue por HTTP de la primera generación, por la segunda o por la tercera. Es determinante para interpretar el waterfall, porque el límite de conexiones simultáneas por origen solo existe en la primera y explica una forma de cascada muy característica.
Prioridad. El navegador asigna a cada recurso una prioridad que decide en qué orden se piden y se envían. Ver esa columna responde a la pregunta de por qué un recurso importante salió el último.
Dominio. Agrupa visualmente y permite ver de un vistazo cuántos orígenes distintos intervienen. Cada dominio nuevo implica al menos una resolución de nombres y un apretón de manos.
Identificador de conexión. Dice qué peticiones compartieron conexión. Es la columna que confirma si la multiplexación está funcionando.
Cabeceras concretas. Se puede añadir una columna por cada cabecera de respuesta que te interese, lo cual convierte el panel en una tabla de auditoría: una columna con la cabecera de caché muestra la política de todos los recursos a la vez, sin abrir ninguno.
Merece la pena activar además las filas grandes, que muestran dos valores por celda: en la columna de tamaño, el transferido y el descomprimido; en la de tiempo, el total y el tiempo hasta el primer byte. Ese segundo número es el que más veces se necesita.
Transferido frente a descomprimido
La distinción más informativa del panel y la que más gente pasa por alto.
El tamaño transferido son los bytes que cruzaron la red, incluida la compresión y las cabeceras. El tamaño de recurso es lo que ocupa el contenido una vez descomprimido.
Tres lecturas.
Si el transferido es mucho menor que el descomprimido, la compresión está funcionando. Un ratio de tres o cuatro a uno es normal en texto.
Si son iguales, el recurso no se comprimió. En un fichero de texto de cierto tamaño, eso es una configuración de servidor que hay que arreglar. En una imagen o un vídeo es normal, porque ya vienen comprimidos.
Si el transferido es cero y el descomprimido no, el recurso vino de la caché. La suma de esos ceros es lo que la caché te está ahorrando.
En la barra de resumen aparecen ambos totales, y la diferencia entre ellos es el titular de cualquier conversación sobre el peso de una página.
La barra de resumen
Al pie del panel hay cuatro números y conviene saber qué mide cada uno.
Peticiones. El total registrado. Un número por encima de cien en una página de contenido suele indicar que hay algo que revisar.
Transferido. Bytes reales por la red, incluidas las cabeceras.
Recursos. Bytes descomprimidos, el peso real de lo que la página maneja.
Terminado. El instante en que la actividad de red cesó. No es lo mismo que la carga: incluye todo lo que se pidió después, incluida la analítica y las peticiones diferidas.
Y dos hitos con su propio color, que también se dibujan como líneas verticales sobre el waterfall.
El evento de contenido del DOM cargado, que marca cuándo el documento terminó de parsearse y los scripts bloqueantes se ejecutaron.
El evento de carga, que marca cuándo terminaron todos los subrecursos iniciales.
Ninguno de esos dos hitos es una métrica de experiencia de usuario. Una página puede disparar el evento de carga con la pantalla en blanco, y otra puede estar perfectamente usable mucho antes. Sirven como referencias temporales para leer el waterfall, no como objetivos.
Navegar la lista
La columna de iniciador y el grafo de dependencias
La columna de iniciador dice qué provocó cada petición: el parser del documento, un script concreto con su línea, una redirección, o el resultado de otra petición.
Y hay una función que muy poca gente conoce y que reconstruye el grafo entero visualmente: manteniendo pulsada la tecla de mayúsculas mientras pasas el cursor sobre una petición, el panel colorea en verde la que la inició y en rojo las que ella misma inició.
En una cascada de sesenta peticiones, recorrerla con esa tecla pulsada enseña en veinte segundos la estructura de dependencias completa: qué depende de qué, dónde están las cadenas largas, y cuál es el recurso del que cuelga todo lo demás. Esa estructura es exactamente lo que la siguiente lección enseña a diagnosticar.
Filtrar por tipo con las pestañas
Sobre la tabla hay una fila de filtros por tipo de recurso: documentos, hojas de estilo, imágenes, scripts, peticiones de datos, fuentes, medios, manifiestos, websockets. Se pueden combinar con la tecla de comando o de control.
Su uso más rentable no es aislar un tipo sino contar. Pulsar en cada categoría y mirar cuántas peticiones y cuántos bytes tiene cada una da el reparto del peso de la página en treinta segundos, y ese reparto decide dónde merece la pena invertir esfuerzo. Optimizar el JavaScript de una página cuyo ochenta por ciento del peso son imágenes es trabajo desperdiciado.
Hay un desajuste de perspectiva que conviene tener presente desde el principio de este nivel, porque decide qué conclusiones puedes sacar de aquí. El panel de red es una vista centrada en los recursos, y la experiencia del usuario es una vista centrada en los píxeles. Un waterfall impecable —pocas peticiones, todas rápidas, buen paralelismo, terminado a los ochocientos milisegundos— es perfectamente compatible con una pantalla en blanco durante cuatro segundos, si resulta que todo el contenido lo pinta un JavaScript que tarda en ejecutarse. Y al revés: un waterfall con setenta peticiones y una cola larga de analítica puede corresponder a una página que se ve completa a los seiscientos milisegundos, porque todo lo importante llegó primero y lo demás es ruido posterior. La consecuencia práctica es una regla de secuencia que evita muchas horas mal invertidas: antes de optimizar nada de lo que veas aquí, comprueba que la red es de verdad el cuello de botella. La comprobación es directa y no requiere ninguna herramienta especial: recarga con el throttling más lento que tengas y observa cuándo aparece el contenido en relación con cuándo termina la actividad de red. Si el contenido aparece mucho después de que la red se calme, tu problema es de ejecución y ningún ahorro de bytes lo va a arreglar. Si el contenido aparece en cuanto llega el último recurso crítico, entonces sí, la red manda y todo lo de este nivel se aplica. Es la misma disciplina de acotar antes de medir que abre esta guía, aplicada al panel donde más fácil es perderse optimizando números que no le importan a nadie.