En algún momento te atascas: la página no carga bien, un dato no aparece, el botón no hace lo que tiene que hacer. La respuesta instintiva de mucha gente es repasar el código línea a línea hasta encontrar algo raro. El desarrollador que trabaja con DevTools abierto resuelve ese mismo problema en un minuto.
Las DevTools del navegador son las herramientas de desarrollo integradas que trae Chrome, Firefox y Edge desde hace años. No tienes que instalar nada. Son tu laboratorio.
Cómo abrirlas#
Tres formas equivalentes:
F12en cualquier página.- Clic derecho sobre cualquier elemento → Inspeccionar.
Ctrl+Shift+Ien Windows/Linux,Cmd+Option+Ien Mac.
Se abren como un panel lateral o inferior que no interfiere con la página. Puedes moverlo donde te venga mejor con el botón de las tres líneas que hay en la esquina de las propias DevTools.
Elements: el DOM en vivo#
El panel Elements te muestra el árbol DOM real que el navegador tiene en memoria ahora mismo. No el fichero HTML que guardaste en disco, sino el resultado después de que el JavaScript lo haya modificado, el servidor lo haya generado y el navegador lo haya interpretado.
En el Navegador por dentro vimos cómo el motor de renderizado construye ese árbol. Aquí lo puedes tocar con las manos:
- Haz clic en cualquier elemento del árbol: la parte de Styles de la derecha muestra todas las reglas CSS que aplican, de dónde vienen y en qué orden (cuál sobrescribe a cuál).
- Haz doble clic en un texto o en un valor de atributo y edítalo directamente: el cambio se refleja en la página al instante.
- Ese cambio es local y temporal. El navegador lo tiene en su memoria pero no toca ningún servidor. Al recargar, desaparece. Esto es ideal para probar si un ajuste de CSS funciona antes de escribirlo de verdad en el código.
La varita de selección (la flecha con un cuadrado, arriba a la izquierda de las DevTools) te permite hacer clic en cualquier elemento de la página para saltar directamente a su nodo en el árbol. Úsala siempre: localizar un elemento manualmente leyendo el HTML es lento y frustrante.
Console: los errores que importan (y, más adelante, tu propio JS)#
El panel Console tiene dos usos que conviene separar en tu cabeza.
Leer lo que ya está ahí. Esto lo aprovechas desde hoy. Cuando algo falla, casi siempre hay un mensaje de error en rojo. Ese mensaje te dice el tipo de error, el fichero y la línea. Léelo antes de tocar nada: TypeError: Cannot read properties of null seguido de un nombre de fichero y una línea es mucho más valioso que intuir dónde está el bug.
Ejecutar JavaScript (un adelanto). La consola es, además, el sitio donde se escribe y se ejecuta JavaScript en el contexto de la página: escribes una orden, pulsas Enter y se ejecuta al instante. Aún no sabes JavaScript, y no hace falta: lo aprenderás en el Nivel 2. Quédate de momento con que la consola es ese campo de pruebas; cuando llegues ahí, volverás a este panel constantemente.
Network: las peticiones de verdad#
Este es el panel que más vas a usar en el trabajo. Muestra cada petición que lanza el navegador para construir la página, con toda la información del viaje.
En el capítulo Qué pasa al escribir una URL describimos el ciclo completo: DNS, petición, cabeceras, código de estado, cuerpo de la respuesta. Network es donde ves todo eso ocurriendo de verdad, en tiempo real.
Para verlo bien, haz esto:
- Abre DevTools y ve al panel Network.
- Recarga la página con
Ctrl+R(oCmd+R). Hazlo con DevTools ya abierto, porque si abres DevTools después de cargar la página, las peticiones ya ocurrieron y no se registraron. - Verás una cascada de filas, una por petición. La primera suele ser el HTML. Después vienen el CSS, los ficheros JavaScript, las fuentes, las imágenes, y finalmente las peticiones de datos que lanza el propio JS (las que devuelven JSON, las que llaman a una API).
Lo que puedes leer de cada fila:
- Name: la URL que se pidió.
- Status: el código de respuesta. Un 200 en verde, un 404 o 500 en rojo.
- Type: si es un documento, un script, una hoja de estilo, una imagen o XHR/fetch (datos JSON).
- Size: cuánto pesó la respuesta.
- Time: cuánto tardó.
Haz clic en cualquier fila para ver el detalle: las cabeceras de la petición, las cabeceras de la respuesta y, en la pestaña Preview o Response, el cuerpo que llegó. Para una petición de datos verás el JSON. Para el HTML verás el texto del documento. Exactamente lo que describimos en teoría, aquí tangible.
El filtro de arriba (All, Fetch/XHR, JS, CSS…) te ayuda a no perderte cuando hay decenas de peticiones. En el día a día lo más útil es filtrar por Fetch/XHR para ver solo las llamadas a la API y encontrar la que devolvió error.
Un vistazo rápido: Application y Performance#
No vas a necesitarlos hoy, pero conviene saber que existen.
Application agrupa todo el almacenamiento local del navegador: localStorage, sessionStorage, cookies e IndexedDB. Cuando más adelante guardes el progreso del quiz en localStorage, podrás venir aquí a ver exactamente qué está guardado y borrarlo si quieres reiniciar.
Performance graba una sesión y te dice dónde se fue el tiempo: en JavaScript, en pintar el DOM, en calcular estilos. Es una herramienta para cuando la página va lenta y necesitas pruebas concretas de dónde está el cuello de botella. No es para el nivel 0.
Ábrelas ahora#
La teoría no vale nada si no tocas el teclado. Dedica cinco minutos a esto antes de seguir:
- Abre cualquier web (la que usas a diario sirve) y pulsa
F12. - Ve a Elements. Usa la varita de selección y haz clic en el titular principal de la página. Localiza ese nodo en el árbol. Mira sus estilos a la derecha: identifica al menos una regla CSS que aplique y de qué fichero viene.
- Ve a Network. Recarga la página. Espera a que cargue del todo. Haz clic en la primera fila (el HTML) y mira sus cabeceras de respuesta: busca el
Content-Typey el código de estado. - Filtra por Fetch/XHR. Si la web hace llamadas a una API, verás los JSONs. Haz clic en uno y mira el Preview.
- Ve a Console y, sin agobiarte por la sintaxis (es JavaScript, lo verás en el Nivel 2), escribe
document.titley pulsa Enter: te devuelve el título de la pestaña. Solo es para comprobar que la consola responde.
Si has hecho eso, ya manejas DevTools a un nivel funcional. El resto es práctica.
Comprueba lo que sabes#
Pregunta 1 de 5