Chrome DevTools Features You Are Probably Not Using

I used Chrome DevTools daily for years while only ever touching maybe four of its panels, Elements, Console, Network, and occasionally Sources for setting a breakpoint. It was not until a coworker was screen sharing and casually used a feature I had never seen that I realized how much of the tool I had been ignoring. This is a rundown of the features that actually earned a permanent spot in my workflow once I found them.

The Coverage tab will make you uncomfortable

Open the command menu with Cmd+Shift+P and type Coverage, then start recording and reload the page. It shows you, file by file, exactly what percentage of your shipped CSS and JavaScript actually executed during that page load, with unused bytes highlighted in red directly next to the used bytes in green, down to the line level in the Sources view.

The first time I ran this against a production marketing page, I found a component library CSS bundle where 71 percent of the rules were unused on that specific page, dead weight shipped to every visitor purely because it was bundled globally rather than scoped per route. That single finding led to a route-based code splitting change that dropped our largest page's CSS payload by more than half. This is not a one-time audit tool either, I now check Coverage any time I add a new dependency, because it is the fastest way to see whether a library is tree-shaking the way its documentation claims it does.

The Rendering tab exposes problems Lighthouse only summarizes

Under the same command menu, Rendering gives you toggles for Paint Flashing, which highlights in green any area of the page that gets repainted, and Layer Borders, which shows you the actual compositing layers the browser is managing. Turning on Paint Flashing while scrolling a page with a poorly implemented sticky header is genuinely eye-opening, you can watch large swaths of the page flash green on every scroll event because a CSS property change is forcing a repaint of content that should not need to repaint at all.

The Core Web Vitals overlay, also in this panel, gives you a live, on-page readout of CLS, LCP, and INP as you interact with the page, rather than waiting for a synthetic Lighthouse run after the fact. For debugging a specific layout shift, watching the CLS number tick up in real time while you interact is far faster than the trial-and-error loop of running a full Lighthouse audit after every code change.

The Network panel's throttling is more useful than the presets suggest

Everyone knows you can throttle to Slow 3G, but the panel also lets you define a completely custom throttling profile with specific latency and bandwidth numbers, which matters because Slow 3G is a much harsher condition than most of your actual users experience, while Fast 4G can be misleadingly forgiving. I built a custom profile that roughly matches median mobile conditions in our actual user base, pulled from our real user monitoring data, and use that instead of the defaults, because testing against conditions your actual users experience is more useful than testing against a generic preset that may not represent your traffic at all.

The Network panel's request blocking feature, right-click a request and choose Block request URL, is also underused. It is the fastest way to answer does my app still work if this third-party script fails to load, which is a question worth answering deliberately rather than discovering during an actual outage of some analytics or chat widget script you depend on.

The Application panel for anything involving storage

Beyond the well-known ability to inspect localStorage and cookies, the Application panel's Storage section gives you a quota usage breakdown showing exactly how much of the browser's storage quota your site is consuming across IndexedDB, Cache Storage, and localStorage combined. For any app using service workers for offline support, the Service Workers section here is essential, showing you the exact registered worker, letting you force an update, bypass it entirely for testing, or simulate going offline without touching your actual network connection.

clearStorageOnly = true;

One workflow I use constantly: the Clear site data button at the bottom of the Storage section, scoped specifically to the current origin, which is a much faster reset than manually clearing cookies through Chrome's general settings when you are testing a fresh-user flow repeatedly during development.

Console has features past console.log

Most developers use console.log and maybe console.error and stop there, but console.table renders arrays of objects as an actual sortable table, which is dramatically easier to scan than a nested object dump when you are debugging a list of API results.

console.table(users.map(u => ({ id: u.id, name: u.name, role: u.role })));

console.time and console.timeEnd give you quick, zero-dependency performance measurements around a block of code without reaching for the full Performance panel.

console.time('parse');

const result = JSON.parse(largePayload);

console.timeEnd('parse');

And the $ and $$ shortcuts available directly in the console, equivalent to document.querySelector and querySelectorAll, plus $0 which refers to whatever element is currently selected in the Elements panel, save a surprising amount of typing when you are poking around a live page's DOM interactively.

Why almost nobody explores past the basics

I think the honest reason most developers, myself included for years, never venture past Elements and Console is that DevTools has no real onboarding, you learn what you learn from tutorials that happened to cover a specific panel for a specific problem, and the rest stays invisible until someone shows it to you directly. It is worth carving out thirty minutes sometime to just click through every top-level panel and every item in the command menu once, not to solve a specific problem, just to know what exists, because the next time you hit a performance mystery or a storage quota error, having seen the right panel once before is the difference between an intuitive five-minute fix and an hour of guessing.

One more panel that deserves a mention because it saved me on a recent project: the Memory tab, specifically its heap snapshot comparison feature. Take a snapshot, perform some interaction repeatedly, take another snapshot, and DevTools shows you exactly what grew between them, sorted by retained size, with the actual retaining path back to a root, which is the piece that usually matters most, since knowing an object leaked is far less useful than knowing what is still holding a reference to it. I used this to track down a detached DOM node leak in a single-page app where a modal component was being removed from the page but a stale event listener elsewhere in the codebase was still holding a reference to it, keeping the entire subtree alive in memory indefinitely. Without the retaining path view laid out clearly in that comparison, that would have been an extremely tedious bug to trace by manual inspection alone.

I will end with the practical suggestion I actually follow now: pick one panel a month you have never seriously used, and spend a real debugging session, not a tutorial, deliberately reaching for it even when your instinct says to use a more familiar tool. The Security panel, the Lighthouse panel run directly rather than through a CI integration, the Sensors panel for simulating geolocation and device orientation, these all have genuinely useful moments where they are the fastest path to an answer, and you will not know which of your regular problems they solve best until you have used each one at least once under real pressure. DevTools rewards this kind of deliberate exploration far more than most tools do, precisely because so much of it is genuinely built for exactly the kind of obscure, specific problem that only shows up once every few months, right when you least expect to need it.