1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
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.
|
