Beyond console.log: The Console API
The browser console is far richer than a single console.log. These methods give you structured output, conditional logging, and styling — all without touching production code.
console.table
// console.table — renders arrays/objects as a table
const users = [
{ name: "Alice", age: 30, role: "admin" },
{ name: "Bob", age: 25, role: "user" },
];
console.table(users);
// Optional second arg: restrict which columns to show
console.table(users, ["name", "role"]);console.table
Render arrays/objects as a sortable table — great for API response inspection.
console.group
Fold related logs into collapsible groups to reduce noise.
console.assert
Log only when a condition is false — zero output when everything is correct.
console.dir
Show a DOM element or object as an expandable JS property tree.
console.count
Count how many times a label is hit — no manual counter variable needed.
%c styling
Apply CSS to log output for colour-coded, visually distinct module prefixes.
Breakpoints — Pause Without Changing Code
Breakpoints let you freeze execution at any point and inspect the live program state. DevTools offers several types — each suited to a different debugging scenario.
1
Line-of-code breakpoint
Click a line number in the Sources panel gutter. Execution pauses before that line runs. Right-click to make it conditional.
2
Conditional breakpoint
Right-click a gutter → Add conditional breakpoint. Enter any JS expression — pauses only when it evaluates to truthy. Invaluable in hot loops.
3
Logpoint (no code edits)
Right-click → Add logpoint. Type an expression to print. DevTools logs it like console.log without modifying your source — disappears when you remove it.
4
DOM breakpoints
In the Elements panel, right-click a node → Break on → subtree modifications / attribute changes / node removal. Pauses exactly when the DOM mutates.
5
Event listener breakpoints
Sources → Event Listener Breakpoints. Expand a category (Mouse, Keyboard, XHR…) and tick an event. Pauses inside the handler for every matching event.
6
XHR / Fetch breakpoints
Sources → XHR/fetch Breakpoints → Add. Enter a URL substring — pauses when any fetch matching that pattern is initiated.
Logpoint example
Logpoint expression
// Logpoint — right-click a line gutter in Sources -> Add logpoint
// Type an expression; DevTools prints it without changing your source.
// Example logpoint expression:
"fetchUser called with id =", userId, "at", new Date().toISOString()
// No console.log in your code — logs disappear when you remove the logpoint.Stepping keyboard shortcuts — memorise these to move through paused code without touching the mouse:
F8 Resume / pauseF10 Step overF11 Step intoShift F11 Step outF9 Step (one statement)
Sources Panel: Call Stack, Scope, and Watch
When execution is paused, the Sources panel becomes your primary inspection tool. Each pane reveals a different facet of runtime state.
Sources Panel Layout
Call Stack — ordered list of active frames; click any frame to jump to its code and scope
Scope — Local / Closure / Global variables for the selected frame; values are live-editable
Watch — pin any JS expression; re-evaluated on every pause so you can track derived values
Breakpoints — all active breakpoints with enable/disable toggles
Ignore List (Blackboxing) — mark third-party or bundled files; stepping skips them entirely
Performance Panel: Flame Charts and Long Tasks
The Performance panel records a detailed timeline of everything the browser does — JavaScript execution, style recalculation, layout, paint, and compositing. It is the primary tool for diagnosing jank and slow interactions.
Profiling Workflow
1
Navigate
Go to the page you want to profile
2
Record
Click the record button or press Ctrl+E
3
Interact
Perform the slow action (scroll, click, load)
4
Stop
Click Stop — DevTools processes the trace
5
Analyze
Inspect the flame chart, find long tasks
Reading the flame chart
Each bar is a function call. Width = duration. Stacked bars show the call tree — a wide bar near the top with tall stacks below it means one function is driving a lot of downstream work. Look for Long Tasks (red triangles, >50 ms) — they block the main thread and cause visible jank.
Typical Frame Budget (16 ms at 60 fps)
JS execution6 ms
Style / Layout3 ms
Paint / Composite2 ms
Browser overhead2 ms
Remaining budget3 ms
✓Layout shift markers
Expand the Experience row at the top of the timeline to see Cumulative Layout Shift (CLS) events. Clicking a shift marker highlights which elements moved and by how much.
Network Panel: Waterfall and Timing
The Network panel records every request made by the page. The waterfall view shows when each request started relative to others and how long each phase took — essential for diagnosing slow page loads.
| Timing Phase | What It Measures |
|---|---|
| Queueing | Time waiting before the browser could send the request (connection limits, priorities) |
| Stalled | Time blocked after queueing — e.g. waiting for a free TCP connection |
| DNS Lookup | Time to resolve the hostname to an IP address |
| Initial connection | TCP handshake (+ TLS negotiation for HTTPS) |
| TTFB (Waiting) | Time to First Byte — server processing + network round-trip |
| Content Download | Time to receive the full response body |
Coverage Tab: Find Unused JS and CSS
The Coverage tab (open via Ctrl Shift P → "Show Coverage") records which bytes of every JS and CSS file were actually executed during a recording session. Red bars = unused code.
40–70%
Typical unused JS
of initial bundle bytes on average page load — mostly lazily needed code
50–90%
Typical unused CSS
of stylesheet bytes — especially from large utility frameworks
<20%
Target
unused bytes on critical path; defer or tree-shake the rest
How to use Coverage
Open the Coverage tab, click the record button, interact with your page, then stop. Click any file to open it in Sources — lines highlighted in red were never executed. Use this data to guide code splitting: move those paths behind
import() dynamic imports so they load only when needed.User Timing API and Source Maps
Instrument your own code with performance.mark and performance.measure to add named markers that appear directly in the Performance panel timeline — no guessing which flame chart entry corresponds to your feature.
performance.mark / measure
// User Timing API — custom marks visible in the Performance panel
performance.mark("data-fetch-start");
const data = await fetchDashboard();
performance.mark("data-fetch-end");
performance.measure("data-fetch", "data-fetch-start", "data-fetch-end");
// Read timings programmatically
const [entry] = performance.getEntriesByName("data-fetch");
console.log(`fetch took ${entry.duration.toFixed(1)} ms`);
// Clean up after reading
performance.clearMarks();
performance.clearMeasures();Source maps for minified code
Enabling source maps
// tsconfig.json — enable source maps
{
"compilerOptions": { "sourceMap": true }
}
// vite.config.ts
export default defineConfig({
build: { sourcemap: true }, // or "inline", "hidden"
});
// Once deployed, DevTools automatically maps minified code back to
// your original TypeScript source — breakpoints, stack traces, and
// variable names all reflect your source files.Debugging Workflow Checklist0/10