Observar frente a intervenir: las dos modalidades
Cada acción en las DevTools o lee el estado o lo modifica, y confundir las dos es la causa silenciosa de la mitad de las sesiones de depuración que no llegan a ninguna parte.
Hay una distinción que las DevTools no señalan en ningún sitio y que ordena todo lo demás: algunas acciones solo miran, y otras cambian el mundo que estás mirando. Editar un estilo, borrar un nodo, evaluar una expresión en la consola o detener la ejecución en un breakpoint son intervenciones, y cada una deja huella. Cuando llevas veinte intervenciones acumuladas ya no estás depurando la página del usuario: estás depurando una página que solo existe en tu pestaña, y cualquier conclusión que saques de ahí es sospechosa.
- Clasificar cualquier acción de las DevTools como observación o como intervención.
- Enumerar los efectos laterales de las intervenciones más frecuentes y su ámbito de persistencia.
- Aplicar la disciplina de recarga limpia entre hipótesis y saber cuándo se puede saltar.
- Reconocer las cuatro intervenciones que contaminan una medición de rendimiento.
Qué cuenta como intervención
La lista es más larga de lo que parece, porque varias acciones que se sienten pasivas no lo son.
Son intervenciones evidentes editar una declaración en el panel de estilos, editar un nodo como HTML, arrastrar un nodo a otro sitio, borrarlo, ocultarlo con la tecla H, cambiar un valor en el panel de scope mientras estás detenido, y ejecutar cualquier expresión en la consola que tenga efectos.
Son intervenciones menos evidentes forzar un estado de pseudo-clase, porque cambia qué reglas casan y puede disparar transiciones; activar la emulación de dispositivo, porque recarga con otro tamaño de ventana y otro user-agent; y activar el throttling, porque cambia el orden en que llegan las respuestas y por tanto el orden en que se ejecuta tu código.
Y hay una intervención que casi nadie contabiliza como tal: detenerse en un breakpoint. Mientras el hilo principal está pausado, el reloj del mundo real sigue corriendo. Los setTimeout no se ejecutan pero acumulan retraso, las peticiones en vuelo pueden completarse, y las conexiones pueden expirar. Un await fetch(...) que resuelve mientras estás parado tres minutos en un breakpoint produce un orden de eventos que jamás ocurriría en producción. Depurar código con condiciones de carrera a base de breakpoints es la forma más eficiente conocida de perseguir un bug que tú mismo has creado.
Detenerse en un breakpoint dentro de un manejador de eventos de entrada tiene otro efecto lateral raro: el navegador puede considerar que la página no responde y aplicar comportamientos de recuperación. Si el bug que persigues involucra el manejo de gestos o de teclado, el logpoint es casi siempre mejor herramienta que la pausa.
El ámbito de persistencia de cada cambio
No todas las intervenciones duran lo mismo, y saber cuánto dura cada una evita dos errores contrarios: creer que un cambio se ha guardado cuando no, y creer que se ha perdido cuando sigue ahí estropeándote la siguiente prueba.
| Intervención | Sobrevive a | Se pierde al |
|---|---|---|
| Editar un estilo o un nodo | Nada | Recargar |
Escribir en localStorage desde la consola |
Recargar y cerrar la pestaña | Borrarlo o cambiar de perfil |
| Registrar un service worker | Recargar y cerrar el navegador | Desregistrarlo explícitamente |
| Ajustes de las DevTools | Recargar y reiniciar | Restaurar valores por defecto |
| Breakpoints | Recargar y reiniciar | Borrarlos |
| Throttling, caché desactivada, emulación | Recargar | Cerrar las DevTools |
| Overrides locales | Todo, incluso reiniciar | Desactivarlos o borrar la carpeta |
La fila de los overrides merece un aviso: es la única intervención que sigue aplicándose sin que haya ninguna señal visual llamativa, y ha causado desconciertos memorables. Alguien sobrescribe un fichero para probar un fix, se olvida, y una semana después está depurando por qué la aplicación no coge la versión nueva de ese fichero. La respuesta lleva siete días en su disco.
La fila de los service workers merece otro. Un service worker registrado sirve respuestas desde su caché sin que la petición aparezca como venida de la red, y sobrevive a la recarga y al cierre del navegador. Es, con diferencia, la causa número uno de “he desplegado y no veo los cambios”.
La disciplina de la recarga limpia
De todo lo anterior sale una regla operativa simple: una hipótesis, una recarga. Cada vez que vayas a comprobar una idea nueva, parte de un estado conocido. Si no lo haces, tus resultados dependen del orden en que hiciste las pruebas anteriores, y ese orden es irrepetible.
El estado conocido tiene tres niveles, de más barato a más caro.
Una recarga normal basta cuando las únicas intervenciones fueron ediciones en Elements o expresiones sin efectos en la consola.
Una recarga forzada —Cmd+Shift+R en macOS, Ctrl+Shift+R en Windows y Linux— hace falta cuando sospechas de la caché. Con las DevTools abiertas, mantener pulsado el botón de recargar ofrece además la opción de vaciar la caché y recargar, que es más agresiva.
Una ventana de incógnito es el estado limpio de verdad: almacenamiento vacío, sin service workers registrados, y sin extensiones si no las has habilitado explícitamente para incógnito. Es el desempate definitivo de “funciona en mi máquina”, y cuesta dos segundos.
Cuándo sí se puede saltar la disciplina: cuando estás en fase de exploración, no de verificación. Los primeros minutos de mirar una página desconocida son legítimamente sucios; toqueteas, expandes, pruebas. El momento de imponer la disciplina es cuando pasas de “a ver qué hay aquí” a “creo que el problema es X”. A partir de ahí, cada comprobación parte de cero o no vale.
El fallo más caro de esta lección no es intervenir: es intervenir y olvidarlo. Las DevTools no llevan un registro visible de lo que has tocado, y el panel de estilos no distingue con suficiente fuerza entre una regla que venía del fichero y una que escribiste tú hace un rato. El resultado es una clase de bug particularmente cruel: pasas media hora entendiendo por qué un elemento se comporta de una manera que es imposible según el código, y la respuesta es que tú mismo le pusiste un position: relative en element.style a los cinco minutos de empezar y se te olvidó. Hay dos hábitos que lo evitan, y ninguno cuesta nada. El primero es recargar antes de creerte cualquier conclusión: si el comportamiento sobrevive a una recarga limpia, era real; si desaparece, era tuyo. El segundo es no editar nunca en element.style cuando estés investigando: crea una regla nueva con el selector explícito, que se ve muchísimo mejor en el panel y que además te obliga a pensar en el selector, que suele ser donde está el problema. La regla general que resume ambos: durante la fase de diagnóstico, intervén lo mínimo posible; guarda las intervenciones para la fase de comprobar el arreglo, que es cuando sí sabes qué estás cambiando y por qué.
Las cuatro intervenciones que arruinan una medición
Cuando lo que estás haciendo es medir y no diagnosticar, el listón sube. Cuatro cosas invalidan una medición de rendimiento y las cuatro son fáciles de dejarse activadas.
Breakpoints activos, aunque no se disparen. El motor renuncia a optimizaciones cuando hay un depurador enganchado con puntos de parada, y los números dejan de parecerse a los de producción. El panel de breakpoints tiene un interruptor para desactivarlos todos sin borrarlos; úsalo antes de grabar.
La consola llena. Miles de líneas con objetos expandibles retienen memoria y ralentizan el frontend. Limpiar la consola antes de grabar es gratis.
Extensiones. Muchas inyectan scripts en cada página, y algunas son notoriamente caras. Un perfil tomado con seis extensiones activas mide tus extensiones. La ventana de incógnito resuelve esto también.
El propio panel de Network grabando con la conservación del log activada durante media hora. La instrumentación no es gratis y la memoria acumulada tampoco.
Estas cuatro no son supersticiones: son la diferencia entre un perfil que te dice algo de tu código y un perfil que te dice algo de tu entorno de desarrollo. La lección siguiente cierra el nivel con el método completo que ordena observación e intervención en una secuencia repetible.