Your editor gets keybindings, extensions and a theme. Your browser, where you spend a comparable share of the day inspecting layout, reading network traffic and holding six documentation tabs open, usually gets nothing.
This covers the DevTools features that replace console.log debugging, a workflow for the documentation tabs that pile up, and what the research on interrupted work actually found - which is both less dramatic and more useful than the number that gets quoted.
Disclosure: this site and TheTab, the tab manager mentioned later, are both built by the same people. Treat the recommendation accordingly.
DevTools Features Most Developers Miss
You know Elements and Console. These are the ones that change how you debug.
Logpoints instead of console.log
Right-click a line number in the Sources panel and choose "Add logpoint". You type an expression and DevTools logs it every time that line runs, without editing your source, restarting the dev server, or leaving a console.log behind to be caught in review.
// In the logpoint expression field:
"User data:", user, "at timestamp:", Date.now()
For tracing a value through several components this beats instrumenting the code, because you can move the logpoint while the page is running.
Network request overrides
Right-click a request in the Network panel and choose "Override content" to return whatever body you like without touching the backend. Useful when:
- The endpoint does not exist yet and you are building the UI against it.
- You want to see how the UI handles a 500, or an empty array.
- You need a slow response to check that the loading skeleton is real.
Pair it with the throttling dropdown to test under a connection nobody on your team has.
Local overrides that survive reloads
Sources > Overrides maps a local folder to the site's assets, so edits you make in DevTools persist across reloads. Tweak CSS in Elements until the spacing is right, then copy the final values into your source, rather than doing the full edit-save-rebuild loop for every two-pixel adjustment.
Performance profiling
The Performance panel records what the browser did during a window and shows it as a flame chart: which functions ran long, where layout was recalculated, what re-rendered. For React, add the React DevTools profiler and turn on "Highlight updates when components render", which makes unnecessary re-renders visible rather than theoretical.
Custom formatters
If you work with immutable structures, class instances or Immer, console output can be unreadable. Settings > Preferences > Console > "Enable custom formatters" lets a library supply its own display for its objects.
Extensions That Earn Their Place
- React DevTools. Component tree with props and state, and a profiler that shows what triggered each render.
- A state-library devtool. Redux DevTools and its equivalents give you the action log and time travel. Zustand and Jotai both connect to it.
- A JSON viewer. Raw JSON in a browser tab is unreadable; a viewer folds it and lets you copy a path.
- Vimium, or another keyboard-driven navigator. If your editor is keyboard-only, the mouse-driven browser is the friction.
flabels every link with a key. - A tab manager. Which is the rest of this post.
The Documentation Tab Problem
Building a feature with Next.js, TypeScript and Tailwind means the App Router reference, the TypeScript handbook, the Tailwind class list, MDN and your component library, all open at once. That is not a bad habit. Having the reference open is how you write correct code.
The problem starts when those tabs outlive the task. Three tasks later you have forty tabs, no idea which belong to which piece of work, and finding anything means reading favicons.
Work in sessions
Organise the browser the way you organise a branch: one context at a time.
Before starting. Open only what this task needs. Pin the two you will return to constantly.
Before switching. Save the current set as a named session. Close it. Open a fresh set.
On returning. Restore the session. The references come back in the state you left them.
You would not develop two features on one branch with both sets of changes uncommitted. The argument is the same.
This is also the workflow that makes learning a stack survivable. A session is not "study Next.js", it is "understand how Server Components decide what ships to the client" - narrow enough that you know when it is finished. Open three or four tabs, work through it, write two sentences about what you learned, save the session, stop. When a question comes up that is outside the objective, write it down instead of opening a tab for it. That single rule is most of the difference between a browser with six tabs and a browser with forty.
We build TheTab for the save-and-restore half of this, and it is ours, so weigh that: any tab manager with named sessions does the job, and so do browser profiles plus bookmark folders if you would rather not install anything.
Prune the library as you go
When you find the definitive page for something you use daily, bookmark it and close the tab. Tab sprawl is mostly search residue: you search, open five results, skim, keep three "just in case", and that is fifteen tabs from three searches. A resource is worth keeping if it covers the topic end to end, shows code you can adapt, and is dated recently enough to describe the current version. A React tutorial from 2021 is about class components.
What Interrupted Work Actually Costs
You will have seen a figure like "it takes 23 minutes to get back into what you were doing". It comes from real research, it is repeated far more precisely than the research supports, and it is worth knowing what was actually measured.
In a field study of 24 information workers, observed for about 700 hours in total, Mark, González and Harris found that people spent an average of 11 minutes 4 seconds on a working sphere before switching or being interrupted, that 57% of working spheres were interrupted, and that when interrupted work was resumed the same day, the average elapsed time before returning to it was 25 minutes 26 seconds.
Two caveats the popular version drops, and they matter:
- The standard deviation on that 25 minutes was 54 minutes 48 seconds. The distribution is enormously wide. It is not a per-interruption tax you can multiply.
- It measures elapsed time before returning to the task, and on average people worked in 2.26 other working spheres in between. It is not a measurement of how long your brain takes to reload context, which is what the number usually gets used to claim.
So the honest version is narrower and still useful: interrupted work tends to be picked up much later, after intervening work, not immediately. That is an argument for making the return cheap - for the state of your research surviving the interruption - rather than an argument for a productivity multiplier.
Open Tabs and Memory
The specific per-tab memory numbers that circulate ("50 to 300MB a tab") do not have a source we could trace, and they should not be quoted, including by us: consumption varies by an order of magnitude between a documentation page and a running dev build.
What is measured, by the vendor doing the measuring: Microsoft reports that putting a tab to sleep in Edge saves 83% of that tab's memory on average, across 1.38 billion tabs slept in September 2022.
That is a percentage, not an absolute, and it is the right shape for the decision anyway. An inactive tab holds most of its memory until something reclaims it, and a machine also running a dev server, a TypeScript service, a container and an editor is the machine where that matters. Both Chrome and Edge now reclaim memory from background tabs on their own, which shrinks this problem but does not remove it, and neither of them reclaims your attention.
The fix is the same as above and is not about memory: close what you are not using, after saving it so that closing is not a decision.
Browser Profiles
Chrome profiles are separate environments: their own extensions, cookies, bookmarks and logins.
- Development. DevTools extensions, tab manager, JSON viewer. Logged into dev services.
- Personal. Everything else.
- Per client or project. Separate cookie jar, so you cannot act on the wrong account by accident.
The last one is the strongest argument. The distraction benefit is real but soft; not being logged into two clients' dashboards in the same cookie jar has prevented actual incidents.
What This Costs
- Session managers are another thing to trust. A tab manager sees every URL you have open. That is a meaningful amount of information about your work, and it is worth checking what any of them does with it, ours included.
- Saved sessions become their own hoard. Forty tabs closed into twelve named sessions you never reopen is the same problem with an extra step. Delete them.
- Local overrides are easy to forget. An override left on will silently serve stale CSS on your next visit and you will debug the wrong file for twenty minutes.
- Profiles fragment your state. Different history, different extensions, different logins. Switching for a two-minute lookup is not worth it.
- DevTools features go stale. Panels get renamed and moved between Chrome versions. Anything here that has drifted is in the Chrome docs linked below.
Sources
Checked 2026-08-20.
- Mark, G., González, V. M., and Harris, J., "No Task Left Behind? Examining the Nature of Fragmented Work", CHI 2005 - the 11 min 4 sec average working-sphere length, the 57% interruption rate, and the 25 min 26 sec average resumption time with its 54 min 48 sec standard deviation and 2.26 intervening working spheres.
- Sleeping tabs in Microsoft Edge - that a slept tab saves 83% of its memory on average, measured across 1.38 billion tabs in September 2022.
- Chrome DevTools: pause your code with breakpoints - logpoints.
- Chrome DevTools: local overrides - persisting DevTools edits across reloads.
- Chrome DevTools: network features - request overriding, blocking and throttling.
- Chrome DevTools: performance panel - recording and reading flame charts.
- Chrome DevTools: settings and preferences - where custom formatters are enabled.