Experimentos, canales de Chrome y depurar las propias DevTools
Cómo funcionan las funciones experimentales, por qué desaparecen sin avisar, cuándo compensa depurar en Canary, y cómo inspeccionar el panel con otro panel.
Una parte no despreciable de lo que las DevTools saben hacer está detrás de una casilla en la sección de experimentos, y otra parte solo existe en versiones de Chrome que no son la que tienes instalada. Saber navegar esas dos capas es lo que separa a quien usa la herramienta de hace tres años de quien usa la de este mes. También hay un truco recursivo que resuelve la clase de problema más frustrante que existe: cuando lo que está roto no es tu página, es el propio panel.
- Activar y evaluar una función experimental sabiendo qué garantías tiene y cuáles no.
- Elegir el canal de Chrome adecuado para un trabajo de depuración concreto.
- Mantener perfiles separados para desarrollo y para navegación normal, y justificar por qué.
- Abrir DevTools sobre las propias DevTools para diagnosticar un fallo del panel.
Qué es un experimento y qué no garantiza
La sección de experimentos del diálogo de preferencias contiene una lista de casillas con nombres largos y descripciones escuetas. Cada una activa código que ya está compilado dentro de tu Chrome pero desactivado por defecto, normalmente porque está incompleto, porque el equipo quiere medir si se usa, o porque puede degradar el rendimiento del panel.
Las tres cosas que hay que entender sobre ellos.
No tienen compromiso de estabilidad. Un experimento puede desaparecer en la siguiente versión sin nota de migración, puede graduarse y pasar a ser una función normal, o puede quedarse ahí durante años. No construyas un flujo de trabajo que dependa de uno sin plan alternativo.
Algunos requieren recargar el panel para tomar efecto, y unos pocos requieren cerrarlo y volver a abrirlo. Si activas uno y no notas nada, ese es el primer paso antes de concluir que no funciona.
Algunos cuestan rendimiento, porque añaden instrumentación adicional. Los relacionados con capturar más información de la que las DevTools recogen normalmente entran todos en esta categoría.
La forma robusta de explorarlos es buscar en el propio diálogo por palabra clave, porque la lista es larga y la mayoría de las entradas no te interesan. Las áreas donde históricamente ha habido experimentos valiosos son la accesibilidad —incluido el cálculo alternativo de contraste—, el panel de rendimiento, la depuración de CSS moderno y las integraciones con frameworks.
Un experimento activado es estado invisible: modifica el comportamiento del panel sin ninguna señal visual permanente. Si un día las DevTools se comportan de una forma que no reconoces y no encuentras explicación, la lista de experimentos es de los primeros sitios donde mirar, junto con el botón de restaurar valores por defecto.
Los canales y cuándo compensa cambiar
Chrome se distribuye en cuatro canales que avanzan a distinta velocidad: Stable, Beta, Dev y Canary. Canary se compila a diario, Dev avanza semanalmente, Beta va unas semanas por delante de Stable, y Stable es lo que tienen los usuarios.
Para el trabajo diario, Stable. Los tres casos donde compensa tener otro instalado son concretos.
Cuando persigues un bug del propio navegador. Reproducirlo en Canary responde a la pregunta de si ya está arreglado, que decide si tienes que buscar un rodeo o simplemente esperar.
Cuando quieres usar una función de DevTools que todavía no ha llegado a Stable. El panel avanza rápido y hay funciones que tardan meses en bajar.
Cuando pruebas una API web reciente. Las implementaciones nuevas llegan primero a Canary con la bandera correspondiente.
Los cuatro canales se pueden instalar a la vez en la misma máquina, con perfiles y datos separados. No hay conflicto. Y esa separación lleva al siguiente punto.
Un perfil de navegador para desarrollo
La recomendación con mejor relación entre esfuerzo y beneficio de todo este nivel: usa un perfil de Chrome distinto para desarrollar, o directamente un canal distinto.
El motivo no es el orden. Es que tu perfil personal tiene extensiones, y las extensiones inyectan scripts en las páginas que visitas. Eso tiene cuatro efectos, todos malos para depurar.
Contaminan el panel de Sources con scripts de contenido que no son tuyos. Contaminan la consola con sus mensajes. Contaminan los perfiles de rendimiento con su propio trabajo, a veces con cantidades absurdas. Y en el peor caso, modifican el DOM o interceptan peticiones, produciendo bugs que solo existen en tu máquina y que has intentado explicar durante una hora.
Un perfil limpio, con las DevTools configuradas a tu gusto y sin más extensiones que las estrictamente necesarias, elimina esa clase entera de problemas. La ventana de incógnito consigue algo parecido de forma puntual, pero no conserva tus preferencias ni tus snippets, así que como entorno de trabajo permanente es incómoda.
| Entorno | Extensiones | Estado persistente | Uso recomendado |
|---|---|---|---|
| Perfil personal | Muchas | Todo tu historial y sesiones | Navegar, no depurar |
| Perfil de desarrollo | Ninguna o mínimas | Sesiones de tus entornos | Trabajo diario |
| Incógnito | Ninguna por defecto | Vacío en cada ventana | Desempatar “funciona en mi máquina” |
| Canary | Independiente | Independiente | Verificar bugs del navegador |
DevTools sobre DevTools
Cuando el panel se comporta mal —una pestaña que no carga, un gráfico que no se pinta, un error que aparece en un rincón— la pregunta natural es cómo se depura eso. La respuesta sale de la arquitectura: el frontend es una página web, así que se depura como cualquier otra página web.
El procedimiento tiene dos pasos y hay que hacerlos en orden.
Primero, desacopla las DevTools en su propia ventana, con el atajo de acoplamiento o desde el menú de comandos. Mientras estén acopladas, el atajo de apertura se lo lleva la página.
Segundo, con el foco en la ventana desacoplada, pulsa el atajo de apertura otra vez. Se abre una segunda instancia de DevTools que inspecciona a la primera. Puedes ver su DOM, sus errores de consola, sus peticiones y su código.
Sirve para tres cosas de verdad. Para leer los errores que el propio panel emite cuando algo falla, que suelen decir exactamente qué pasa. Para entender cómo está construida una función que te interesa, porque el código está ahí y es legible. Y para modificar su interfaz en caliente, lo cual es más un juego que una técnica, pero descubre bastante sobre cómo funciona por dentro.
Hay una consecuencia de todo este nivel que no es sobre configuración sino sobre método, y que cambia cómo lees los informes de bugs. Las DevTools y el motor de renderizado avanzan juntos, y eso significa que la herramienta con la que investigas es siempre al menos tan nueva como el navegador donde ocurrió el problema, y normalmente más. Cuando alguien reporta un fallo visual y tú no lo reproduces, hay cuatro hipótesis y solo una es “no existe”: puede que su Chrome sea varias versiones anterior y no tenga la propiedad CSS que estás usando; puede que tenga una extensión que modifica la página; puede que su sistema tenga preferencias de accesibilidad activas que disparan otra rama de tus media queries; o puede que su hardware caiga en otro camino de composición. Ninguna de las cuatro se descubre mirando tu propia pantalla. Por eso la primera pregunta ante un fallo no reproducible no es “¿qué has hecho?” sino “¿qué navegador, qué versión y qué sistema?”, y por eso conviene tener a mano al menos un canal alternativo instalado: te permite probar la hipótesis de versión en dos minutos en vez de descartarla por incómoda. La depuración eficaz no consiste solo en dominar la herramienta; consiste en recordar que tu entorno es uno entre muchos y que el tuyo es, casi siempre, el menos representativo de todos.