What is it?
Devtools is the panel that opens when you press F12. It's a debugger, a profiler, a network monitor, an accessibility tree inspector, and a DOM editor — all in one. Every browser ships its own; Chrome's is the most featureful, Firefox's CSS panels are the best.
Why it matters
Reading devtools fluently separates "I followed a tutorial" from "I can debug what I built." Most production bugs leave traces in the Network, Console, or Performance panels. Knowing where to look saves hours per issue and turns "I have no idea why" into a one-line fix.
What to learn
- Elements: live DOM editing, computed styles, event listeners panel
- Console:
console.loglevels,console.table, conditional breakpoints - Network: filtering, throttling, request waterfall, response inspection
- Performance: recording, flame charts, identifying main-thread blockers
- Application: cookies, localStorage, service workers, manifests
- Lighthouse: built-in audits for performance, a11y, SEO, best practices
Common pitfall
Using console.log for everything. The Sources panel has real
breakpoints, conditional breakpoints, and the ability to step through
code. Setting one breakpoint and walking through state usually beats
sprinkling 20 logs and re-running.
Resources
Primary (free):
- Chrome DevTools docs · docs
- Firefox Developer Tools · docs
- Edge Developer Tools — What's new · article
Practice
Open any production website and try four things: throttle the network to "Slow 3G," record a performance trace of the page load, run Lighthouse against the page, and open the Application panel to see its service worker. Done when you can do all four without looking up a single shortcut.
Outcomes
- Set a breakpoint and step through real code, not just
console.log. - Read a Network waterfall to spot the slow request.
- Run a Lighthouse audit and interpret the four scores.
- Inspect any element's computed styles and event listeners.