Visor de Archivos HAR
Visualiza y analiza el contenido de archivos HAR.
Descripción general
Un archivo HAR es un registro en JSON de todo lo que cargó el navegador, exportado desde DevTools. Es preciso y prácticamente ilegible a ojo. Este visor lo convierte de nuevo en la cascada que estabas mirando en DevTools, para que puedas leer una captura que te ha mandado otra persona sin abrir su navegador.
Cada barra se divide en las fases que el navegador registró de verdad: tiempo bloqueado en la cola, DNS, conexión, handshake TLS, espera del primer byte y descarga. Una barra larga que es casi toda TTFB es un problema de servidor; una barra larga que es casi toda descarga es un problema de tamaño de carga útil.
Cómo se usa
- En DevTools, abre Network, haz clic derecho sobre la lista de peticiones y elige Save all as HAR.
- Suelta aquí el archivo, o haz clic para buscarlo. Nada sale de la página.
- Filtra por tipo de recurso y haz clic en una fila para ver su URL y el desglose completo por fases.
- Lee TRANSFER BY TYPE para descubrir qué domina realmente el peso de la página.
Cómo leer las fases
Los seis segmentos los registra el navegador, no se derivan de ningún cálculo, y cada uno señala a un responsable distinto del problema.
| Fase | Qué mide | De quién es la culpa si es larga |
|---|---|---|
blocked | En cola en el navegador, esperando un hueco de conexión | De la página: demasiadas peticiones en paralelo, o HTTP/1.1 |
dns | Resolución del nombre | Del proveedor de DNS, o de una caché fría en la primera visita |
connect | Handshake TCP | De la distancia de red hasta el origen |
tls | Handshake TLS | De la longitud de la cadena de certificados, o de no reanudar sesión |
ttfb | Espera después de enviar la petición | Del servidor. Casi siempre tiempo de aplicación o de base de datos |
download | Recepción del cuerpo | Del tamaño de la carga útil, o del ancho de banda |
Un valor de -1 significa que el navegador no registró esa fase, lo cual es
normal: una petición que reutiliza una conexión existente no tiene dns,
connect ni tls en absoluto. La herramienta omite esos segmentos en lugar de
dibujarlos como cero.
Hay dos patrones que vale la pena aprender a reconocer. Una fila donde domina
blocked mientras muchas filas comparten el mismo host es contención de
conexiones: la solución es hacer menos peticiones o usar HTTP/2, no un servidor
más rápido. Una fila donde domina ttfb en la petición del documento significa
que todas las demás barras de la captura arrancan tarde; nada de lo que viene
después puede ser más rápido que ese número.
Cómo leer la forma de la cascada
La posición horizontal de cada barra importa tanto como su anchura. Las peticiones se colocan sobre una línea de tiempo compartida, así que una escalera significa serialización: cada petición no pudo empezar hasta que terminó otra anterior. Las causas habituales son una hoja de estilos que bloquea el renderizado, un script síncrono que bloquea el parser, o una respuesta JSON que contiene las URL de la siguiente ronda de peticiones.
Las marcas DCL y LOAD vienen de los tiempos de página de la propia captura.
Las peticiones que quedan a la derecha de LOAD no afectaron al evento de
carga: imágenes perezosas, balizas de analítica, prefetches. Las peticiones que
quedan a la izquierda de DCL están en la ruta crítica, lo pretendieras o no.
Qué se enmascara en pantalla
El visor muestra los valores de cabeceras y parámetros para que puedas depurar
con ellos, con una excepción: los valores cuyo nombre parece una credencial —
Cookie, Authorization, token, api_key, signature, code, state — se
muestran enmascarados. Eso es una protección frente a miradas por encima del
hombro, no una frontera de seguridad. El archivo que tienes en el disco sigue
igual y sigue conteniendo todos los secretos.
Si necesitas una versión que puedas adjuntar a una incidencia o enviar a un proveedor, usa el saneador de HAR. Reescribe el JSON —vaciando los arrays de cookies, los cuerpos de petición y de respuesta, los destinos de redirección y las tramas WebSocket— y te devuelve un archivo que se puede compartir.
Ejemplos
- Primer pintado lento: busca un segmento TTFB ancho en la petición del documento; el coste está en el servidor, no en la red.
- Página demasiado pesada: la barra de transferencia normalmente deja claro que las imágenes o un único bundle de JS se llevan la mayoría de los bytes.
- Despliegue roto: filtra por
jsy busca 404 que hayan quedado de una referencia obsoleta. - Un tercero del que te habías olvidado: ordena por host en el desglose de transferencia. Los gestores de etiquetas suelen arrastrar más cosas de las que esperaba quien los añadió.
- «A mí me va rápido, al usuario lento»: compara su captura con la tuya. Las
diferencias en
dnsyconnectson geografía; las diferencias enttfbsobre el mismo endpoint son casi siempre estado de caché.
Notas
Los tamaños se toman del tamaño transferido de la captura cuando existe, con retroceso al cuerpo más las cabeceras y después al tamaño de contenido decodificado, en ese orden, porque cada exportador rellena campos distintos.
El tipo de recurso se deduce primero de la extensión de la URL y después del
tipo MIME, porque una página de error devuelve text/html incluso para una
petición que pretendía ser un script.
Las capturas de navegadores distintos no son directamente comparables. Firefox y
Safari rellenan campos opcionales diferentes, y Chrome añade entradas no
estándar _initiator y _webSocketMessages. Este visor lee los campos estándar
e ignora el resto, así que una captura de Firefox se dibuja con menos detalle en
lugar de fallar.
Si no tienes una captura a mano, load sample capture abre un HAR sintético pequeño para que veas cómo se lee el panel. Son datos de demostración, etiquetados como tales en la cabecera: no es una medición real.