I Was Wrong About Browser Developer Tools — Here Is What Changed

I spent years using DevTools as three panels: Elements, Console, Network. I dismissed most of the rest as demo material for conference talks. I was wrong about six things in particular, and each one replaced a workflow I had built out of workarounds.

Local Overrides, which I assumed was a toy

In the Sources panel, enable Overrides and pick a folder. Now any edit you make to a CSS or JS file — or any network response you save — persists across reloads, served from disk instead of from the server. I used to reproduce production CSS bugs by deploying to a staging branch. Now I edit the minified production stylesheet in the browser, reload, and confirm the fix before writing it in the repo. It also overrides JSON responses, which means you can test an empty-state or an error payload without touching the backend.

Logpoints, which I replaced with console.log for a decade

Right-click a line number in Sources and choose Add logpoint. It prints an expression every time that line runs, without modifying the file, without a rebuild, and without the risk of committing it. Conditional breakpoints do the same for pausing: orderId === 'A-771' stops on the one iteration that matters instead of the four hundred that do not.

The Rendering tab, which I never opened

Open the command menu with Ctrl+Shift+P and type "rendering". Paint flashing shows exactly which regions repaint on scroll. Layout Shift Regions highlights what is moving, which turns an abstract CLS number into a visible blue rectangle. It also emulates prefers-color-scheme, prefers-reduced-motion and forced-colors mode, so you can check three accessibility media queries without changing an OS setting.

Console utilities, which are not console.log

$0 is the currently selected element and $_ the last result. $$('a[href^="/"]') returns a real array of matches, so you can map over every link on a page in one line. monitorEvents($0, 'focus') logs events on an element — the fastest way to find what is stealing focus. debug(myFunction) sets a breakpoint on a function by name without hunting for it in a bundle. copy(JSON.stringify(data)) puts the result on your clipboard.

The Coverage panel, which told me something uncomfortable

Command menu, "Show Coverage", then reload and interact. It reports which bytes of each CSS and JS file actually executed. On the first site I ran it against, most of the CSS was unused on the landing page, all of it from a component library imported wholesale. Unlike a bundler report, it measures execution rather than imports, so it accounts for the code you ship and never run.

The Performance panel, which I had been reading wrong

I used to look at the summary pie chart. The useful part is the main-thread flame chart with CPU throttling at 4x, where a single long task is visibly one wide bar you can click to get the exact call. Since Chromium started reporting long animation frames, slow interactions arrive with the responsible script attached, which removed the guesswork I used to fill with instinct.

The one I still do not use

The Recorder panel exports a user flow as a Puppeteer script. It works, but the generated selectors are brittle enough that maintaining them costs more than writing the test by hand. Worth knowing it exists; not worth building a suite on.