Los niveles de log y el filtrado que hace la consola usable
Los cinco niveles, qué implica cada uno, el filtro por texto y por regex, y cómo convertir una consola con diez mil líneas en una con las tres que importan.
La consola de una aplicación real en desarrollo produce cientos de líneas por minuto entre tu código, tus dependencias, los avisos de los frameworks y los mensajes del navegador. Sin filtrado, el mensaje que necesitas está ahí y no lo vas a ver nunca. El sistema de niveles existe precisamente para eso, y la mayoría de la gente lo desaprovecha porque escribe todo con console.log y luego se queja del ruido que ella misma produjo.
- Usar los cinco niveles de log con criterio y saber qué implica cada uno.
- Filtrar la consola por nivel, por texto, por expresión regular y por negación.
- Reconocer los mensajes que emite el navegador y distinguirlos de los tuyos.
- Reducir el ruido de una consola sin perder información relevante.
Los cinco niveles
console.debug es el nivel más bajo. Está oculto por defecto: los mensajes emitidos con él no aparecen salvo que actives el nivel detallado en el filtro. Eso lo convierte en la herramienta correcta para la instrumentación que quieres dejar en el código pero no ver siempre: trazas de flujo interno, valores intermedios, marcas de ciclo de vida. Es la diferencia entre borrar tus trazas al terminar y dejarlas donde estaban por si vuelven a hacer falta.
console.log es el nivel informativo genérico y el que se usa para todo, lo cual es exactamente el problema.
console.info es, en la práctica, indistinguible de log en Chrome: se agrupa con él en el filtro. Su valor es semántico, no visual.
console.warn aparece con fondo amarillo, icono de aviso y traza de pila plegable. Ese último detalle es el que lo hace útil de verdad: un aviso te dice de dónde salió sin que tengas que añadir un console.trace.
console.error aparece con fondo rojo, también con traza de pila, y además contribuye al contador de errores que se ve en la esquina de las DevTools incluso con el panel cerrado. Emitir un error con console.error no lanza ninguna excepción ni interrumpe nada: solo lo registra.
La traza de pila que acompaña a warn y error respeta la lista de scripts ignorados, así que si tienes bien configurado el filtrado de librerías, esa traza apunta directamente a tu código en vez de a diez marcos internos del framework. Es una de las sinergias más útiles entre dos funciones que parecen no tener relación.
Los filtros
El filtro por nivel
El desplegable de niveles de la barra de la consola permite marcar y desmarcar cada uno. Las combinaciones que se usan de verdad son tres.
Solo errores y avisos, para revisar la salud de una página sin leer nada más. Es lo primero que hay que hacer al abrir una aplicación desconocida.
Solo detallado, que muestra únicamente los debug, para seguir tu propia instrumentación sin el ruido de todo lo demás.
Todo, para investigar de verdad.
Cuando algún nivel está desmarcado, la barra lo indica. Merece la pena fijarse, porque el “no sale ningún mensaje” más frecuente es un filtro de nivel que quedó puesto de otra sesión.
El filtro por texto y por expresión regular
El campo de filtro acepta tres sintaxis.
Texto plano, que casa por subcadena contra el mensaje completo, incluidos los objetos serializados.
Expresión regular entre barras: /pedido|factura/ muestra solo los mensajes que mencionen alguna de las dos palabras. Se pueden usar banderas.
Negación con guion delante: -webpack oculta todos los mensajes que contengan esa palabra. Es lo que salva la consola cuando una dependencia emite un aviso por cada módulo.
Y hay un cuarto filtro implícito que mucha gente no conoce: en el desplegable de contexto se puede limitar la consola a un origen concreto, lo que oculta los mensajes de los iframes y de las extensiones.
Los mensajes que no son tuyos
Buena parte de lo que aparece en una consola real no lo has emitido tú. Distinguir su procedencia ahorra investigaciones inútiles.
Los errores de red aparecen automáticamente cuando una petición falla, con el código de estado. No los ha emitido tu código; los emite el navegador.
Las violaciones de política de seguridad de contenido, los avisos de recursos bloqueados por modo mixto y los de cookies rechazadas también son del navegador y suelen indicar un problema de configuración del servidor, no del frontend.
Los avisos de funciones obsoletas llevan un enlace a la documentación y una fecha estimada de retirada. Merecen atención porque el plazo suele ser corto.
Las infracciones de rendimiento —mensajes sobre manejadores que tardaron demasiado, o sobre uso de propiedades que fuerzan reflow— son avisos del propio motor. Están ocultas por defecto en algunas versiones y hay un nivel de filtro específico para ellas.
Y los mensajes de las extensiones, que llegan con el origen de la extensión y que son la razón principal para depurar con un perfil limpio.
Usar los niveles con criterio
La propuesta que convierte la consola en una herramienta en vez de un vertedero. Es una convención, no una regla del lenguaje, y funciona.
| Nivel | Para qué | Se queda en el código |
|---|---|---|
debug |
Trazas de flujo interno, valores intermedios | Sí, oculto por defecto |
log |
Salida deliberada que quieres ver siempre en desarrollo | Solo si es útil de verdad |
info |
Hitos del ciclo de vida de la aplicación | Sí |
warn |
Algo raro que no impide continuar | Sí, siempre |
error |
Algo falló y hay que enterarse | Sí, siempre |
La consecuencia de aplicarla es que la instrumentación deja de ser desechable. Si tus trazas de investigación van en debug, no hay que borrarlas: quedan ahí, invisibles, y la próxima vez que ese módulo dé problemas se reactivan con un clic en el filtro. Eso convierte cada sesión de depuración en una inversión en vez de en un gasto.
Hay una razón técnica para preferir debug y el filtrado a llenar el código de log, y no es de estilo. Cada llamada a la consola tiene un coste que se paga aunque el mensaje esté filtrado. El argumento se evalúa siempre: si escribes console.debug('estado', estructurarDatos(x)), la función se ejecuta aunque el mensaje no se muestre nunca, porque JavaScript evalúa los argumentos antes de llamar. Y hay un segundo coste, más insidioso: los objetos pasados a la consola quedan retenidos. El frontend guarda una referencia para poder expandirlos bajo demanda, así que un objeto logueado no se puede recoger mientras esa línea siga en la consola. Un bucle que loguea nodos del DOM o instancias de un componente construye una fuga que solo existe con las DevTools abiertas, y que estropea cualquier análisis de memoria posterior. Hay un tercer coste que aparece en código caliente: cuando la consola está conectada, las llamadas no se optimizan igual, así que una traza dentro de un bucle de render o de un manejador de scroll altera precisamente lo que estás midiendo. La conclusión práctica tiene tres partes. Primera, nunca pases estructuras grandes a la consola en código que se ejecute muchas veces; pasa un resumen, o una copia serializada con structuredClone si necesitas la foto del instante. Segunda, usa logpoints en vez de trazas siempre que puedas, porque no tocan el código, no se olvidan dentro y se quitan de golpe. Y tercera, la que más gente ignora: limpia la consola antes de medir cualquier cosa, porque la memoria retenida por miles de líneas de log es real y contamina tanto los perfiles de rendimiento como los snapshots de memoria.