Idea central: depurar en el navegador no consiste en abrir todos los paneles de DevTools y esperar que alguno revele la respuesta. Consiste en convertir un síntoma en una pregunta comprobable y elegir la herramienta que puede aportar esa evidencia.
Imagina una página con un botón que debería guardar un formulario. El usuario hace clic, pero no aparece ningún mensaje, no cambia la pantalla y tampoco ves una petición en el servidor. La reacción más común es añadir varios console.log(), revisar el CSS, recargar la página y abrir la pestaña Network al mismo tiempo. El resultado suele ser una colección de pistas desconectadas. El navegador tiene mucha información, pero tú todavía no tienes una hipótesis.
Ese cambio de enfoque importa más que memorizar atajos. La documentación de MDN sobre las herramientas de desarrollo del navegador muestra que DevTools sirve para observar HTML y CSS en tiempo de ejecución, ejecutar JavaScript, pausar el código y revisar los recursos solicitados. Son capacidades diferentes porque responden preguntas diferentes. La depuración mejora cuando respetas esa diferencia.
El síntoma no te dice todavía qué panel abrir
Un fallo visible es el final de una cadena, no su explicación. “El botón no funciona” puede significar que el botón no existe en el DOM que se está renderizando, que una regla CSS impide hacer clic, que el evento no está conectado, que el manejador se interrumpe con una excepción o que la petición se envía y el servidor responde con un error. Cinco causas pueden producir la misma frase del usuario.
Por eso conviene describir el fallo con tres preguntas concretas:
| Pregunta | Evidencia que buscas | Primer lugar razonable |
|---|---|---|
| ¿El elemento que veo es realmente el que recibe el evento? | HTML, clases, estilos aplicados y estados como :hover o :focus. | Inspector o Elements. |
| ¿El código llega a ejecutar el manejador? | Errores, valores y punto exacto donde la ejecución se detiene. | Console y Debugger. |
| ¿La aplicación intenta comunicarse con un servidor? | URL, método, código HTTP, cabeceras y respuesta. | Network. |
Esta tabla no pretende crear una nueva lista para memorizar. Su utilidad está en el orden de las preguntas. Antes de buscar una respuesta, define qué observación podría descartar una causa. Si el clic ni siquiera llega al manejador, mirar el código de respuesta del servidor es prematuro. Si la petición existe y devuelve 401, modificar el color del botón no resolverá el problema.
Primero congela la evidencia, no la borres con otra recarga
Una depuración improvisada suele alterar el escenario. Se recarga la página, se elimina el mensaje de error de la consola, se modifica una línea y después se intenta recordar qué ocurría antes. El navegador deja de ser un testigo y se convierte en una escena que cambia cada minuto.
Empieza con una reproducción mínima. Anota la URL, los pasos exactos y el resultado observable: “abrir la página, escribir un correo, pulsar Guardar; el formulario permanece visible y no aparece una petición”. Abre DevTools y reproduce una sola vez. No cambies código todavía. Si el problema depende de una interacción, comprueba si se repite; si no se repite, registra qué condición era distinta.
También conviene observar qué ocurre antes del clic. En el Inspector puedes comprobar si el elemento tiene la clase esperada, si está cubierto por otro elemento y qué estilos calculados recibe. MDN explica que el Inspector permite editar temporalmente HTML y CSS para ver el efecto al instante, pero esos cambios no se guardan en el proyecto. Esa característica convierte al panel en un laboratorio: sirve para probar una hipótesis, no para reparar el archivo sin saber por qué funcionó.
Por ejemplo, si un botón parece visible pero no responde, activa el estado :hover o inspecciona el modelo de caja. Una capa con position, un z-index inesperado o pointer-events: none pueden explicar el síntoma. Si al quitar temporalmente esa regla el clic vuelve a funcionar, has encontrado una relación causal. Todavía falta decidir dónde corregirla, pero ya no estás adivinando.
Cuando la página no cambia: separa estructura, estilo y evento
El primer recorrido debe contestar si la página que ves corresponde al código que creías haber escrito. El HTML del servidor, el DOM final y el panel de elementos no siempre son la misma cosa: JavaScript puede crear, eliminar o modificar nodos después de cargar el documento.
Selecciona el botón y revisa tres detalles. Primero, confirma que el selector que usa tu código coincide con el elemento real. Segundo, busca si el botón está deshabilitado o si el formulario se encuentra dentro de otro elemento que intercepta el evento. Tercero, observa las reglas CSS activas y las que aparecen tachadas. La diferencia entre una declaración escrita y una declaración ganadora explica muchos “no funciona” visuales.
Este método conecta con la distinción entre estructura y comportamiento que se desarrolla en la guía de HTML, CSS y JavaScript. HTML aporta los nodos, CSS decide cómo participan visualmente y JavaScript puede leerlos o cambiar su estado. Un problema de interacción puede cruzar las tres capas, así que no conviene atribuirlo automáticamente al lenguaje que estabas editando.
Haz una prueba simple en la consola con el elemento seleccionado. Si el navegador ofrece una referencia como $0, puedes comprobar propiedades y clases del nodo sin modificar todavía el código fuente:
console.log($0);
console.log($0.disabled);
console.log($0.className);
El objetivo no es convertir la consola en un segundo editor, sino verificar si la aplicación está trabajando con el objeto que tú imaginas. Si $0 es un botón distinto del que devuelve document.querySelector(), el problema puede estar en un selector demasiado amplio o en una página que renderiza componentes duplicados.
Cuando JavaScript se detiene: la Console muestra el “qué”, el Debugger el “cómo”
La Console es adecuada para detectar errores, probar expresiones pequeñas y observar valores. También puede ejecutar JavaScript contra la página cargada, algo útil para comprobar si un selector devuelve null o si una función existe en el momento esperado. Pero un mensaje como Cannot read properties of null te dice que una operación falló; no siempre te muestra la secuencia de decisiones que llevó hasta allí.
Ahí entra el Debugger. La documentación del JavaScript Debugger de Firefox lo describe como una herramienta para recorrer el código y examinar o modificar su estado. Un breakpoint detiene la ejecución antes o después de una línea relevante. Mientras la aplicación está pausada puedes mirar variables locales, la pila de llamadas y el alcance disponible, en vez de imprimir valores en muchos lugares.
Supón que el manejador recibe un objeto de usuario, pero el mensaje final nunca aparece. Un console.log(user) puede confirmar que el objeto existe. Un breakpoint en la línea que construye el mensaje permite comprobar si el campo se llama email, correo o si llega vacío. Si la función fue llamada por otro componente, la pila de llamadas también revela qué ruta condujo hasta el punto de fallo.
Una regla práctica ayuda a elegir: usa Console para una pregunta corta (“¿qué valor tiene esta variable?”) y Debugger para una pregunta de trayectoria (“¿en qué decisión se perdió este valor?”). Los atajos de teclado pueden acelerar la navegación una vez que sabes qué quieres observar; la guía de atajos de VS Code es útil para el editor, pero no sustituye la hipótesis que debe guiar la investigación.
Cuando una petición desaparece: Network no es un detector universal
Si el código debería llamar a una API, abre Network antes de reproducir el problema y limpia el registro solo si ya sabes qué evento vas a observar. La pestaña registra recursos mientras está abierta. Al recargar o pulsar el botón, cada fila te permite revisar estado HTTP, tipo de recurso, iniciador, tamaño y tiempo. La guía práctica de Chrome DevTools sobre actividad de red recomienda usar este panel para comprobar si los recursos se suben o descargan y para inspeccionar sus propiedades.
La primera distinción es entre “no hubo petición” y “hubo petición con respuesta problemática”. Si no aparece ninguna fila, vuelve al código: el evento quizá no se ejecutó, una validación detuvo el flujo o una excepción ocurrió antes de fetch(). Si aparece una petición, filtra por el tipo que esperas y abre sus detalles.
| Señal | Hipótesis inicial | Siguiente comprobación |
|---|---|---|
| 404 | La ruta o el recurso no existe en esa dirección. | Revisar URL, ruta base y archivo solicitado. |
| 401 o 403 | La petición llega, pero la autenticación o autorización falla. | Inspeccionar cabeceras y permisos sin exponer secretos. |
| 500 | El servidor recibió la solicitud y falló al procesarla. | Leer la respuesta y revisar logs del backend. |
| Solicitud pendiente | El servidor no terminó, la conexión se bloqueó o el flujo espera otra cosa. | Revisar Timing, cancelación y condiciones de la interfaz. |
Hay una advertencia importante: Chrome señala que Network no debe ser el primer lugar para todo problema de rendimiento, porque muchas causas no pertenecen a la actividad de red y Lighthouse puede ofrecer recomendaciones más dirigidas. La herramienta correcta depende de la pregunta, incluso dentro de DevTools.
Un circuito de diagnóstico que puedes repetir
Cuando el fallo sea confuso, recorre este circuito sin saltarte etapas:
- Describe el síntoma. Sustituye “no funciona” por una observación que otra persona pueda repetir.
- Comprueba el DOM y los estilos. Asegúrate de que el elemento existe, tiene el estado esperado y no está bloqueado por la presentación.
- Busca el primer error. La primera excepción de la Console suele ser más informativa que los mensajes posteriores que produce la interrupción.
- Decide entre imprimir y pausar. Si basta con un valor, usa Console; si necesitas seguir una trayectoria, pon un breakpoint.
- Comprueba el límite con el servidor. Solo después de confirmar que el flujo llega a la llamada, interpreta Network y su código HTTP.
- Reproduce después del cambio. Una corrección no se valida porque desapareció un mensaje; se valida porque el escenario original deja de fallar y no introduce otro comportamiento.
La secuencia parece más lenta que abrir cinco pestañas a la vez, pero reduce el número de hipótesis simultáneas. También produce una explicación que puedes compartir: “el evento sí se ejecutaba; el selector devolvía el nodo equivocado; por eso no se enviaba la petición”. Ese relato es mucho más valioso que “lo arreglé después de tocar varias cosas”.
El resultado de depurar es una explicación, no solo una línea corregida
Las herramientas de desarrollo no existen para reemplazar el razonamiento, sino para hacerlo observable. Inspector, Console, Debugger y Network son cuatro formas de mirar el mismo sistema desde ángulos distintos. El error no se vuelve pequeño porque encuentres un panel conocido; se vuelve tratable cuando puedes relacionar un síntoma con una causa y una prueba.
Si quieres practicar el siguiente paso, compara esta forma de investigación con la guía sobre errores comunes de JavaScript y con el artículo de propiedades CSS esenciales. La pregunta útil no es qué panel debes memorizar, sino qué evidencia falta para dejar de adivinar.
Dudas que aparecen al investigar un fallo en el navegador
¿Debo empezar siempre por la Console?
No siempre. Es un buen punto de partida si sospechas una excepción o quieres comprobar valores, pero un elemento que no recibe clic puede requerir primero el Inspector. Si el problema es que no se carga un recurso, Network aporta evidencia más directa.
¿Los cambios hechos en Inspector modifican mi proyecto?
No. Son modificaciones temporales del DOM o de los estilos que el navegador está mostrando. Sirven para probar una hipótesis y ver un efecto, pero debes trasladar la corrección al archivo fuente y volver a probar desde un estado limpio.
¿Cuándo conviene usar un breakpoint en lugar de muchos mensajes?
Cuando necesitas entender el orden de ejecución, el valor de varias variables o la función que llamó al código que falla. Para una comprobación aislada, un mensaje puede ser suficiente; para una trayectoria compleja, pausar suele conservar mejor el contexto.
¿Qué significa que no aparezca ninguna petición en Network?
Que el flujo no produjo una solicitud durante el periodo observado, no necesariamente que el servidor esté caído. Revisa si el evento se ejecutó, si una validación canceló el proceso o si una excepción ocurrió antes de la llamada de red.
Martin Rojas escribe sobre tecnología, programación y desarrollo web. En Skydutz Academy comparte explicaciones prácticas sobre herramientas digitales, conceptos de programación y recursos para aprender de forma progresiva. Su objetivo es hacer que los temas técnicos sean más claros, útiles y accesibles para lectores de distintos niveles.