En una frase
Un archivo HAR es un log en formato JSON de la interacción de un navegador web con un sitio, que captura cada una de las peticiones y respuestas de red con un detalle minucioso para su posterior análisis.
El problema que resuelve
Imagina esto: un usuario al otro lado del mundo te manda un DM: "Tu app está tan lenta que no se puede usar". La pruebas. Va como un rayo. Te dicen que está rota. Tú dices que en tu máquina funciona. Punto muerto.
Este es el clásico "él dijo, ella dijo" del desarrollo web. Antes de las herramientas de navegador modernas, debuggear problemas de red remotos era una pesadilla de adivinanzas, de bucear en los logs del servidor y de pedirle a usuarios no técnicos que describieran mensajes de error esotéricos. Incluso con la llegada de las DevTools del navegador y su gloriosa pestaña de Red (Network), el problema persistía: los datos eran efímeros. No podías simplemente "embotellarlos" y enviárselos a un colega. Una captura de pantalla de un diagrama de cascada no cuenta toda la historia.
Aquí entra el formato HTTP Archive, o HAR. Concebido por el Grupo de Trabajo de Rendimiento Web (Web Performance Working Group) del W3C, fue diseñado para ser un formato estándar y compartible para, bueno, archivar transacciones HTTP. Es el equivalente digital de poner una grabadora de caja negra en el navegador de un usuario.
Un archivo HAR resuelve el problema de "en mi máquina funciona" al capturar la conversación de red completa entre un navegador y un servidor para la carga de una página web determinada. Graba cada petición de una imagen, un script, una fuente o una llamada a una API. Registra los headers exactos que se enviaron, las cookies que se intercambiaron, las redirecciones que se siguieron y, lo más importante, los tiempos precisos de cada etapa de la petición.
Esto permite que un desarrollador en San Francisco vea exactamente lo que experimentó un usuario en Singapur, milisegundo a milisegundo, sin tener que adivinar. Hace que los bugs de red transitorios y difíciles de reproducir sean analizables y convierte las quejas vagas de "lentitud" en datos procesables.
Cómo funciona por dentro
En el fondo, un archivo HAR no es magia. Es solo un archivo JSON grande y estructurado. Puedes abrir uno en un editor de texto y verlo todo, aunque un visor dedicado hace que sea infinitamente más fácil de analizar. Echemos un vistazo por dentro.
La estructura principal: es solo JSON
Un archivo HAR contiene un único objeto JSON de nivel superior con una clave: log. Todo lo demás vive dentro de este objeto log.
{
"log": {
"version": "1.2",
"creator": { "name": "Chrome", "version": "118.0.0.0" },
"browser": { "name": "Chrome", "version": "118.0.0.0" },
"pages": [ /* ... uno o más objetos de página ... */ ],
"entries": [ /* ... uno o más objetos de petición/respuesta ... */ ]
}
}
version: La versión de la especificación HAR, generalmente "1.2".creator/browser: Metadatos sobre qué herramienta y navegador generaron el archivo. Útil para el contexto.pages: Un array que describe la página o páginas principales que se cargaron. Incluye el título de la página y los tiempos para eventos de alto nivel comoonLoadyonContentLoad.entries: Esta es la estrella del show. Es un array largo donde cada objeto representa una única petición de red y su correspondiente respuesta.
La estrella del show: el array entries
Cuando analizas un archivo HAR, pasas el 99% de tu tiempo en las entries. Cada entrada es un dossier completo sobre un recurso.
Aquí hay un vistazo simplificado a una sola entrada:
{
"startedDateTime": "2023-10-27T10:30:05.123Z",
"time": 258.45,
"request": { /* ... detalles de la petición ... */ },
"response": { /* ... detalles de la respuesta ... */ },
"timings": { /* ... el jugoso desglose de rendimiento ... */ },
"pageref": "page_1"
}
startedDateTime: La marca de tiempo UTC exacta en que comenzó la petición.time: El tiempo total transcurrido para la petición en milisegundos, de principio a fin.request: Un objeto que contiene todo lo que el navegador envió al servidor.response: Un objeto que contiene todo lo que el servidor devolvió.timings: La mina de oro para el debugging de rendimiento. Desglosaremos esto a continuación.pageref: Un ID que vincula esta petición a una de laspagesen el array de páginas.
Anatomía de una petición y una respuesta
Los objetos request y response son un reflejo de lo que verías en las DevTools.
El objeto request detalla:
method:GET,POST,PUT, etc.url: La URL completa del recurso.headers: Un array de todos los headers de la petición, comoUser-Agent,Accept, yCookie.queryString: Un array de cualquier parámetro de consulta en la URL.postData: Para peticionesPOST, esto contiene el payload, como datos de formulario o un cuerpo JSON.
El objeto response detalla:
status: El código de estado HTTP (por ejemplo,200,404,500).statusText: La frase de motivo (por ejemplo,OK,Not Found).headers: Un array de todos los headers de la respuesta, comoContent-Type,Cache-ControlySet-Cookie.content: Un objeto que describe el cuerpo de la respuesta, incluyendo susize,mimeTypey, a menudo, el cuerpo mismo en la propiedadtext(aunque esto puede omitirse para ahorrar espacio o por seguridad).
El desglose de tiempos del diagrama de cascada
El objeto timings es lo que alimenta el colorido diagrama de cascada en un visor de HAR. Desglosa el time total de la petición en sus fases constituyentes. Entender estas fases es clave para diagnosticar "por qué" una petición fue lenta.
| Timing | Qué significa |
|---|---|
blocked |
Tiempo que la petición pasó esperando en la cola del navegador antes de poder siquiera empezar. A menudo se debe a los límites de conexión. |
dns |
Tiempo dedicado a la búsqueda de DNS. Un valor alto podría indicar un proveedor de DNS lento. |
connect |
Tiempo que se tarda en establecer una conexión TCP con el servidor. Incluye el tiempo de ssl. |
ssl |
(Parte de connect) Tiempo para el handshake de SSL/TLS. Valores altos pueden apuntar a problemas de configuración del servidor o de la red. |
send |
Tiempo dedicado a enviar la petición HTTP al servidor. Normalmente es muy corto. |
wait |
Time To First Byte (TTFB). El más crítico. Tiempo de espera a que el servidor procese la petición y envíe el primer byte de la respuesta. Un tiempo de wait largo es casi siempre un problema del backend. |
receive |
Tiempo dedicado a descargar el cuerpo de la respuesta desde el servidor. Un tiempo de receive largo en un archivo pequeño podría indicar una red lenta; en un archivo grande, es lo esperado. |
El time total para una entrada es la suma de estos tiempos individuales (no negativos). Cuando un visor de HAR te muestra una barra para una petición, está apilando visualmente estos valores de timings uno tras otro.
Historias del mundo real
El caso de la lentitud misteriosa
Un PM frenético le escribe al equipo: "¡La nueva página de checkout está súper lenta para nuestro cliente más grande! ¡Amenazan con irse!". El equipo de desarrollo prueba el flujo de checkout. Va como un rayo. El cliente insiste en que tarda 20 segundos en confirmar un pedido. En lugar de un inútil ida y vuelta, el lead dev guía al cliente para que exporte un archivo HAR.
Al abrir el archivo, el problema es instantáneamente obvio. En las entradas, la petición POST a /api/v1/finalize_order tiene un time total de 20,145ms. Mirando el objeto timings, el wait (TTFB) supera los 20,000ms. El servidor backend está tardando 20 segundos en responder. Resulta que este cliente específico tenía un historial de pedidos masivo, y una consulta a la base de datos no optimizada estaba agotando el tiempo de espera, pero solo para su cuenta. El archivo HAR proporcionó la prueba irrefutable que apuntaba directamente a un proceso específico del backend.
La lección: Un archivo HAR captura condiciones específicas del usuario (como los datos de su cuenta) que no puedes replicar, convirtiendo un misterio en un reporte de bug específico.
El culpable del bundle hinchado
Un sitio de marketing se lanza y la tasa de rebote está por las nubes. Simplemente se siente pesado. Un desarrollador front-end abre el sitio, abre las DevTools, graba una sesión y exporta el HAR.
En el visor de HAR, ordenan las entradas por tamaño. En la parte superior está main.acb123.js con la friolera de 5.2 MB. El diagrama de cascada muestra que es un recurso que bloquea el renderizado; nada aparece en la página hasta que este mastodonte haya terminado de descargarse. El tiempo de receive por sí solo es de varios segundos, incluso con una conexión rápida. Peor aún, al mirar los headers de response de esta entrada, ven que el servidor no está enviando un header Content-Encoding: gzip, a pesar de que el navegador envía Accept-Encoding: gzip en los headers de la request. El bundle de JavaScript no se estaba comprimiendo.
La lección: Los archivos HAR hacen que sea trivialmente fácil detectar asesinos del rendimiento como assets de gran tamaño y configuraciones incorrectas del servidor que están masacrando el tiempo de carga de tu página.
El bucle de redirección infinito
Un usuario se queja de que no puede iniciar sesión. Ingresa sus credenciales, hace clic en "Iniciar sesión" y es devuelto inmediatamente a la página de login sin ningún error. Es un bucle clásico. El equipo de soporte le pide al usuario un archivo HAR del intento de inicio de sesión.
La lista de entries en el HAR cuenta una historia clara:
- Un
POST /logintiene éxito y obtiene una redirección302 Redirecta/dashboard. La respuesta incluye un headerSet-Cookiecon el token de sesión. - El navegador sigue la redirección y hace una petición
GET /dashboard. - El servidor responde a
GET /dashboardcon una redirección302 Redirectde vuelta a/login.
¿Por qué? El desarrollador inspecciona la entrada de la petición GET /dashboard. Al header Cookie le falta el token de sesión. Luego revisa la respuesta del POST /login inicial. El header Set-Cookie era session_id=...; Secure; HttpOnly. El flag Secure significa que el navegador solo enviará la cookie por HTTPS. El usuario estaba en un entorno http://staging.example.com. El navegador se negaba correctamente a enviar la cookie segura a través de una conexión no segura, por lo que el servidor nunca lo vio como conectado.
La lección: Los archivos HAR te dan una repetición perfecta, fotograma a fotograma, de las redirecciones HTTP y los intercambios de headers, lo que hace posible debuggear flujos de autenticación complejos que fallan silenciosamente.
Errores y trampas comunes
- Olvidar marcar "Preserve log". Si tu bug implica pasar de la página A a la página B, debes habilitar la opción "Preserve log" (o equivalente) en las DevTools. De lo contrario, el log se borra al navegar, y tu archivo HAR solo contendrá las peticiones de la página B.
- Compartir datos sensibles. Los archivos HAR son grabadoras indiscriminadas. Capturarán claves de API, tokens de sesión en las cookies e información de identificación personal en los cuerpos de las peticiones POST. Siempre sanitiza los archivos HAR antes de compartirlos en bug trackers públicos o foros.
- Malinterpretar el tiempo de
blocked. Un tiempo deblockedalto no siempre significa que la red esté congestionada. Los navegadores tienen un límite de cuántas conexiones paralelas abrirán a un único dominio (generalmente 6). Si lanzas 20 peticiones de imágenes a la vez, 14 de ellas se quedarán en estadoblocked, esperando que una de las primeras 6 termine. - Ignorar el estado de la caché. Si estás probando el rendimiento de la primera carga, necesitas grabar con la caché del navegador desactivada. De lo contrario, verás un montón de respuestas
304 Not Modifiedo peticiones que se completan en menos de un milisegundo, lo que no refleja la experiencia de un usuario nuevo.
Por qué debería estar en tu radar
Deberías pensar en usar un archivo HAR siempre que la comunicación de red sea una posible sospechosa.
- Cuando un usuario reporta un problema de rendimiento que no puedes reproducir.
- Cuando necesitas optimizar una página de carga lenta y quieres identificar los mayores cuellos de botella.
- Cuando estás debugueando un flujo de API de varios pasos, como un login con OAuth o un proceso de pago, y necesitas ver la secuencia exacta de eventos.
- Cuando necesitas presentar un reporte de bug a un servicio de terceros (como un CDN o un proveedor de API) y quieres proporcionarles una prueba irrefutable del problema. Un archivo HAR es el lenguaje universal de los problemas de red.
Para profundizar
- HAR 1.2 Specification: La especificación original y de facto que define la estructura de los archivos HAR.
- Google Chrome DevTools: Network features reference: Una guía a fondo de la herramienta que se usa más comúnmente para generar archivos HAR.
- MDN Web Docs: Lista de solicitudes de red: La excelente documentación de Mozilla sobre cómo interpretar las peticiones de red en las DevTools de Firefox.
- What is a HAR File?: Un buen resumen de alto nivel sobre cómo generar y usar archivos HAR para solucionar problemas.