Update courses/debugging_and_performance_analysis_with_chrome_and_firefox_dev_tools.md

diff --git a/courses/debugging_and_performance_analysis_with_chrome_and_firefox_dev_tools.md b/courses/debugging_and_performance_analysis_with_chrome_and_firefox_dev_tools.md
new file mode 100644 (file)
index 0000000..3535f41
--- /dev/null
+++ b/courses/debugging_and_performance_analysis_with_chrome_and_firefox_dev_tools.md
@@ -0,0 +1,171 @@
+# 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.
+