Del síntoma al panel: el árbol de decisión

La diferencia medible entre alguien que depura rápido y alguien que no está casi toda en los primeros noventa segundos. No en la destreza con el panel, sino en la elección del panel. Quien acierta la primera vez tarda diez minutos; quien empieza mirando el sitio equivocado descubre su error cuando ya lleva cuarenta y ha contaminado el estado de la página con veinte cambios. Esta lección es un árbol de decisión y su tabla, para que el primer movimiento deje de ser un reflejo y empiece a ser una elección.

Las cinco categorías raíz

Todo síntoma reportado por un humano cae en una de cinco cajas. La clasificación no es opinable: depende de si algo se ve, se ve mal, no responde, va lento, o se rompe con el tiempo.

No se ve. El elemento no aparece en pantalla. Puede que no exista en el DOM, que exista con dimensión cero, que esté fuera del área visible, o que esté tapado. Son cuatro causas con cuatro diagnósticos distintos y el árbol las separa en dos preguntas.

Se ve mal. Está ahí, pero con el color, el tamaño, la posición o la tipografía equivocados. Es el territorio nativo de Elements, y casi siempre se resuelve leyendo la cascada real en vez de escribiendo más CSS.

No hace lo que debe. El botón no responde, el formulario no envía, el estado no se actualiza. Es el territorio de Sources y de la consola, y es donde más se pierde el tiempo porque la tentación de instrumentar con trazas es máxima.

Va lento. Tarda en cargar, tarda en responder al clic, salta al hacer scroll. Tres síntomas que la gente agrupa bajo “lento” y que no tienen nada que ver entre sí: el primero es red o arranque, el segundo es el hilo principal ocupado, el tercero es composición.

Se degrada con el uso. Funciona bien al principio y peor con el tiempo. Es el único síntoma que apunta directamente a memoria, y también el único que exige un ciclo de reproducción diseñado antes de medir.

El árbol

flowchart TB
s[Sintoma] --> a{Se ve el elemento}
a -->|No| b{Esta en el arbol del DOM}
b -->|No| n1[Network o Sources]
b -->|Si| e1[Elements estilos y geometria]
a -->|Si pero mal| e2[Elements cascada y computados]
s --> c{Responde a la interaccion}
c -->|No| so1[Sources breakpoints de evento]
c -->|Con datos malos| so2[Network respuesta y Sources]
s --> d{Va lento}
d -->|Al cargar| ne1[Network waterfall]
d -->|Al interactuar| pe1[Performance hilo principal]
d -->|Al hacer scroll| re1[Rendering y capas]
s --> f{Empeora con el tiempo}
f -->|Si| me1[Memory tres snapshots]
style s fill:#cba6f7,color:#11111b
style n1 fill:#f9e2af,color:#11111b
style e1 fill:#89b4fa,color:#11111b
style e2 fill:#89b4fa,color:#11111b
style so1 fill:#a6e3a1,color:#11111b
style so2 fill:#a6e3a1,color:#11111b
style ne1 fill:#f9e2af,color:#11111b
style pe1 fill:#fab387,color:#11111b
style re1 fill:#fab387,color:#11111b
style me1 fill:#f38ba8,color:#11111b

La primera bifurcación del árbol es la que más rendimiento da y la que más gente se salta: antes de mirar por qué algo se ve mal, comprueba si existe. Un Cmd+F en el panel de Elements buscando el texto o el selector del elemento responde en tres segundos y bisecciona el problema en dos mitades que no tienen ninguna herramienta en común. Si el nodo no está en el árbol, todo el CSS del mundo es irrelevante y el problema está en los datos o en la lógica que decide renderizarlo. Si está, el problema es de presentación y Sources no pinta nada.

La tabla de correspondencias

El árbol se despliega en una tabla que conviene tener presente hasta que se automatice. La columna que importa no es la del panel sino la de la primera acción: abrir el panel correcto sin saber qué hacer dentro sirve de poco.

Los tres síntomas ambiguos

Hay tres casos donde el árbol se bifurca de verdad y hace falta un desempate. Merecen conocerse porque son exactamente los que más tiempo consumen.

“El dato no aparece en pantalla.” Puede ser que la petición no devolviera el dato o que el dato llegara y el render lo ignorara. El desempate cuesta cinco segundos: mira la pestaña de respuesta de esa petición en Network. Si el dato está en la respuesta, el problema es tuyo y está en el código de render. Si no está, deja de mirar el frontend. Este único movimiento evita la conversación más larga y más estéril entre frontend y backend.

“Funciona en mi máquina.” Casi siempre es estado persistente o caché. El desempate es abrir una ventana de incógnito, que arranca con almacenamiento vacío, sin service worker registrado y sin extensiones. Si allí falla igual, es código. Si allí funciona, es estado, y Application es tu panel.

“A veces pasa y a veces no.” La intermitencia apunta casi siempre a tiempo: una carrera entre dos operaciones asíncronas, un setTimeout que gana o pierde, una respuesta que llega después de que el componente se desmonte. El desempate es exagerar la asimetría: activa el throttling de red al perfil más lento y el de CPU al máximo. Si con eso el fallo pasa de intermitente a constante, tienes una carrera y ya sabes cuál de las dos ramas gana cuando la red va lenta.

Por qué el orden no se puede alterar

Las preguntas del árbol están ordenadas por coste de respuesta creciente y por poder de bisección decreciente. Comprobar si un nodo existe cuesta tres segundos y parte el espacio de búsqueda en dos. Grabar un perfil de rendimiento cuesta un minuto de grabación más cinco de lectura y no descarta casi nada por sí solo.

Empezar por la pregunta cara es un error doble: gastas el tiempo y además llenas la cabeza de datos que todavía no sabes interpretar porque no has acotado el problema. Un perfil de Performance de una página que no funciona es ilegible; el mismo perfil, cuando ya sabes que la lentitud aparece al pulsar un botón concreto y solo con cien filas en la tabla, se lee en dos minutos.

Ese es el principio general y vale para todo lo que viene después: acotar antes que medir, y medir antes que arreglar. Las lecciones siguientes de este nivel formalizan las dos mitades de ese principio.