From: Rubén Beltran del Río Date: Tue, 6 Jul 2021 15:05:48 +0000 (+0000) Subject: Update courses/debugging_and_performance_analysis_with_chrome_and_firefox_dev_tools.md X-Git-Url: https://git.r.bdr.sh/rbdr/txt/commitdiff_plain/b5ebcc314b07dd5b403b02d3f83e892627fd016c?ds=inline;hp=657de3fa00666ca71ed15f76deaba4e7ad2950c8 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 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. +