dev tools power hour notes

pwhr.md

• 1 - Elements panel
• 2 - Console panel
• 3 - Performance (prev. Timeline)
• 4 - Responsive mode
• 5 - Layers
• 6 - Table views

Elements panel

everyone should know this panel. here are some simple tricks

Raw DOM Editing:

• Select node (keyboard nav, cmd+shift+c)
• Enter key edit attribute values
• Tab and Shift+Tab cycles attribute values
• Last highlight is new attribute
• Double-click text is sanitized :(
• Edit as HTML
• F2 (or Fn+F2, or right-click) on node
• Raw HTML. Cmd+Enter to save changes
• Move nodes with click+drag
• Awesome for testing if your styles are good (would this field work below that field?)
• Delete nodes with... delete
• Focus panel, undo with cmd+z

DOM State

Force element states

• Right-click, :hover, :active, etc
• Can edit a:pseudo states in styles panel (normally hard)
• Notice orange circle
• Sidebar Styles panel > :hov tab

DOM breakpoints

demo: time tracker

• Right-click, Break on...,
• Will pause JS, jump to line in source. Really handy
• "Subtree modification": any children change, removed, added
• "Attribute modifications" classnames, aria-whatever (demo: hamburger menu)
• "Node removal" pause when that node is removed from DOM
• Notice blue circle
• Sidebar "DOM Breakpoints" panel on right
• End of left side

Event Listener sub-tab

demo: NOT SURE

• Highlight an element with JS event attached
• Lists all events that have active listeners
• "Ancestors" shows like, all basically
• Expand, Right-click "handler", go to source
• YMMV with event libs (try Framework listeners)

Styles tab

will be brief here

"Filter" section

• type on the left to filter
• :hov tab forces pseudo-classes
• .cls tab toggles or adds class names

Panel

• Split up by selector blocks
• Ordered most->least specific selector
• inline-styles under element.style at top
• filename takes you to definition. works with source maps (if enabled in settings)
• black = active, gray = overridden. BOTH rules and selector blocks

Editting styles

• click to right of any style to add new one
• will only apply if it would if there in the code
• use element.style normally
• good autocomplete (all chrome supports). tab to accept. escape to cancel
• check/uncheck
• up/down on numbers: shift x10, alt x0.1 increments, scrollwheel
• color picker great for rgba eyedropper useful swatches at bottom are colors it's found in the page
• transition: cubic-bezier editor
• "more actions". adding new ones. shadows is kind of useful
• new box-shadow editor
• tldr; click all icons you see inline in the panel.

Computed tab

best tab ever (demo: anything?)

• interactive box model.
  • click numbers or - to edit or add values
  • hover to show that part on the page
  • live updates
  • hover node in element panel to highlight box model on page
• shows all rules that are active on that element
• gray rules have been calculated by browser or are default (height, width normally, or everything with "Show all"),
• expand rule. top is one in use, then all others that could be used
• click arrow to show rule in style tab, file name to jump to sources
• "Rendered Fonts" at the bottom shows what resource it used.
• some annoying ones like background and border are often there (if using reset)
• really stress this USE THE COMPUTED TAB to see what styles are actually being applied. expand a rule to see all rules that are trying to get applied (matching selector).

Console panel

• dont bother with the tab, use esc

Command line API (helpful builtin functions)

demo: power hour page

• $0-$4 last 5 inspected elements. $0 is most helpful
• $() alias to document.querySelector(). careful this can be overwritten with jquery, demo: $('.card')
• $$() is the same but querySelectorAll
• $_ last evaluated expression. limited use. next example tho.
• copy() string representation of object. demo: $0.getBoundingClientRect(), highlight copy and paste. then copy($_) and paste
• dir() object-style representation, instead of toString. Show a dom node dir vs regular evaluation. aka console.dir. demo: dir($0)
• monitor() and monitorEvents(). pretty cool. monitorEvents(window, 'click') will log event details whenever that event is dispatched. monitor is the same with a function, but must be global, so less useful
  • unmonitor and unmonitorEvents
  • provides "shortcut" events: mouse, key, touch, and control. demo: select an input, and monitorEvent($0 or window, 'key'). easy key codes
• table() renders an object or array into an interactive table. not sure what data to use.

General

• shift+enter to newline without submitting
• q: ever thought about autocomplete menu?:
  • > previous commands
  • wont autocomplete unless it knows the el. demo: $('div').<tab>, then assign const adiv and press .
  • gray label: where that method/prop is inherited from _demo: adiv.align, then MDN HTMLDivElement look at inheritance graph. go back, scroll down autocomplete. wonder what unique methods a script tag has? autocomplete.

Console API

• console.log() everyone knows. note that it takes infinite arguments, so don't string concat. you lose type formatting that way.
• console.assert() logs error if first argument is false. demo console.assert(false vs true)
• console.count() sweet. counts every time this is called. keeps a separate counter for each string passed to it. demo: $(0).addEventListener('click', () => console.count('content clicked')), then add another to header and click it
• console.dir() as described above. will always be object output

Log Levels

• Log level: Filter > Verbose will show these "Violation" messages, which are actually really helpful for performance. It will log out a message when any function or event takes a long time to run. I don't know what the rules are... they seem to just pick some max time each type of event should take. https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/3tViQmRF2l8/discussion Can easily filter by "importance"
• console.error() shows stack track and looks like js error
• console.warn() shows stack track and is yellow
• console.info() or log plain message.
• _demo: reuse addEventListener with console.warn/error/info for sections. then click around and filter.

Groups

not sure how to demo

• Log a bunch of stuff together without polluting the console
• start with console.group or groupCollapsed (better)
• every console method used until groupEnd() will be grabbed

https://developers.google.com/web/tools/chrome-devtools/console/command-line-reference

Performance Tab

• Identify target: page load or specific interaction?

lets start with

Page load measurement

• check "Screenshots"
• reload and record (cmd+shift+e)

Overview

collapse each section

• FPS, CPU, NET chart
  • tiny overview of all the other data on the page
  • FPS: 0-60fps graph. red bar means FPS is too low
  • CPU: 0-100% load over time. color coordinated to other sections (see summary pie at bottom)
  • NET: bars where there is network activity
  • area is also where you manage selection window
• Events (vertical bars)
  • important dom events. dom content loaded, main load event etc. FMP coming
• Main section, will come back to it
• Bottom panel
  • reflects whatever is selected above
  • no selection, then zoomed
  • selection can be frame, net call, function, event, shift+click area
  • will come back when relevant

Navigation

• use top section
• drag handles to zoom
• click+drag to zoom
• scroll up/down (anywhere) to zoom towards cursor
• scroll left/right (anywhere) to move in time
• click+drag main area to move
• top area: single click tight zoom, double reset zoom
• also WASD controls all of these

Main section

Network

• click a request.
• view summary details. priority (blocking)
• view helpful when compared to Main activity
• thin lines show waiting (time-until-first-byte?). stuff you cant probably control

Frames

• "block" for every single rendered frame.
• green block = new frame. white = idle (not a problem)
• hover for ~fps.
• essential tool. long green blocks are bad.
• expand to see screenshot of every frame.
• click "block", click image in Summary tab. arrows jump between every new frame.

Interactions

• Input: user (mouse/key) events.
  • length is how long took to resolve
  • red bar is time waiting for main thread so it can run this event
  • red bars and triangles are always bad
• Animations too. not much to say about that

Main

• main thread activity
• the whole point of this view pretty much
• what actual work is happening, and what is causing slowdown

Flame chart

• A Root Activity is a the top bar of the flame chart. It is something that caused the browser to do some work.
• Types of root activities
  • click, hover, keyup, keydown events. User interaction events basically
  • network request finished
  • layout, paint, recalculate style, update layer tree. these aren't JS activities, so the don't have flame charts (i think)
• the nesting of chart represents the call stack

things to cover:

• detailed inspection of the graphs and colors. what do all of the lines and symbols mean?
• Merge in the table-views.md file
• Make a performance recording. then click on a function in the top-down or whatever to reveal it in the sources panel. that will add the execution timestamps on the left. use those to debug a slow function (like the calculator bug)

Device view

Helpful mode for making responsive sites.

Setting button: Enable everything except rulers.

Media query bars demo: kgportal

• top bar (blue) shows max-width media queries
• mid bar (green) shows range queries (min width and max width)
• bottom bar (orange show min-width queries)
• Super helpful for seeing if you have too many media queries (can make code more complex), or if you have any weird ones.
• If there are like 3 right next to each other maybe you can simplify and combine them. best partthough is you can click the bars to resize to that exact width.
• For some reason resizing the window in this view is way faster than resizing the divider between page and dev tools
• Extra bonus: right click on the media query bar to reveal that MQ in your source code (take screenshot of big list). If you use it in more than one place it will show you a list of everywhere it is used.

Others

• demo screenshot tools
• Compare mobile/desktop interactions. hover, click+drag
• performance selector (low-end mobile etc)

Layers panel

• enable "advanced paint instrumenation" in performance settings
• make new performance recording
• click a frame, then Layers tab
• shows gpu layers on that frame
• click one to see what caused it

Table views in the performance window

• Table views reflect whatever is selected above. This is very very useful. If nothing is selected, it shows the the section that is zoomed in. Click an item in the chart an it show it and it's call stack. Click a Frame and see calls that happened in that single frame. Shift+click+drag a section to show that range without zooming.

Call Tree tab

Self Time Column

Time spent on that specific task

Total Time Column

Time spent on this task and all children of it

Total time show you where to start looking. Self Time is what you want to find.

Heaviest stack

Click the icon in top right. This window shows you the slowest route down the selected item. It's like clicking the expand arrow all the way down the slowest path.

In general this isn't the most useful tab

Bottom-up tab

Most useful inspection tab, it highlights the activities that are the slowest themselves

Self Time column

A little different from the Self Time column in the Call Tree tab. It shows execution time for all occurances of this function. Entire column will equal 100%.

Total Time column

How long this function's entire tree took to run. So including everything that this activity kicked off. Column will not equal 100% (because it counts all of it's children)

Activity column

Expanding these items is going UP the call stack. It's the opposite of the Call Tree panel. Note the file name on the right. If you have a lot of dependencies in your project (I know you do...) this can really quickly tell you if one of them is slow. Bonus: Click on the file name to jump directly to that function in that file. The gutter will also show you how long that function took. Throw in a breakpoint there and you are immediately debugging that issue!

Warning, it can be easy to mis-interpret this information. Try to look for one specific thing and don't get distracted by other functions

Careful when filtering by name! The activities will swallow up the time their children that have been filtered out took. It's really confusing, I don't like it.

Demo

![bottomup]

1. Select a slow frame
2. Select Bottom-up tab
3. Sort by Self Time (default)

Observations:

Calls to mountComponent took the longest

But notice it only took 49ms (8.2% of frame) of self time. That tells us that there isn't one big slow function causing this long frame. If there was we would have an item with a really high Self Time (400ms or something). 49ms is the longest any single activity takes, although we don't know how many time that ran. It might have run 10,000 times in 49ms. I don't know how to find execution count in the dev tools...

Total Time is important here though. That means mounting all of the React components in this frame took 360ms. We should look at our components in more detail. Again, if there was 1 slow function it would show up here, so maybe we just have too many components mounting

Compare Total Time and Self Time. If Self Time is high, you have found a function to optimize. If all Self Times are low, you are probably in good shape. If your page is still running slow, maybe you just have have too much going on.

Event Log tab

Shows Root Activities chronologically. It is essentially a list view of the main timeline, so it isn't super helpful.

You can however click "All" next to the Filter box, and filter out events that took less than 1ms or less than 15ms. This can be useful if there are a ton of root activities (any thing that start cpu work) and it's not easy to see which ones are slow.