Learning on Web Dev Open is free for all.

Take It Apart > The DOM as an APIThe DevTools you are not using yet
Phase 01The DOM as an API72 of 434

The DevTools you are not using yet

Most people use Elements and Console and stop. The other panels are where the answers are, and none of them take long to learn.

Build22 minAI pair

Work through each of these on your own deployed site. Do not read about them, do them. The whole chapter is about thirty minutes if you actually click things and a waste of time if you do not.

Performance. Record a page load with CPU throttled to 4x slowdown. Find the longest task. Find the first contentful paint marker. Find any purple layout blocks in a row, which is the thrashing you read about last chapter. Do it again for an interaction, click something and record just that.

Breakpoints. Open Sources, find a function, and set a breakpoint by clicking the line number. Reload. When it pauses, read the Scope panel and the Call Stack. Then right-click a breakpoint and add a condition, i > 40, so it only pauses when you care. Then try a DOM breakpoint: right-click an element in Elements, "Break on", "attribute modifications", and find out what is changing it. That last one answers a question console.log really cannot.

Coverage. Command-Shift-P, "Show Coverage", reload. It shows what percentage of each CSS and JS file was actually used. Most sites are shipping 60-80% unused CSS. Look at your worst file.

Network conditions. Throttle to Slow 3G and reload. This is the closest thing to an honest look at your own site that exists on your laptop, and it is two clicks.

Accessibility. In Elements, the Accessibility pane shows the computed role, name and state of the selected node, the tree you read about in lesson two, for your own page. Check five interactive elements. At least one will have no accessible name.

Rendering. Command-Shift-P, "Show Rendering". Turn on "Paint flashing" and interact with your page: green flashes are repaints, and large flashes where something small changed mean you are repainting far more than you need to. Turn on "Layout Shift Regions" and reload to see shifts you cannot perceive but Lighthouse can.

Write down one thing each panel told you that you did not know. Seven lines. That file is your DevTools reference and it is more useful than any tutorial because every line is about your own code.

Done when

  • A Performance recording taken with CPU throttling, with the longest task identified
  • A conditional breakpoint and a DOM breakpoint both used successfully
  • A Coverage run with the worst unused-bytes file named
  • Five elements checked in the Accessibility pane, with any missing names listed
  • Paint flashing observed during a real interaction
  • Seven notes, one per panel, on something you did not previously know about your own page

Nobody marks this for you. It goes into your phase checkpoint, where a person does.

Build this in your own editor

This one runs on your machine rather than in the browser workbench. Work to the outcomes below, then come back and mark it complete.

You should now be able to

  • Record and read a Performance profile
  • Use conditional breakpoints and the call stack instead of console.log
  • Audit with the Coverage and Accessibility panels
  • Throttle network and CPU to reproduce a user’s conditions
Ask the community

Loading…