# Debugging and Performance Analysis with Chrome and Firefox Dev Tools
Today we’ll be covering three areas of the dev tools: Debugger, Networking, and Performance.

## Debugger / Sources
For this I prefer:Firefox. Due to its better integration with source maps. However, both platforms offer pros and cons so we should look at both of them.

On firefox: Debugger tab.
On Chrome: The sources tab.

On the left hand side you have a file tree. First let’s find the code that we want to listen to.

On production: it’s *minified* so it’s hard to use.
In some situations you might have source maps, which are useful.

Source maps are currently disabled on *next* :(. In production this makes sense because it reduced the download, however for QA servers it might make sense to have them to make debugging easier.

Let’s find the same piece of code using both.

## Showing how source maps work
Go to the homepage https://www.amboss.com/us

* On firefox you have Webpack, on chrome you have webpack://
* Find `src/components/Pages/Page.js`
* Place a breakpoint on componentDidMount()
* Refresh

## What can we do when stopped on a break point?

### Check the call stack.
Right hand column, section called Call Stack.
In firefox we can actually map them!

You can see who called the function and go up and read the code.

Let’s see how the call changes.

1. Step OVER the current call. (eg. stop right after it finishes, at the same level)
2. Step INTO the next call (eg. stop right after it starts)

### Check the scopes.

What’s the value of `this`, `arguments` and any closured values. + what scope we’re inheriting it from.

### Open a console.

Run things.
Source maps can be tricky, the console isn’t aware :( 

### Add Watch Expressions

Source map friendly

## Showing how to trigger breakpoints
### Pause on Unacaught Exceptions
On Chrome: The pause button in the stop sign
On Firefox: In the breakpoints section

Example: Pause on exception, find the duplicated script. Pause on the if UC_UI_IS_RENDERED and disable exceptions.

Check OK we’re here the first time, it’s OK. How did this load. AH from running the bundle.

Let’s go to the network pane. First time from script. Second time from this piece of Bundle.

Cool! We can now root cause it.

A bit harder in Chrome.

CAREFUL WITH CAUGHT EXCEPTIONS LOL

### Pause on DOM modifications

Subtree, removal or attributes.

For some reason my Firefox was not preserving them, but that’s a bug. Both browsers are supposed to preserve them on reload.

## Questions so far?

## Network Pane

* Preserve Log (In cog in firefox)
* Disable Cache
* Throttling: Though in my experience this has been a bit jank. I prefer Network Link Conditioner.

## Columns
* Status
* Name (Chrome) -> File (Firefox)
* Method
* Size
* Timing

Right click in both to see more options.

Some notable ones:

* Type & Initiator. They behave a bit different but they tell us what type of request.
	* Firefox: Initiator is the method and Type is the mime type
		* fetch / plain
		* font / woff2
		* script / js
		* link to the url / sag
	* Chrome: Initiator is the script that initiated it
	* Type is a combination of mime type and initiator

## The Sidebar

Headers. Your basic HTTP Request and Response + protocol and such
Response -> In firefox it combines Preview and Response.

Confusingly, Chrome puts the request payload in the Headers section. While firefox has a response 

You can also see the Cookies

When available you can see the Stack Trace (Firefox) / Initiator (Chrome)

In firefox you can see some additional info on Security

## Timing

This is important for performance.

Queued: When the resource was Queued
Started: When it actually begun.

In Chrome Sending is Blocked + DNS + Connecting + TLS + Sending + Waiting.

Firefox:
Blocked -> Time spent waiting for a connection (limited number of connections per domain.)
DNS -> Time spent resolving the DNS name
Connecting -> Time taken establishing a TCP connection
TLS -> Time spent doing the TLS handshake
Sending -> Time spent actually sending our request
Waiting -> Time waiting for server to respond (eg. because it’s processing)
Receiving -> Time taken to read the results after the first bite.

Stalled/Queuing
DNS Lookup
Initial Connection (Includes TLS)
Proxy negotiation
Request sent
Waiting
Content Download

## Reading WebSockets

In Firefox: In Response
In Chrome: In Messages

## Performance. We’re going to shift to Chrome only here. Because frankly, the firefox performance tools are lacking

## Lighthouse
Can be run on CI.

IT’S NOT A REAL USER’S EXPERIENCE AND DEPENDS ON YOUR MACHINE. USE IT AS INSIGHT NOT AS HARD DATA.

## Viewing the Trace

* see the top it gives you insight on CPU and slow frames (RED == bad)
* * Los at the Network. What requests were being done. What was the order. What blocked what. What triggered what.
* Then look at the web vitals and compare them to the frames: ANALYZE!
* Look at the Long Tasks
	* Look at the Main thread. What’s causing the long task?
		* Evaluate script?
		* A function?


It’s better to trace directly. Let’s reload and trace. Now we have a lot more info.

A flame chart is the task visualised.
The lower it is the worse it will perform, the exact same code.
Long iterative pieces are better when chunked into async code.