El mapa de los paneles: cuatro familias, no veinte pestañas
Una ontología de las DevTools que agrupa los paneles por la pregunta que responden, para que dejes de recordar nombres y empieces a recordar competencias.
La lista de pestañas de las DevTools crece con cada versión de Chrome y se reordena sin avisar. Aprenderla de memoria es trabajo perdido: en un año la mitad estarán en otro sitio. Lo que no cambia es la estructura conceptual que hay debajo, porque responde a las capas reales del navegador. Hay exactamente cuatro preguntas que puedes hacerle a una página, y cada panel es una herramienta para responder una de ellas.
- Clasificar cualquier panel de las DevTools en una de las cuatro familias por la pregunta que responde.
- Explicar por qué esas cuatro familias se corresponden con capas reales del navegador.
- Nombrar el panel primario y el secundario de cada familia y decir cuándo se pasa de uno a otro.
- Ubicar un panel nuevo que no habías visto sin necesidad de leer su documentación.
Las cuatro preguntas
Toda depuración web es una de estas cuatro preguntas, formulada con más o menos precisión.
¿Qué hay? Es la pregunta sobre el estado presente de la página: qué nodos existen, qué estilos tienen, qué guarda el almacenamiento, qué cachés hay pobladas. Es una pregunta de fotografía. La respuesta es un estado, no un proceso.
¿Qué está pasando? Es la pregunta sobre la ejecución del código: qué función se está ejecutando, con qué valores, quién la llamó, por qué se lanzó esa excepción. Es una pregunta de control de flujo, y su respuesta natural es detener el tiempo.
¿Qué entra y sale? Es la pregunta sobre la frontera con el exterior: qué peticiones se hacen, en qué orden, cuánto tardan, qué devuelven. El navegador es un cliente de red antes que ninguna otra cosa, y una parte enorme de los problemas vive exactamente ahí.
¿Cuánto cuesta? Es la pregunta sobre los recursos: cuánto tiempo de CPU, cuánta memoria, cuántos fotogramas perdidos. Es una pregunta de agregados, no de instantes, y por eso sus herramientas graban en vez de mirar.
flowchart TB raiz[Las DevTools] --> q1[Que hay] raiz --> q2[Que esta pasando] raiz --> q3[Que entra y sale] raiz --> q4[Cuanto cuesta] q1 --> el[Elements] q1 --> ap[Application] q2 --> so[Sources] q2 --> co[Console] q3 --> ne[Network] q3 --> sw[Service Workers] q4 --> pe[Performance] q4 --> me[Memory] q4 --> li[Lighthouse] style raiz fill:#cba6f7,color:#11111b style q1 fill:#89b4fa,color:#11111b style q2 fill:#a6e3a1,color:#11111b style q3 fill:#f9e2af,color:#11111b style q4 fill:#fab387,color:#11111b style el fill:#94e2d5,color:#11111b style ap fill:#94e2d5,color:#11111b style so fill:#94e2d5,color:#11111b style co fill:#94e2d5,color:#11111b style ne fill:#94e2d5,color:#11111b style sw fill:#94e2d5,color:#11111b style pe fill:#94e2d5,color:#11111b style me fill:#94e2d5,color:#11111b style li fill:#94e2d5,color:#11111b
Las cuatro familias
Familia 1: la estructura
Aquí viven Elements y Application, y comparten una propiedad que los distingue de todo lo demás: no graban nada. Muestran el estado actual y lo actualizan cuando cambia. Si el bug ya pasó, esta familia no te sirve.
Elements responde por el árbol del documento y por todo lo que cuelga de él: los nodos, los atributos, las reglas de estilo que casan con cada uno y en qué orden, la geometría de las cajas, el árbol de accesibilidad derivado. Es el panel donde más tiempo pasa cualquiera que escriba interfaces, y también el que más se usa mal, porque la tentación de tocar valores hasta que algo cuadre es enorme y casi nunca es el camino corto.
Application responde por el estado persistente: cookies, localStorage, sessionStorage, IndexedDB, la Cache API, el manifiesto de la aplicación, los service workers registrados, la cuota consumida. Su valor no está en poder leer una clave —eso lo haces desde la consola en un segundo— sino en poder borrar con precisión quirúrgica para reproducir el estado de un usuario nuevo sin destruir el resto de tu sesión.
Familia 2: la ejecución
Sources y Console son los dos extremos de la misma competencia: intervenir en el código que se ejecuta.
Sources es el panel de control del tiempo. Contiene el código realmente cargado, permite detenerlo en un punto arbitrario y avanzar paso a paso, y da acceso al estado congelado en ese instante: variables locales, closures, la pila de llamadas completa. Es la herramienta más potente de todo el conjunto y la que menos gente usa bien, porque exige formular una hipótesis antes de mirar y eso es más incómodo que salpicar el código de trazas.
Console es el panel de la evaluación. Ejecuta expresiones arbitrarias en el contexto de la página —o en el del marco donde estés detenido, que es una distinción crítica— y muestra la salida del programa. Su punto fuerte no es leer trazas, es preguntar: escribir una expresión, ver el resultado, refinarla. La consola bien usada es un REPL de investigación, no un visor de logs.
Los Snippets, que técnicamente viven dentro de Sources, pertenecen a esta familia y merecen su propio nivel: son consola guardada.
Familia 3: la frontera
Network es el panel más rentable por unidad de esfuerzo de aprendizaje de todo el conjunto. Registra cada petición que sale del documento, con su cronología descompuesta, sus cabeceras, su cuerpo, su iniciador y su prioridad. La mayoría de la gente lo usa para comprobar que una llamada devuelve un 200 y para poco más, y eso es como usar un microscopio de pisapapeles.
La pestaña de service workers de Application y el bloqueo de peticiones del cajón inferior también pertenecen a esta familia, porque operan sobre la misma frontera: el service worker es un intermediario que puede responder sin salir a la red, y el bloqueo es una tijera que corta el cable a voluntad.
Existe un patrón de fracaso tan común que casi es una ley: la gente busca el bug en la familia donde tiene más comodidad, no en la familia donde está el bug. Quien viene del CSS se pasa cuarenta minutos en Elements probando propiedades cuando el problema es que la API devolvió un array vacío. Quien viene del backend abre Network y revisa cabeceras cuando el problema es que un useEffect se dispara dos veces. Quien vive en la consola pone treinta trazas cuando un único breakpoint condicional habría dado la respuesta en un minuto. El sesgo es tan fuerte que la mejor heurística que conozco es deliberadamente contraintuitiva: cuando lleves quince minutos sin avanzar, cambia de familia antes que de idea. No pruebes otra hipótesis dentro del mismo panel; formula la misma pregunta desde otra familia. Si llevas quince minutos en Elements, abre Network. Si llevas quince minutos en Network, pon un breakpoint. El cambio de familia reencuadra el problema, y reencuadrar es lo que rompe el atasco.
Familia 4: el coste
Performance, Memory y Lighthouse comparten un rasgo que los separa del resto: no responden a “qué pasa” sino a “cuánto”. Y para responder a cuánto hay que agregar, y para agregar hay que grabar. Por eso los tres tienen un botón de inicio y otro de parada, y por eso ninguno sirve para mirar de reojo.
Performance graba la actividad del hilo principal y de los hilos auxiliares durante un intervalo, con muestreo de la pila y con eventos del navegador anotados en pistas paralelas. Memory hace fotografías del montón de JavaScript y permite compararlas. Lighthouse ejecuta una batería de auditorías automatizadas contra una carga controlada.
El error clásico con esta familia es interpretar sus números como absolutos. Son medidas de tu máquina, con tu perfil de Chrome, con las DevTools abiertas y por tanto con el navegador trabajando más de lo normal. Sirven para comparar dos versiones de tu código, que es para lo que se hicieron. No sirven para decir cuánto tarda tu página en el móvil de un usuario.
Los paneles que no encajan y por qué
Quedan piezas sueltas, y su ubicación en el mapa es un buen ejercicio. La pestaña de Rendering del cajón inferior no es un panel de familia: es un conjunto de interruptores que modifican cómo el navegador pinta y cómo se presenta ante el CSS. Encaja donde la uses. Coverage mide qué porcentaje del código descargado se ejecuta, así que pertenece a la familia del coste aunque su salida sea una lista de ficheros. Animations captura y edita animaciones en vivo, y aunque parezca de estructura es en realidad de ejecución: manipula una línea temporal. El Recorder graba interacciones para reproducirlas, lo que lo convierte en una herramienta de automatización más que de diagnóstico.
Cuando aparezca una pestaña que no conoces, la pregunta que la coloca en el mapa es siempre la misma: ¿esto me dice qué hay, qué pasa, qué cruza la frontera, o cuánto cuesta? Con esa respuesta ya sabes cuándo abrirla, que es la única parte que importa. La lección siguiente convierte el mapa en un árbol de decisión que va del síntoma al panel.