The Console and the Network Panel

The Console

The first place to look when anything behaves unexpectedly. It reports script errors, failed requests, security warnings, deprecation notices and accessibility issues the browser noticed on its own.

Reading it

The Issues tab is worth checking separately. Browsers surface accessibility problems, deprecated attributes and security warnings there rather than in the main log, so it is easy to miss.

Console methods beyond log

console.log(value);
console.table(arrayOfObjects);        // renders as a real table
console.dir(element);                 // the object view, not the DOM view
console.warn("Slow path taken");
console.error("Upload failed");
console.count("render");              // how many times this line ran
console.time("build"); console.timeEnd("build");
console.group("Form"); console.log("..."); console.groupEnd();
console.assert(items.length > 0, "No items to render");

console.table is under used. An array of objects rendered as a sortable table is far easier to read than a wall of logged objects.

Useful expressions

$0                                    // the element selected in Elements
$("h2")                               // shorthand for querySelector
$$("a")                               // shorthand for querySelectorAll, returns an array

// every image with no alt attribute
$$("img:not([alt])")

// every link with unhelpful text
$$("a").filter(a => /^(click here|read more|link)$/i.test(a.textContent.trim()))

// duplicate ids
const ids = $$("[id]").map(el => el.id);
ids.filter((id, i) => ids.indexOf(id) !== i)

// the heading outline
$$("h1,h2,h3,h4,h5,h6").map(h => `${h.tagName} ${h.textContent.trim()}`)

Those four snippets are a usable accessibility audit in thirty seconds.

The Network panel

Every request the page made, in order, with size, timing and status.

Reading the table

The waterfall is the part worth learning to read. A long bar starting late means the request was discovered late; a request that begins only after another finishes indicates a dependency chain.

What to look for

• 404s. Sort by status. Every one is a broken path.
• Redirect chains. A 301 followed by another 301 wastes a round trip each time.
• Large images. Filter by Img and sort by size. Anything over a few hundred kilobytes deserves attention.
• Blocking resources. A stylesheet or a script early in the waterfall with everything else waiting behind it.
• Which responsive image was chosen. Resize the window, reload, and check which file was actually fetched. It is the only way to verify srcset and sizes.
• Cache behaviour. A size of disk cache or memory cache means it was not downloaded.

Throttling

The throttling dropdown simulates a slow connection, and the Performance panel can throttle the processor as well. Testing at Fast 3G with a four times processor slowdown is much closer to the experience of most readers than a fibre connection and a modern laptop.

The Disable cache checkbox forces a fresh download of everything, which is what a first time visitor experiences. Leave it on while measuring.

Inspecting one request

Click any row for the full picture:

• Headers - the request and response headers, including cache directives, content type and status.
• Payload - what a form or a fetch actually sent. This is where you confirm whether a form field arrived.
• Response - the raw body the server returned.
• Timing - the breakdown from DNS lookup to content download.

The Payload tab is the answer to my form field is not reaching the server. If the field is not listed there, it has no name, or it is disabled.

Copy as fetch

Right click a request for Copy, then Copy as fetch or Copy as cURL. It produces a complete reproducible command with every header, which is how you take a browser request into a terminal or a script.

A debugging routine

1. Console first. Any red text is the most likely cause.
2. Issues tab. Browser detected problems that do not reach the log.
3. Network, sorted by status. Any 404 or 500.
4. Elements. Is the DOM what you expected?
5. Styles pane. Is the rule applying, or struck through?
6. Accessibility pane. Is it announced correctly?

Six steps, and they find the overwhelming majority of front end problems.

Important rules

• The console reports errors from the whole page, including third party scripts.
• The Issues tab is separate from the log.
• Network shows only requests made since the panel was opened, unless preserve log is enabled.
• Disable cache only applies while DevTools is open.
• Throttling is a simulation, not a real slow connection.
• The Payload tab shows exactly what a form submitted.

Common mistakes

• Not opening the console at all.
• Ignoring warnings until they become errors.
• Measuring performance with a warm cache.
• Testing only on a fast connection.
• Missing a redirect chain because only the final status was checked.
• Not checking which responsive image variant was actually fetched.

Best practices

• Keep the console open while developing.
• Check the Issues tab before every release.
• Measure with cache disabled and throttling on.
• Use console.table for structured data.
• Keep the four audit expressions above as snippets.
• Use the Payload tab to confirm form submissions rather than guessing.

Practice

1. Run the four console audit expressions on a page you built and record what they find.
2. Load a page with cache disabled at Fast 3G and note the total transferred size.
3. Submit a form and read the Payload tab. Remove a name attribute and submit again.
4. Resize the window through a breakpoint and confirm which image file was fetched each time.