WEBVTT

1
00:00:05.160 --> 00:00:09.960
Hey everybody, welcome back to another
episode of JavaScript Jabber. This week on

2
00:00:10.000 --> 00:00:15.519
our panel we have Dan Shapiir.
Hello from a woman Sunny TELEVIV. I'm

3
00:00:15.599 --> 00:00:18.239
Charles Maxwood and I ducked out a
stand up to come to this, so

4
00:00:18.280 --> 00:00:22.480
I'm excited. We have a special
guest this week that is Jack Franklin.

5
00:00:22.600 --> 00:00:25.399
And Jack, you're based out in
the UK. You want to tell us

6
00:00:25.440 --> 00:00:29.079
a little about yourself? Yeah,
hey, thanks having me. Yeah,

7
00:00:29.160 --> 00:00:32.759
manas Jack, I work Google on
the Chrome dev tools, focusing on the

8
00:00:32.799 --> 00:00:36.679
performance tooling. Yeah, based just
outside of London, where it is sadly

9
00:00:36.759 --> 00:00:40.119
not so sunny as it is for
Dan, a little bit cooler here.

10
00:00:41.560 --> 00:00:44.719
Yeah, we get that all the
time. It'll be like, you know,

11
00:00:44.840 --> 00:00:48.240
minus eighty one hundred degrees here in
Utah and he's like yeah, it's

12
00:00:48.280 --> 00:00:53.079
like sixty degrees and it's like okay, just go away and come back next.

13
00:00:54.759 --> 00:00:59.119
Yeah. There's a downside to that, which is how hot it'll get

14
00:00:59.240 --> 00:01:04.159
around Lion August soya. Yeah,
yeah, it gets hot here, but

15
00:01:04.359 --> 00:01:08.439
it's a dry heat. Like I
lived in Italy for two years and boy

16
00:01:08.560 --> 00:01:11.319
gets muggy there. It's like,
yeah, it's one hundred degrees but it's

17
00:01:11.319 --> 00:01:17.280
a completely different hundred degrees, so
that's for sure. Yeah. All right,

18
00:01:17.319 --> 00:01:22.439
Well, let's dive in and talk
about Chrome dev Tools Jack. Before

19
00:01:22.480 --> 00:01:25.519
we get too far in, I
just want to get a little bit of

20
00:01:25.519 --> 00:01:27.519
a story here, like, how
do you wind up being a Chrome dev

21
00:01:27.599 --> 00:01:34.680
tools person? Yeah? A lot
due to good timing, I think.

22
00:01:34.760 --> 00:01:38.640
So. I've been working in the
front end space for all my career,

23
00:01:38.640 --> 00:01:42.959
really since leaving university, and then
I've been at Google now just over four

24
00:01:42.040 --> 00:01:45.400
years. And it was sort of
four and a half years ago to a

25
00:01:45.439 --> 00:01:49.959
conference in the Netherlands. I did
a talk on how the company I was

26
00:01:49.000 --> 00:01:53.760
at before Google, we were using
React and building components and it's kind of

27
00:01:53.799 --> 00:01:59.439
rearchitecting our front end component driven manner, talking about kind of design systems and

28
00:01:59.480 --> 00:02:02.560
the reason reusability and all that kind
of stuff. And someone sat in the

29
00:02:02.560 --> 00:02:07.439
audience happened to be working at Google
on dev tools and had a space on

30
00:02:07.480 --> 00:02:12.159
their team looking to hire someone in
the London office, and so he spoke

31
00:02:12.199 --> 00:02:15.879
to me afterwards, and I applied
and kind of went through the interview process

32
00:02:15.919 --> 00:02:20.680
and all that stuff, and thankfully
came out the other side intact and with

33
00:02:20.719 --> 00:02:23.319
a job offer. So that was
that, and then yeah, four years,

34
00:02:23.479 --> 00:02:29.039
four years later, I'm still still
here. Oh wow, Yeah,

35
00:02:29.560 --> 00:02:34.000
yeah it was. It's been an
interesting ride for sure. So your background

36
00:02:34.080 --> 00:02:37.439
is all web tech, because you
know, obviously, when you think about

37
00:02:37.439 --> 00:02:43.280
somebody who's working effectively in the Chrome
browser, you also think about, hey,

38
00:02:43.319 --> 00:02:46.479
that person needs to be coding in
C plus plus or stuff like that.

39
00:02:47.120 --> 00:02:51.159
Yeah. So I have a computer
science degree, but after that,

40
00:02:51.240 --> 00:02:54.199
the majority of my experience has been
frontend. I've certainly never done any C

41
00:02:54.560 --> 00:02:59.280
C plus plus or anything in that
region. I was a Ruby developer for

42
00:02:59.319 --> 00:03:02.479
a while. I've kind of dabbled
with various languages, but professionally, yeah,

43
00:03:02.479 --> 00:03:07.919
the majority of my time has been
JavaScript, Typescript and various front end

44
00:03:07.919 --> 00:03:12.840
tech. The thing with devtils is
there's actually a web application itself, So

45
00:03:12.919 --> 00:03:17.560
the entire Creme devtils is built with
HTMLCSS and typescript and it gets embedded into

46
00:03:17.599 --> 00:03:22.639
Chrome. So although I don't have
the background to dive into the sort of

47
00:03:22.680 --> 00:03:27.520
blank chromeum backend side, I'm very
able to be very productive on the front

48
00:03:27.599 --> 00:03:32.400
end, you know, and work
on devtels. So when I was a

49
00:03:32.439 --> 00:03:38.560
new developer, one of the my
mentor Basically, we would joke that we

50
00:03:38.560 --> 00:03:42.879
were going to write an application that
it was code quality, not performance,

51
00:03:42.960 --> 00:03:46.680
but it was going to be a
really simple app that you would submit your

52
00:03:46.680 --> 00:03:49.000
code and it would just come back
and say, this code is terrible,

53
00:03:50.319 --> 00:03:55.199
right, because everybody's code is terrible. So so isn't the correctness problem like

54
00:03:55.240 --> 00:04:01.560
an NP complete problem? I don't
know, But how do you write a

55
00:04:01.599 --> 00:04:09.599
performance tool that's useful and not just
your performances offul Yeah? Yeah, that's

56
00:04:09.680 --> 00:04:13.520
the challenge I think. I think
as well, a lot of performance is

57
00:04:13.520 --> 00:04:16.360
about contextualizing it. So you know, depending on the type of app you

58
00:04:16.439 --> 00:04:20.720
have or website and how it's used
and the average user and what technology they

59
00:04:20.800 --> 00:04:26.600
use to access, the sort of
what we mean by good or bad performance

60
00:04:26.639 --> 00:04:29.439
can vary a lot. So I
think the constant challenge for us is trying

61
00:04:29.480 --> 00:04:32.360
to strike that balance. And also
I think that the balance we have is

62
00:04:33.160 --> 00:04:35.360
we hear the feedback all the time. If you load up, you know,

63
00:04:35.399 --> 00:04:39.879
go to a big website and run
a use the Devitol's performance panel to

64
00:04:40.360 --> 00:04:44.519
reload the page and recorder trace,
you get presented with this this flame chart

65
00:04:44.639 --> 00:04:47.600
and this stuff, and there's just
boxes and different colors everywhere, and there's

66
00:04:48.040 --> 00:04:53.800
various lines and markers and all sorts, and it is very overwhelming if you've

67
00:04:53.839 --> 00:04:56.399
never used the tool before. Even
if you have used the tool before,

68
00:04:56.439 --> 00:04:58.920
it can be like, oh my
goodness, where do I even begin to

69
00:04:59.040 --> 00:05:01.959
start with. So, yeah,
that's kind of what you're alluding to is

70
00:05:02.199 --> 00:05:05.759
similar to the battle we have of
we want to show all this information so

71
00:05:05.800 --> 00:05:10.759
you can debug and dive in and
understand truly why your website is, let's

72
00:05:10.759 --> 00:05:14.199
say, loading slowly, but equally
we don't want to we'd want to try

73
00:05:14.240 --> 00:05:16.160
and not overwhelm me with all this
information upfront. And that's kind of the

74
00:05:16.480 --> 00:05:19.800
never ending tension that we we have. And I don't think right now we've

75
00:05:19.879 --> 00:05:24.120
kind of struck the right balance,
but it's something we're trying to resolve and

76
00:05:24.199 --> 00:05:28.000
work on. Yeah, it's funny
you said flame chart. In my brain

77
00:05:28.040 --> 00:05:30.680
immediately went to there's a fire here, and there's a fire here there.

78
00:05:32.720 --> 00:05:36.519
In the case of the tools,
it's an upside down flame chart. The

79
00:05:36.560 --> 00:05:43.000
fire is burning downwards, right yeah, yeah, yeah, so yeah,

80
00:05:43.240 --> 00:05:46.000
and other tools will show it the
other way. With the you know,

81
00:05:46.079 --> 00:05:49.959
flipped there's a lot of different ways
you can slice the data, and I

82
00:05:50.000 --> 00:05:54.639
think, yeah, one of the
challenges as well is how do how do

83
00:05:54.680 --> 00:05:58.439
we get people to understand interpret what
we're showing them correctly? Right, and

84
00:05:59.040 --> 00:06:03.680
that is different. But before we
dive into the details of this or that

85
00:06:04.639 --> 00:06:10.600
death tools performance well dep Tools panel
in general, I want to first of

86
00:06:10.600 --> 00:06:15.959
all point out what an amazing tool
dev tools are, and people and the

87
00:06:16.040 --> 00:06:21.680
people today kind of take them for
granted. And we've actually had an episode

88
00:06:21.759 --> 00:06:26.519
about dev tools. It's more in
general, I forget who came on the

89
00:06:26.519 --> 00:06:30.040
show to talk about this from somebody
else on your team will need to check

90
00:06:30.480 --> 00:06:33.839
afterwards, Michael Halis, I think, yes, yes, it was,

91
00:06:34.000 --> 00:06:38.839
Yes, it was. Thank you
for reminding me. I still remember the

92
00:06:38.920 --> 00:06:43.240
days. You know, I'm old
enough to remember when we didn't have such

93
00:06:43.279 --> 00:06:49.879
tooling, and you know how we
would debug things with alerts and and afterwards

94
00:06:49.879 --> 00:06:55.920
we got it that what are you
talking about? And how Yeah, well,

95
00:06:55.959 --> 00:06:59.240
at least now you can console log
which is at least a bit better.

96
00:06:59.720 --> 00:07:02.319
Uh. And then we got it
for desktops, but initially didn't have

97
00:07:02.360 --> 00:07:08.160
it for mobile, and then we
got the ability to actually do it on

98
00:07:08.240 --> 00:07:12.160
mobiles. So I think to a
great extent, the modern web as we

99
00:07:12.240 --> 00:07:17.399
know it today could not exist without
dev tools. And of all the dev

100
00:07:17.439 --> 00:07:21.920
tools in all the browsers, I
like Chrome dev tools or you know,

101
00:07:23.120 --> 00:07:29.879
Chromium depth tools, let's say the
most. So kudos for that. Also.

102
00:07:30.040 --> 00:07:33.360
The other thing I wanted to mention
is that if we look at the

103
00:07:33.439 --> 00:07:39.600
panels in Chrome depv tools, like
half of them they have to do with

104
00:07:39.720 --> 00:07:43.560
performance, and in one way or
another, like the network tab, the

105
00:07:43.600 --> 00:07:47.399
performance tab, the Performance info tab, the lighthouse tab, the memory tab

106
00:07:47.839 --> 00:07:50.600
keeps on. The list goes on
and on. Yeah, I have to

107
00:07:50.639 --> 00:07:57.319
say just to add to this.
You know, initially, when I got

108
00:07:57.360 --> 00:08:00.720
into and realized that there were dev
tools in there, right, I think

109
00:08:00.759 --> 00:08:03.120
the first ones I saw were on
Firefox, Right, I was like,

110
00:08:03.160 --> 00:08:05.720
oh, this is him, right, And so then I'm starting to use

111
00:08:05.720 --> 00:08:11.720
some of the same tools on Chrome. Once I start using Chrome, and

112
00:08:11.759 --> 00:08:15.360
then somebody showed me the network tab
and my mind was blown, right,

113
00:08:15.839 --> 00:08:18.720
and then somebody showed me one of
the other tabs I don't remember, and

114
00:08:18.759 --> 00:08:20.160
you know, it was like,
whoa, this does so much more.

115
00:08:20.639 --> 00:08:24.480
And so you know, I have
to admit I haven't really deeply used the

116
00:08:24.480 --> 00:08:28.800
performance tab. So I'm hoping you're
gonna tell me, Yeah, well you've

117
00:08:28.839 --> 00:08:33.919
been missing out and here's here's what
it does, hopefully. Yeah. I

118
00:08:33.960 --> 00:08:37.080
think that the first development tools I
remember using were Firebug. I think it

119
00:08:37.120 --> 00:08:41.679
was called I think it was an
extension to five fox, like a third

120
00:08:41.720 --> 00:08:46.000
party thing. I'm to install it. Yeah. Yeah. And the first

121
00:08:46.039 --> 00:08:48.960
time, I think, I think
I was debugging some CSS issue and the

122
00:08:48.000 --> 00:08:52.399
first time I realized that using Firebug
I could adjust the CSS in the tool

123
00:08:52.440 --> 00:08:58.360
and have it real time update was
just incredible to me. Yeah, And

124
00:08:58.399 --> 00:09:01.440
obviously the tools have come a long
way since that. Fire Bug will always

125
00:09:01.639 --> 00:09:05.799
I'll always remember that whenever we talk
about the tools in any any situation.

126
00:09:05.879 --> 00:09:09.600
I think, yeah, I had
the neat little bug icon in the toolbar.

127
00:09:09.440 --> 00:09:13.879
Yeah. So, so you want
to give us kind of the ten

128
00:09:13.919 --> 00:09:18.240
thousand foot view on the performance panel, and what I guess what I'm looking

129
00:09:18.279 --> 00:09:24.919
for is sort of a how do
you expect developers to use it? And

130
00:09:24.480 --> 00:09:28.000
also, well, let's just start
there because I can't remember what the other

131
00:09:28.039 --> 00:09:33.039
piece was. Sure. Yeah,
So really, I think when we talk

132
00:09:33.080 --> 00:09:37.000
about performance, or when people think
about web performance within the context of Chrome

133
00:09:37.080 --> 00:09:41.720
and Google and all of that,
we're really talking about the core web vitals,

134
00:09:41.759 --> 00:09:45.519
which are these metrics that the Google
has that we want that we think

135
00:09:45.600 --> 00:09:50.919
represent kind of better performing websites that
provide better experiences to use us. So

136
00:09:50.960 --> 00:09:54.039
we expect most people using the Performance
channel would be debugging their core web vital

137
00:09:54.120 --> 00:10:00.480
scores. Two of the cowed vitals
broadly. In fact one sorry LCP,

138
00:10:00.600 --> 00:10:03.200
which is largest contemporal paint. We
can divers deep into what these mean or

139
00:10:03.240 --> 00:10:07.000
or don't mean, but LCP really
represents how quickly or not your page was

140
00:10:07.039 --> 00:10:11.480
loaded and visible to the user and
they could kind of read it and see

141
00:10:11.559 --> 00:10:16.960
kind of what the content is.
And so that's really all about loading speed,

142
00:10:16.960 --> 00:10:20.039
what is delaying loading your website,
And that's one thing that the Performance

143
00:10:20.080 --> 00:10:24.519
Panel is really good at. You
will record your website loading. It shows

144
00:10:24.519 --> 00:10:28.720
you screenshots of the process as various
elements loaded and were rendered. It shows

145
00:10:28.720 --> 00:10:31.320
you the network requests, and it
shows you all the JavaScript that was happening

146
00:10:31.399 --> 00:10:35.000
at the same time. So that
becomes a very good way to see ol

147
00:10:35.120 --> 00:10:39.399
there's this bundle of JavaScript that was
five megabytes in size that took ten seconds

148
00:10:39.440 --> 00:10:43.799
to download that that I can see
visually that stopped my page rendering and showing.

149
00:10:46.039 --> 00:10:48.759
Then you also have CLS, which
is layout shifts, so that's content

150
00:10:48.759 --> 00:10:52.000
shifting around the page as it's loading. In the classic example here is like

151
00:10:52.039 --> 00:10:54.720
the user goes to click a button
and as they do it, another button

152
00:10:54.720 --> 00:10:58.559
loads in and they click the wrong
button. Can probably frustrating, as they

153
00:10:58.320 --> 00:11:01.399
happened to me before for and it
didn't make me really really angry either.

154
00:11:03.279 --> 00:11:05.159
I've had it. I've had it
before, Like a banner has popped into

155
00:11:05.200 --> 00:11:13.000
the tops by fifty pixels. It's
very frustrating on especially the banners. It's

156
00:11:13.080 --> 00:11:16.120
mostly the banners. Yeah, that's
what we'll do it most of the time.

157
00:11:18.120 --> 00:11:20.080
But again that's the kind of thing
we'll show you, and you again

158
00:11:20.200 --> 00:11:24.159
using screenshots you can see kind of
before and after those and try and figure

159
00:11:24.159 --> 00:11:28.240
out what element was responsible for that
and go from there. And the final

160
00:11:28.240 --> 00:11:33.080
web vital is called i NP.
It stands for Interaction to Next Paint.

161
00:11:33.120 --> 00:11:35.279
Broadly, it measures how responsive and
interactive your pages. So when the user

162
00:11:35.279 --> 00:11:39.159
clicks on let's say button, how
long is it until the UI updates to

163
00:11:39.200 --> 00:11:43.120
show them that you know, your
your app has dealt with that button click

164
00:11:43.159 --> 00:11:46.279
and is processing or has registered it, or is doing whatever I'd say,

165
00:11:46.320 --> 00:11:52.080
typically because that's newer and debugging sort
of interactions where users have to interact with

166
00:11:52.120 --> 00:11:56.960
your page is harder. Debugging loading
speed is a bit easier because normally you

167
00:11:56.039 --> 00:12:01.360
can run the page, load,
you might change locally, rerun it again,

168
00:12:01.399 --> 00:12:05.840
and you can kind of replicate that
fairly straightforwardly. Interactions where you have

169
00:12:05.919 --> 00:12:07.480
to try and you know, click
a textbox type in at a certain time

170
00:12:07.519 --> 00:12:13.039
to hit some ed case which is
causing slowness can be trickier. But those

171
00:12:13.039 --> 00:12:16.440
are kind of what when we think
about what features we should be building and

172
00:12:16.480 --> 00:12:18.799
working on in the performance panel and
what kind of user journeys we want to

173
00:12:18.799 --> 00:12:24.240
make easier, it's those web vitals
that we're kind of motivated by. Really,

174
00:12:26.320 --> 00:12:30.639
gotcha? So how does that actually
show up in the panel? Right?

175
00:12:31.559 --> 00:12:33.200
Yeah? So the main panel is
made up of a series of what

176
00:12:33.240 --> 00:12:37.360
we call tracks, and these are
kind of horizontal roads that go all the

177
00:12:37.399 --> 00:12:41.360
way across the screen. These show
specific categories of events or things that happened.

178
00:12:41.399 --> 00:12:45.080
So and obvious one is the network
track. This will show you all

179
00:12:45.080 --> 00:12:48.919
the network requests that happened during that
timeframe, and it shows them as rectangles

180
00:12:48.919 --> 00:12:52.360
where these are representive time. So
the wider the rectangle, the longer that

181
00:12:52.399 --> 00:12:58.559
particular request took its flight. Simpification
because there are there are additional bars on

182
00:12:58.600 --> 00:13:07.720
over end which represent different parts of
the network. I wanted to you mentioned

183
00:13:07.759 --> 00:13:11.720
it. It's for those you know, it's kind of duplicate information with the

184
00:13:11.759 --> 00:13:18.039
network tab in the sense that you
can in both cases you can see the

185
00:13:18.039 --> 00:13:24.639
rectangles the kind of the waterfall that
represents the network activities. If just analyzing

186
00:13:24.679 --> 00:13:31.639
the network itself, and often that's
where I start. Then to be fair,

187
00:13:31.840 --> 00:13:37.240
I prefer doing that on the network
tab initially simply if for no other

188
00:13:37.320 --> 00:13:45.919
reason reason that it's much less busy. And but like you mentioned with the

189
00:13:46.000 --> 00:13:52.320
bars at the end, once I
start analyzing the overall activity of the page

190
00:13:52.480 --> 00:13:58.960
and start correlating the downloads with the
JavaScript activity, because I'd say a JavaScript

191
00:14:00.240 --> 00:14:05.639
is triggering a fetch request, and
then when that fetch request finishes, then

192
00:14:05.799 --> 00:14:09.960
JavaScript is triggered again to process the
results of that fetch request. So when

193
00:14:11.000 --> 00:14:18.039
I do that holistic analysis, that's
where the performance panel really shines. And

194
00:14:18.559 --> 00:14:22.559
you might want to explain, you
know, either an now or later those

195
00:14:22.720 --> 00:14:26.639
lines at the end, because like
you said, there's the actual bar itself

196
00:14:26.720 --> 00:14:31.600
that has like a like a lighter
color and a darker color for the but

197
00:14:31.720 --> 00:14:35.559
it also has the bars at the
beginning like the mustache. I think you

198
00:14:35.639 --> 00:14:39.919
call it at the beginning and the
end. Yeah, we call them whiskers.

199
00:14:41.600 --> 00:14:48.000
Whiskers Okay, yeah, same concept, you love it and yees.

200
00:14:48.039 --> 00:14:50.519
So I think you're right. If
you're debugging purely network issues, the network

201
00:14:50.519 --> 00:14:54.840
panel, I mean, just real
estate wise, has more room because it's

202
00:14:54.879 --> 00:14:58.200
only showing you network things, whereas
the force we have to get the network

203
00:14:58.240 --> 00:15:01.960
in alongside or the various the things
that we show. And yeah, the

204
00:15:03.039 --> 00:15:05.399
key thing with the performance panel,
I think is what Dan is touching on,

205
00:15:05.440 --> 00:15:07.600
is that you've got all these tracks
that have different types of information in

206
00:15:07.879 --> 00:15:11.840
but crucially they're all aligned based on
timestamp, so you can look vertically down

207
00:15:13.159 --> 00:15:16.360
and see exactly what all of these
different you know, what stuff was happening

208
00:15:16.360 --> 00:15:20.080
at this particular timestamp, so what
network requests were happening. Then we jumped

209
00:15:20.080 --> 00:15:22.679
to a track that shows a screenshot
of your page at that given time.

210
00:15:22.759 --> 00:15:26.159
Okay, so this is what the
pagent like. Then we jumped to any

211
00:15:26.200 --> 00:15:28.759
layout shifts that happened at that time, and then it's main thread activity,

212
00:15:28.799 --> 00:15:33.759
which really is what heavy jobscript was
running, let's say re rendering you know,

213
00:15:33.840 --> 00:15:37.480
an Angular component or a React component
or whatever else it may be.

214
00:15:37.519 --> 00:15:41.600
So where the performance panel, I
think it is power comes from is at

215
00:15:41.600 --> 00:15:45.039
any point in time you can see
across a load of different categories what the

216
00:15:45.080 --> 00:15:48.879
browser was having to do to provide
the user with your website or web application.

217
00:15:50.559 --> 00:15:52.559
You know, it's funny you're talking
about all of this, and I

218
00:15:52.559 --> 00:15:56.840
can imagine why it's hard for you
to figure out how to give people a

219
00:15:56.879 --> 00:16:00.960
concise picture of the thing. Yeah, oh yeah, for sure. The

220
00:16:02.960 --> 00:16:07.799
performance panel is I think by far
the busiest of all the panels. To

221
00:16:07.840 --> 00:16:12.919
the extent, I think that you
created the Performance Insights panel to provide a

222
00:16:14.080 --> 00:16:19.240
slightly less busy view, as it
were. But on the other hand,

223
00:16:19.679 --> 00:16:25.240
once you grasp it and you master
it, I think it really becomes a

224
00:16:25.279 --> 00:16:32.720
superpower like it definitely takes you to
the next level in terms of your abilities

225
00:16:32.799 --> 00:16:37.159
to analyze and understand what the web
page is doing. Yeah, and so

226
00:16:37.919 --> 00:16:41.559
to touch on the Performance Insights panel, so this is a distinct panel from

227
00:16:41.600 --> 00:16:45.720
the performance panel, very confusingly named. I'll give you that one. We

228
00:16:45.840 --> 00:16:51.559
noted this I think last year.
It's very much an experimental panel. The

229
00:16:51.600 --> 00:16:56.840
goal is to kind of explore how
we could without without hiding away all this

230
00:16:56.960 --> 00:16:59.480
detail, which, as Dan said, once you kind of understand it and

231
00:16:59.480 --> 00:17:03.240
what it's repped venting, is really
powerful and really actually dive deep. But

232
00:17:03.320 --> 00:17:07.000
for users maybe newer to the sort
of this topic is very overwhelming. So

233
00:17:07.079 --> 00:17:11.799
the Performance Insights panel was an experiment
and how can we pull out what we

234
00:17:11.880 --> 00:17:15.480
call insights and try and guide the
user to, hey, here's here's a

235
00:17:15.480 --> 00:17:18.839
problem that caused your page load in
a way that didn't need them to dive

236
00:17:18.880 --> 00:17:23.680
into all the nitty gritty detail.
It was I think semi successful. The

237
00:17:23.680 --> 00:17:27.799
feedback was at a good mix of
hey, this is really useful this sort

238
00:17:27.799 --> 00:17:32.480
of high level view to hey,
this is cool, but because I want

239
00:17:32.519 --> 00:17:33.759
another level of detail, I will
never use this, I will always use

240
00:17:33.759 --> 00:17:37.799
the performance panel. And long term, we didn't really ever want to maintain

241
00:17:37.880 --> 00:17:42.920
two distinct panels for the foreseeable future. So actually the Performance Insights panel will

242
00:17:42.960 --> 00:17:48.000
eventually be removed, but what we
learned from that in terms of insights will

243
00:17:48.680 --> 00:17:52.200
be coming into the performance panel.
There's a blog post, which we can

244
00:17:52.240 --> 00:17:55.240
link to, I guess in the
show notes, so I can put on

245
00:17:55.839 --> 00:17:59.079
chat where we kind of talk more
about these plans. But yeah, we're

246
00:17:59.079 --> 00:18:00.759
trying to figure out a world where
we can give people these useful kind of

247
00:18:00.759 --> 00:18:04.880
insights like hey, this particular network
request was the source of a lot of

248
00:18:04.920 --> 00:18:10.079
problems for you in this this pageload, but also provide all the data so

249
00:18:10.200 --> 00:18:14.519
people like Dan can dive in and
find exactly what they're looking for. So

250
00:18:14.640 --> 00:18:18.359
first of all, it's news to
me that performance insights is kind of a

251
00:18:18.440 --> 00:18:26.480
temporary thing. So thank you for
highlighting this. And you know what you

252
00:18:26.519 --> 00:18:34.160
should do? The answer is AI
the chace. Yeah, we're still figuring

253
00:18:34.200 --> 00:18:38.880
out exactually how AI slots into all
this. But yeah, yeah you're at

254
00:18:38.920 --> 00:18:42.480
Google. So I was going to
say you handed off to chet GPT,

255
00:18:42.599 --> 00:18:45.960
but you handed off to Gemini and
say, yeah, here's the output.

256
00:18:47.039 --> 00:18:49.720
What do you what do you make
of this? Yeah, something like that.

257
00:18:52.720 --> 00:18:56.319
It's so hard as well, because
I really learned this when I started

258
00:18:56.319 --> 00:19:00.799
working on building the performance panel and
understanding behind the scenes the thing that powers

259
00:19:00.799 --> 00:19:03.440
the performance panel in these flame charts, So what are called trace events?

260
00:19:03.440 --> 00:19:08.279
And these are really just objects of
data that Chrome emits during a page load,

261
00:19:10.559 --> 00:19:11.920
and you begin to see, Okay, so every time I have this

262
00:19:11.960 --> 00:19:15.119
event, I'll always have this other
event that is named like this, and

263
00:19:15.160 --> 00:19:18.960
you can try and build relationships between
these events. But then you release this

264
00:19:19.000 --> 00:19:22.079
feature into the world, and you
know, a thousand people use it across

265
00:19:22.079 --> 00:19:25.799
a thousand different websites, and they
just blow all your assumptions out of the

266
00:19:25.799 --> 00:19:30.160
window because there's such a variety of
technologies and approaches and all the rest of

267
00:19:30.200 --> 00:19:37.319
it. And so the challenge with
ANYAI would be useful, whilst not kind

268
00:19:37.319 --> 00:19:40.759
of pigeonhole and I think into a
few certain categories, but yeah, who

269
00:19:40.839 --> 00:19:44.799
knows. I'm sure it'll be a
space will be exploring along with the rest

270
00:19:44.799 --> 00:19:48.720
of the Internet at some point.
So one of the going back to the

271
00:19:48.799 --> 00:19:55.640
details of the performance panel, I
think one of the things that confuses people

272
00:19:55.680 --> 00:20:02.119
them boast about it is the fact
that it simultaneously shows two timelines. At

273
00:20:02.160 --> 00:20:07.839
the very top, you have a
timeline that encompasses the entirety of the recorded

274
00:20:07.920 --> 00:20:14.440
period, while slightly below it you
have like a partial timeline. Yeah,

275
00:20:14.480 --> 00:20:18.039
so we have the mini map I
would call it the top, which shows

276
00:20:18.039 --> 00:20:22.799
sort of the activity over the whole
trace period. But then what we let

277
00:20:22.799 --> 00:20:26.359
people do is there's two kind of
handles which you can drag to select a

278
00:20:26.440 --> 00:20:30.519
subset, and then the rest of
the panel is scoped to that subset.

279
00:20:30.640 --> 00:20:33.880
The idea being that you can quickly
zoom in on a period of time that

280
00:20:33.960 --> 00:20:38.240
is particularly interesting to you. That's
one of the things we shipped I Lose

281
00:20:38.279 --> 00:20:41.960
Track of Time earlier this year is
the ability to once you zoomed in,

282
00:20:42.000 --> 00:20:45.359
you can actually click a button and
kind of zoom in again and save that

283
00:20:45.440 --> 00:20:49.920
zoomed in state. But one of
the things we're thinking about it was something

284
00:20:49.960 --> 00:20:53.400
we want to do with the Performance
Insights panel didn't ever get around to it

285
00:20:53.440 --> 00:20:57.759
was could we, for example,
automatically detect areas of interest and provided with

286
00:20:57.920 --> 00:21:03.720
short cuts to to particular time spans
that we think contain the most relevant information.

287
00:21:04.160 --> 00:21:07.759
So if you've got a page that
takes five six seconds to load,

288
00:21:07.880 --> 00:21:11.119
clearly that's not good and you'd like
to get that down. But normally there'll

289
00:21:11.160 --> 00:21:15.119
be three or four culprits within that
six seconds where where your attention is best

290
00:21:15.240 --> 00:21:18.880
focused. Well, you do kind
of do it already, don't you.

291
00:21:18.960 --> 00:21:22.160
I mean already. When you record
the page load, you often like zoom

292
00:21:22.240 --> 00:21:27.000
into a particular period of interest in
issue. We will, but that's not

293
00:21:27.240 --> 00:21:32.079
because it's we've identified that period as
interesting. It's because we've identified the rest

294
00:21:32.079 --> 00:21:36.160
of the traces effectively dead space.
So this is the example here is say

295
00:21:36.160 --> 00:21:40.799
you record for ten seconds and all
the activity happens in the first three seconds,

296
00:21:40.839 --> 00:21:44.279
We'll try and zoom into those three
seconds. So really we're just trying

297
00:21:44.279 --> 00:21:47.599
to trim if there's dead space at
the start or end of your timeline,

298
00:21:47.599 --> 00:21:51.799
we're trying to get rid of that. We're not really identifying like this is

299
00:21:51.839 --> 00:21:55.319
where there was a slow network requests, and so we should draw the users

300
00:21:55.359 --> 00:21:59.359
attention to that. That's kind of
something I think on our radar to to

301
00:21:59.480 --> 00:22:04.680
explore that that idea generally of can
we highlight areas of interest? And it's

302
00:22:04.680 --> 00:22:08.160
something that in Lighthouse, if you
do a Lighthouse report on a page,

303
00:22:08.519 --> 00:22:12.519
will also show you estimated savings for
a bunch of the audits. So Lighthouse

304
00:22:12.519 --> 00:22:17.359
will say this image that you loaded
was you know, ex megabyte big.

305
00:22:17.440 --> 00:22:22.960
If you convert it to whatever and
optimize it, you might save one second

306
00:22:22.000 --> 00:22:26.359
on this network request. And so
what we could do is we could begin

307
00:22:26.440 --> 00:22:29.720
to rank, you know, things
we find based on how much potential savings

308
00:22:29.759 --> 00:22:33.519
we think there might be to help
the developer prioritize as well, because I

309
00:22:33.519 --> 00:22:37.640
think, you know, in a
perfect world, developers have endless amounts of

310
00:22:37.680 --> 00:22:41.559
time to spend optimizing every millisecond of
their page load. But you know,

311
00:22:41.640 --> 00:22:45.279
we all know that's not true,
and sometimes this work is prioritized against other

312
00:22:45.359 --> 00:22:47.680
work and you don't get to spend
as much time as you like on it.

313
00:22:48.119 --> 00:22:52.519
So, like, can we direct
you to the most impactful things sooner,

314
00:22:52.559 --> 00:22:56.799
so that if you only have a
few hours or a day to work

315
00:22:56.839 --> 00:23:00.759
on this thing for your company,
you can have the most impact. By

316
00:23:00.799 --> 00:23:07.680
the way, you kind of mentioned
here how you can maybe cross pollinate between

317
00:23:07.839 --> 00:23:15.000
Lighthouse and the DEPV tools by bringing
Lighthouse insights into the performance panel. I

318
00:23:15.039 --> 00:23:22.279
would like to mention that one cool
feature of the Lighthouse that is built into

319
00:23:22.319 --> 00:23:30.400
DEAV tools is that you can jump
from Lighthouse into the performance panel for that

320
00:23:30.519 --> 00:23:34.359
Lighthouse session. Oh wow. Yeah, So you can click a link and

321
00:23:34.359 --> 00:23:38.559
it will take you into the performance
panel with the recording of the pageload that

322
00:23:38.640 --> 00:23:44.480
Lighthouse used, so you can dive
in and it's actually something we're working on,

323
00:23:44.519 --> 00:23:48.200
and this is in our blog posts
from earlier this year, is we

324
00:23:48.240 --> 00:23:52.400
are literally working on integrating lighthouses kind
of analysis tools deeply into the performance panel.

325
00:23:52.720 --> 00:23:56.680
So the long time vision is that
there won't be a distinct lighthouse panel

326
00:23:56.759 --> 00:24:02.359
within death Tools, not because we're
removing that functionality, but it will kind

327
00:24:02.400 --> 00:24:06.920
of be combined into the performance panel. The exact details obviously to be ironed

328
00:24:06.920 --> 00:24:08.480
out, and there will be a
lot of experimentation on how we do this,

329
00:24:10.119 --> 00:24:12.359
but that is something that we're kind
of working on, and just to

330
00:24:12.359 --> 00:24:17.200
be very explicit, that isn't lighthouse
going away. It's it's meaning. So

331
00:24:17.279 --> 00:24:19.359
if you want to work on performance
and dev tools, you go to the

332
00:24:19.359 --> 00:24:23.880
Performance panel and you don't have to
decide between the performance panel or the Performance

333
00:24:23.920 --> 00:24:27.240
Insights panel or the lighthouse panel.
We're trying to kind of collate the better

334
00:24:27.319 --> 00:24:34.000
everything into one panel. That is
the place to go. So when we

335
00:24:34.160 --> 00:24:40.839
record a session within the Performance panel, one the obvious way is simply just

336
00:24:41.039 --> 00:24:44.839
click the record button, which start
a recording, and then you can do

337
00:24:44.880 --> 00:24:49.279
whatever you want, including reloading the
page, and then you explicitly stop the

338
00:24:49.359 --> 00:24:53.960
recording when you want. The other
option is to click the reload button,

339
00:24:55.000 --> 00:25:00.480
which automatically instigate a reload of the
page with the recording and and then also

340
00:25:00.559 --> 00:25:07.640
automatically stops the recording when loading is
complete. How do you determine when to

341
00:25:07.680 --> 00:25:11.480
stop the loading? By the way, in that scenario, Oh, you're

342
00:25:11.519 --> 00:25:17.640
pushing my memory of the code.
But I'm pretty sure it's after a particular

343
00:25:17.960 --> 00:25:22.279
event, a particular page load event. I think we wait a few more

344
00:25:22.319 --> 00:25:26.000
seconds, I think, but you
I'd have to, I'd have to look

345
00:25:26.039 --> 00:25:30.799
up the exact inmentation, But I
think it's it's something fairly straightforward, like

346
00:25:30.839 --> 00:25:34.359
wait for this particular event and then
allow a few seconds of grace for anything

347
00:25:34.359 --> 00:25:37.720
else to flow in. But yeah, the idea with that one is is

348
00:25:37.720 --> 00:25:41.720
we expect people to use that when
they're explicitly debugging their pages load time.

349
00:25:42.039 --> 00:25:45.920
So we wait for when the event
that basically tells us that the page is

350
00:25:45.960 --> 00:25:48.279
loaded, give a few extra seconds
just in case, and then and then

351
00:25:48.319 --> 00:25:53.559
stop if I remember rightly, but
don't quote beyond that. So usually when

352
00:25:53.599 --> 00:25:57.839
I'm loading a page, you know, in some if in some cases,

353
00:25:59.200 --> 00:26:03.400
let's put it differently, when it
works, I like to use the reload

354
00:26:03.440 --> 00:26:08.079
button simply because it's the faster option. I have run into some cases with

355
00:26:08.240 --> 00:26:15.559
some websites where it stopped too soon, and then my only recourse was to

356
00:26:15.640 --> 00:26:22.200
actually click the record explicitly, reload
explicitly, and then stop it explicitly when

357
00:26:22.240 --> 00:26:27.559
it's done. But yeah, when
the reload works automatically, it's the cleaner,

358
00:26:27.640 --> 00:26:33.400
it's the nicer option. Now,
as long as we're talking about that,

359
00:26:33.599 --> 00:26:40.000
though, another thing or another suggestion
that I have or a gotcha to

360
00:26:40.079 --> 00:26:47.119
watch out for is a lot of
people just analyze the loading performance in a

361
00:26:47.160 --> 00:26:52.519
regular tab in the regular browser,
and that means that they're also kind of

362
00:26:52.640 --> 00:26:56.759
profiling all their extensions, which may
not be what they want to do.

363
00:26:57.359 --> 00:27:03.000
So very often what you really want
to do is to try to analyze it

364
00:27:03.119 --> 00:27:06.160
in you know, in the middle
at least to begin with, in in

365
00:27:06.240 --> 00:27:11.039
the most in the cleanest environment possible. And in that context, I wanted

366
00:27:11.079 --> 00:27:14.960
to ask you because there are really
two ways to achieve it. One way

367
00:27:15.000 --> 00:27:18.759
is to simply open up an incognito
window and and you know, do the

368
00:27:18.799 --> 00:27:26.640
recording and that. Another option is
to create a profile just for debugging purposes,

369
00:27:26.720 --> 00:27:30.160
So basically, just create a local
profile has no extensions in it and

370
00:27:30.319 --> 00:27:36.480
use that, which would you recommend. I don't think it makes too much

371
00:27:36.480 --> 00:27:41.480
difference. I think I'm trying to
remember if people would have to think about

372
00:27:41.480 --> 00:27:47.079
casing if they had a distinct profile, because also you need to often you

373
00:27:47.119 --> 00:27:51.200
want to make sure in dentals that
the in the network panel you've you've de

374
00:27:51.319 --> 00:27:55.839
selected or ticked rather disabled cash in
order to get kind of a fresh page

375
00:27:55.839 --> 00:27:59.799
load. So trying to remember if
incognito effectively, But it wouldn't matter if

376
00:27:59.799 --> 00:28:02.680
you has the same website a few
times in the same incompanies have tabed,

377
00:28:02.720 --> 00:28:04.839
So I think it's really a matter
of personal preference. But yeah, that

378
00:28:04.920 --> 00:28:08.319
is a common kind of gotcha that
when you're reloading the page, you are

379
00:28:08.880 --> 00:28:12.519
reloading the page within your your active
Creren profile, and we can't do anything

380
00:28:14.400 --> 00:28:18.519
to stop all those various extensions and
whatnot running. So yeah, we do

381
00:28:18.559 --> 00:28:22.759
recommend one of those approaches IDV for
traces, if you're trying to be the

382
00:28:22.799 --> 00:28:26.720
most accurate. I think another kind
of on that same theme, we see

383
00:28:26.759 --> 00:28:32.279
people testing a lot on their very
fast Ethernet connection in their office in the

384
00:28:32.319 --> 00:28:37.200
center of some big city which has
amazing connection speeds. Generally, I think

385
00:28:37.960 --> 00:28:41.160
people need to consider they should be
throttling the network, which is something you

386
00:28:41.160 --> 00:28:45.319
can do from within the panel before
you start a recording, to try and

387
00:28:45.400 --> 00:28:51.119
emulate, say a three G connection
or something slower, if your users maybe

388
00:28:51.160 --> 00:28:55.000
are typically on mobile a bit more, or if generally your users just aren't

389
00:28:55.000 --> 00:29:00.400
on a big Ethernet connection. So
one other thing with mobile is and I

390
00:29:00.400 --> 00:29:03.759
think I've seen people do this,
but I'm not sure exactly how. And

391
00:29:03.759 --> 00:29:07.400
I guess this is more a general
dev tools question than a performance question.

392
00:29:07.480 --> 00:29:12.200
But if I load the app on
my phone sometimes it does things a little

393
00:29:12.240 --> 00:29:17.640
differently anyway. Yeah, so is
there a way to hook up my dev

394
00:29:17.680 --> 00:29:22.559
tools on my computer so that I
can watch the performance on my phone?

395
00:29:22.359 --> 00:29:26.839
Yeah? There is, So you
would plug in your phone via a USB

396
00:29:26.000 --> 00:29:30.640
lead, And then there is there's
deb tools remote debugging. I don't quite

397
00:29:30.640 --> 00:29:33.400
remember the steps get it working,
but there'll be documentation. But yeah,

398
00:29:33.440 --> 00:29:38.799
that isn't it explicitly supported use case
you can do it? I think yes,

399
00:29:38.960 --> 00:29:45.160
you definitely can. There's just one
really important caveat which goes to the

400
00:29:45.240 --> 00:29:49.920
episode we recently recorded with Bruce Lawson, and that's the fact that Chrome on

401
00:29:51.039 --> 00:29:57.079
iPhone is not Chrome. So if
you want to if you want to debug

402
00:29:57.400 --> 00:30:03.319
Chrome on a mobile device, you
can debug Chrome on an Android device.

403
00:30:03.759 --> 00:30:07.200
But if you want to debug Chrome
on an iPhone, that's kind of a

404
00:30:07.240 --> 00:30:11.759
problem because it's not really Chrome.
Yeah. Well that's just another reason.

405
00:30:11.799 --> 00:30:15.359
Since it's a different engine and everything, right, because it's all using the

406
00:30:15.440 --> 00:30:22.240
WebKit engine exactly, then then I
definitely want to be checking it out right

407
00:30:22.359 --> 00:30:26.680
because it may it may do something
entirely completely different or do it in a

408
00:30:26.680 --> 00:30:30.319
different way. It will, but
the problem is that you I don't think

409
00:30:30.359 --> 00:30:41.279
you can use Chrome dev tools to
debug uh and Safari Safari and Chrome on

410
00:30:41.400 --> 00:30:47.720
iPhone is effectively Safari. So you
know, until we finally get Chrome on

411
00:30:47.839 --> 00:30:52.119
an iPhone, you know, fingers
crossed. I you know, it's so

412
00:30:52.160 --> 00:30:56.759
for now, if you if you
really want to do the mobile debugging rather

413
00:30:56.839 --> 00:31:02.480
than simulating a mobile device, you
really have to use an Android device.

414
00:31:03.480 --> 00:31:07.440
Yeah, yeah, correct. Now, so we we talked about the the

415
00:31:07.559 --> 00:31:12.599
tracks, thet the structure of of
the panel that on the on the at

416
00:31:12.640 --> 00:31:17.519
the top you have you called it
the mini view. How how did you

417
00:31:17.559 --> 00:31:22.720
call it the mini map? The
mini map, and and you know,

418
00:31:22.839 --> 00:31:26.880
it's it's really a useful starting point, and you've added a lot of useful

419
00:31:26.920 --> 00:31:32.000
information into it. So you know, you've got the screenshots, You've got

420
00:31:32.240 --> 00:31:37.359
the graph showing periods of CPU activity
and even color coded to show what the

421
00:31:37.400 --> 00:31:44.039
CIPU is busy doing. I not
so long ago learned that when it's thatched,

422
00:31:44.480 --> 00:31:48.319
it means that it's activity. It's
the CIPU is busy, but it's

423
00:31:48.359 --> 00:31:55.759
off of the main thread. Is
that correct? I honestly couldn't tell you

424
00:31:55.799 --> 00:32:00.319
after my head about checking. So
there are there are kind of is this

425
00:32:00.440 --> 00:32:02.599
like the horizontal bars of the pair
or is this kind of thatched in the

426
00:32:02.640 --> 00:32:07.119
sort of Yeah, I'm so,
I'm talking about you know the graph at

427
00:32:07.279 --> 00:32:09.519
at the very top of the mini
map, you know where you see the

428
00:32:09.640 --> 00:32:15.759
yellow graph for the JavaScript for example, and occasionally you would see like a

429
00:32:15.880 --> 00:32:22.799
thatched pattern. Yeah, you also
have those small bars that are either dark

430
00:32:22.880 --> 00:32:27.599
red or light red for to indicate
long tasks. Sorry, yeah, yeah,

431
00:32:27.640 --> 00:32:32.039
so then the long tasks. I
don't remember the exact heuristic for why

432
00:32:32.599 --> 00:32:37.079
error is at thatched, but yeah, it will be something problematic, But

433
00:32:37.319 --> 00:32:40.240
I don't remember the exact criteria for
what it is off to my head.

434
00:32:40.680 --> 00:32:45.799
I would take that later on.
But by the way, long tasks or

435
00:32:45.960 --> 00:32:52.720
or or long frames sometimes they're called, are basically again, correct me if

436
00:32:52.759 --> 00:33:00.640
I'm wrong, are basically when the
main thread is busy and consequently is unable

437
00:33:00.839 --> 00:33:07.559
to produce the desired frame rate.
In other words, it's check yeah,

438
00:33:07.720 --> 00:33:13.000
exactly that. So the browser wants
to create a frame but is not able

439
00:33:13.039 --> 00:33:15.079
to. It's not here. Create
a frame basically means, you know,

440
00:33:15.160 --> 00:33:19.960
paint and update to the user,
update the website. It's unable to because

441
00:33:20.039 --> 00:33:22.799
jobscript is keeping the main thread busy
and therefore it browser doesn't get a chance

442
00:33:22.839 --> 00:33:25.720
to do it. So the best
way to kind of deal with that is

443
00:33:25.759 --> 00:33:31.920
ideally split up your jobscript into smaller
tasks. There are now APIs. I

444
00:33:31.960 --> 00:33:36.880
don't remember the stage there up,
but they're coming around scheduling. So there

445
00:33:36.880 --> 00:33:39.960
will be a scheduler API where you'll
be able to incue some code like a

446
00:33:39.960 --> 00:33:45.519
callback function to run, but tell
the browser what priority that callback functions should

447
00:33:45.559 --> 00:33:50.960
have. So there's more powerful scheduling
tools coming to the browser. They may

448
00:33:51.000 --> 00:33:53.880
already be in there, I don't
quite remember. But the kind of the

449
00:33:53.920 --> 00:33:58.400
way other people do this is you
can use the request animation frame call back.

450
00:33:59.039 --> 00:34:01.400
Historically, people you set time out
and gave it a function and then

451
00:34:01.440 --> 00:34:07.079
with a zero time which really just
gives the browser you know, a chance

452
00:34:07.679 --> 00:34:12.159
a gap to do some other work. So that's that's the main thing that

453
00:34:12.280 --> 00:34:15.639
is important with long task is it's
too much jobscript running without a break.

454
00:34:16.239 --> 00:34:21.039
Yeah. I'm kind of amused by
that because you know, we talk about

455
00:34:21.159 --> 00:34:25.320
ways to do splitting on IDOL,
callbacks, set time out like you mentioned,

456
00:34:25.400 --> 00:34:34.320
and other APIs that are coming.
But realistically, I think unfortunately a

457
00:34:34.320 --> 00:34:40.039
lot of web devs are not really
using these APIs directly anymore because we're working

458
00:34:40.119 --> 00:34:47.119
primarily inside frameworks like React or View
or Angular, and you know, they

459
00:34:47.199 --> 00:34:54.880
control where when our code runs and
how execution is partitioned. So for example,

460
00:34:57.599 --> 00:35:01.320
if you're using React, it's probably
about using suspense and use transition and

461
00:35:01.360 --> 00:35:07.639
stuff like that rather than you know, manually scheduling code in most cases,

462
00:35:07.719 --> 00:35:14.039
I mean, you know, obviously
there are other different scenarios, but but

463
00:35:14.199 --> 00:35:19.039
that's for better for worse, what
I'm seeing. That's the reality, and

464
00:35:19.519 --> 00:35:22.599
more often than not, like a
long period. For example, when using

465
00:35:22.679 --> 00:35:28.079
React, the long task would be
the hydration and you know, a lot

466
00:35:28.119 --> 00:35:30.760
of a lot of developers aren't really
you know, sure what you know,

467
00:35:30.800 --> 00:35:35.920
what they can do about it anyway, So it's like leaving it up to

468
00:35:35.960 --> 00:35:39.039
the framework to resolve such issues.
Yeah, I think he's trying to get

469
00:35:39.079 --> 00:35:45.679
my sister off the phone when I
was a teenager. Yeah, I think

470
00:35:45.880 --> 00:35:50.599
some of those APIs. I think
some of the motivation is that they will

471
00:35:50.599 --> 00:35:53.480
be able to be used by frameworks. So I think some of the APIs

472
00:35:53.519 --> 00:35:59.199
around scheduling, particularly. I wasn't
involved in the design process of them at

473
00:35:59.199 --> 00:36:02.119
all, but it is thinking about
how can developers use this to break up

474
00:36:02.159 --> 00:36:07.079
their jobscip But it's also thinking about
how can framework authors use this to very

475
00:36:07.119 --> 00:36:13.800
easily introduce kind of batched or scheduling
or scheduled updates using what's built into the

476
00:36:14.079 --> 00:36:17.039
web platform and the browser, which
has a couple of benefits. Really,

477
00:36:17.079 --> 00:36:23.119
firstly, it should be more accurate
and bluntly better implemented. Unless you spend

478
00:36:23.159 --> 00:36:28.039
a lot of a lot of time
working on scheduled kind of updates, they

479
00:36:28.039 --> 00:36:30.480
can be very fiddly. And it
also means that those framework authors don't have

480
00:36:30.480 --> 00:36:35.079
to write code themselves to manage the
scheduling and batching, or at least they

481
00:36:35.119 --> 00:36:37.559
have to write less because they can
also lean on a kind of built in

482
00:36:37.639 --> 00:36:42.559
browser API. So some of the
work in these APIs is not necessarily aimed

483
00:36:42.599 --> 00:36:45.760
at developers building websites. It's saimed
at those building the abstractions that a lot

484
00:36:45.800 --> 00:36:52.480
of people are building on top of. So you mentioned what is probably the

485
00:36:52.480 --> 00:36:58.679
most colorful, colorful part of the
performance panel, which is the flame chart.

486
00:37:00.039 --> 00:37:04.920
So obviously it's kind of difficult to
explain without showing, but can you

487
00:37:05.159 --> 00:37:09.199
briefly describe what it is and how
it's how you read it as it were.

488
00:37:10.199 --> 00:37:14.119
Yeah, I'll give it a go. This really is a picture paints

489
00:37:14.119 --> 00:37:16.280
a thousand words, but I'll try
and say fewer than a thousand words.

490
00:37:17.239 --> 00:37:22.440
So the flame chart represents activity that
was happening in your page. We're talking

491
00:37:22.480 --> 00:37:27.760
here JavaScript that ran, and the
way to look at it is, you

492
00:37:27.800 --> 00:37:30.039
know, a rectangle on the flame
chart was a bit of code that ran

493
00:37:30.119 --> 00:37:34.719
for a certain period of time,
represented by how long or short or wide

494
00:37:34.719 --> 00:37:37.480
I should say the rectangle is what
people will also see is there's a level,

495
00:37:37.599 --> 00:37:39.920
there's nesting within the flame chart.
So when you look at it,

496
00:37:39.840 --> 00:37:44.920
it almost looks like a tree structure. So you can see that there are

497
00:37:44.920 --> 00:37:47.840
rectangles. Then below that rectangle there
will be a smaller rectangle, and then

498
00:37:47.840 --> 00:37:52.559
below that there could be many levels
of these sort of nestage rectangles. But

499
00:37:53.119 --> 00:37:55.880
if you look at the rectangle at
the top and then go down the flame

500
00:37:55.960 --> 00:38:00.719
chart, all the rectangles below the
first one will be smaller or contained within

501
00:38:00.880 --> 00:38:04.840
its parent. So you think of
this as a tree or a parent with

502
00:38:04.880 --> 00:38:07.039
a child, and that child might
have more children. And so what this

503
00:38:07.119 --> 00:38:09.159
lets you do is it lets you
look at the top row, which might

504
00:38:09.199 --> 00:38:13.079
say long task, and it might
say it was a second long. Then

505
00:38:13.159 --> 00:38:15.000
as you take that and you look
vertically down the flame chart, you're going

506
00:38:15.000 --> 00:38:20.039
to see all the functions and code
that ran within that long task that added

507
00:38:20.119 --> 00:38:22.719
up to make its total duration.
The reason this is so helpful is you

508
00:38:22.760 --> 00:38:25.679
might have a long task that's the
second long. If you look one level

509
00:38:25.679 --> 00:38:29.639
deeper in its children, you might
see that one of its children took point

510
00:38:29.800 --> 00:38:32.039
zero one of a second, so
that's really not useful. The other child

511
00:38:32.079 --> 00:38:37.079
took you know, zero point nine
nine of the second. And so what

512
00:38:37.079 --> 00:38:38.760
that lets you do is it lets
you see, okay, there was a

513
00:38:38.800 --> 00:38:43.400
long task, you could look down
to see the culprits or the causes of

514
00:38:43.440 --> 00:38:46.719
that long task, could really dive
in to the weeds of it. And

515
00:38:47.639 --> 00:38:54.000
just to add and potentially it helps
clarify. Think about the function A that

516
00:38:54.119 --> 00:39:00.119
calls function beat twice, so you'll
have a wider rag tangle four it A

517
00:39:00.840 --> 00:39:05.239
and contain with it. One level
down would be two rectangles for the you

518
00:39:05.280 --> 00:39:09.400
know, consecutive rectangles for the separate
calls to be. And in this in

519
00:39:09.440 --> 00:39:16.159
this context is useful to remember that
JavaScript is essentially a single threaded language.

520
00:39:16.199 --> 00:39:21.679
You know, we have workers,
but they are effectively run independently of each

521
00:39:21.679 --> 00:39:27.559
other, so it's always contained within
as it were, Yeah, correct,

522
00:39:27.639 --> 00:39:30.400
Yeah, And that you know,
long task can be caused by one or

523
00:39:30.400 --> 00:39:36.039
two things, broadly, either one
function that took an absolute age to run

524
00:39:36.440 --> 00:39:38.960
or one function that doesn't take very
long to run but got called you know,

525
00:39:39.000 --> 00:39:44.000
a million times, And so that
the flame show lets you figure out

526
00:39:44.000 --> 00:39:46.400
which one of those two it was. Obviously, the resolution or the way

527
00:39:46.400 --> 00:39:51.320
you fix that is different. You
know. Generally, it all boils down

528
00:39:51.320 --> 00:39:54.320
to can we do less work?
Can we run less less lines of code?

529
00:39:55.159 --> 00:39:59.440
But sometimes it can also be highlighting
where you might have a function that

530
00:39:59.480 --> 00:40:02.159
you think you don't need to optimize
because it it isn't very complicated, But

531
00:40:02.199 --> 00:40:06.440
if it's been called loads and loads
of times, then it may well need

532
00:40:06.480 --> 00:40:09.679
to be have a bit more attention
given to it. Now it's called a

533
00:40:09.679 --> 00:40:13.880
flame chart, I guess because of
the shape. But it's also called a

534
00:40:13.920 --> 00:40:17.760
flame chart I think because of the
colors, which are often yellow, red,

535
00:40:17.920 --> 00:40:22.719
purplation, et cetera. Ye,
that color coding. How does it

536
00:40:22.840 --> 00:40:28.400
work? What's kind of the logic
behind which color which each direct angle gets?

537
00:40:28.960 --> 00:40:31.880
Dan, you're really pushing my memory
of all these details. That's what

538
00:40:31.880 --> 00:40:37.719
I'm here for. So yeah,
yellow, if I rightly, is scripting,

539
00:40:38.079 --> 00:40:44.159
and most of the time the ones
that particularly interesting is purple. Is

540
00:40:44.639 --> 00:40:49.960
like browser layout type events. This
might be recalculate styles event, which is

541
00:40:49.960 --> 00:40:52.079
where something happened which made the browser
have to a bunch of work to check

542
00:40:52.480 --> 00:40:57.760
that it's latest layout of the page
is accurate. The kind of the most

543
00:40:57.760 --> 00:41:01.639
common got you with those is if
you call method like get bounding client wrecked

544
00:41:01.840 --> 00:41:07.639
on an element or if you read
an element's Paul Irish has got a great

545
00:41:07.119 --> 00:41:09.800
get hub page with all the different
ways you can trigger this, but there's

546
00:41:10.000 --> 00:41:14.960
if you read an elements with or
height or scroll top and various things.

547
00:41:15.440 --> 00:41:17.320
The browser before it gives you that
value back has to make sure that what

548
00:41:17.440 --> 00:41:21.039
it thinks the layout is is what
the layout is, so it will do

549
00:41:21.119 --> 00:41:23.440
some extra work to kind of verify
that. And so what you want to

550
00:41:23.480 --> 00:41:27.760
do is minimize how often that happens, because that can be quite expensive on

551
00:41:27.760 --> 00:41:32.800
a complicated page. So that's purple. I'd like to tell a short story

552
00:41:32.840 --> 00:41:38.320
about that. So a while back, a friend of mine contacted me about

553
00:41:38.320 --> 00:41:43.039
the problem that they were having within
the application. It happened to be within

554
00:41:43.159 --> 00:41:46.519
Angular, but it's neither here or
there in that regard, which was taking

555
00:41:46.800 --> 00:41:53.000
a very long time to render it
in its primary view. And when I

556
00:41:53.079 --> 00:41:58.199
talked to them and we looked at
at the flame chart, it became very

557
00:41:58.239 --> 00:42:02.920
pretty obvious that it was laying out
a whole lot of time. Effectively,

558
00:42:04.280 --> 00:42:10.800
it had layout thrashing. And because
the way that this application, the UI

559
00:42:12.000 --> 00:42:15.480
was structured, it was structured as
a lot of rectangles, and they built

560
00:42:15.480 --> 00:42:22.480
those rectangles in a way that certain
amount of texts and images needed to fit

561
00:42:22.639 --> 00:42:30.280
nicely within them. And now instead
of using CSS to kind of properly factor

562
00:42:30.360 --> 00:42:35.760
those sizes, they actually used Java
initially used JavaScript for it. So they

563
00:42:35.800 --> 00:42:39.559
would, you know, put the
content in a rectangle, get the dimensions

564
00:42:39.559 --> 00:42:43.360
for the rectangle, fixed the content, and then do it for the next

565
00:42:43.360 --> 00:42:47.360
rectangle, then do it for the
next rectangle. So effectively, each rectangle

566
00:42:49.239 --> 00:42:58.000
required a relayout, so they were
changing some position and with aspects and then

567
00:42:58.119 --> 00:43:05.400
querying the and high aspects. So
for every rectangle, relayout, and there

568
00:43:05.400 --> 00:43:09.239
were hundreds of such rectangles on the
page. And that's what's known as layout

569
00:43:09.280 --> 00:43:15.639
thrashing, which you're when you're forcing
the browser to relayout multiple times in or

570
00:43:15.679 --> 00:43:21.960
to just to render that initial one
view. And basically what I told them

571
00:43:22.519 --> 00:43:28.480
is one of two things that the
less ideal solution would be to put to

572
00:43:28.599 --> 00:43:35.559
have instead of one loop doing putting
in the content, then getting the layout

573
00:43:35.639 --> 00:43:39.320
information, putting in more content getting
layout information, do it is two separate

574
00:43:39.360 --> 00:43:44.280
loops, like you know, even
three loops, do all the positioning,

575
00:43:44.400 --> 00:43:47.920
get all the layouts, and then
do all the fixes. And that actually

576
00:43:49.000 --> 00:43:53.679
turns out to be faster, even
though it's potentially counterintuitive because the browser can

577
00:43:53.760 --> 00:44:00.000
do the just the one layout instead
of the layouts rushing, I just discret

578
00:44:00.760 --> 00:44:04.599
or even better, just do it
in CSS. Let the CSS do it

579
00:44:04.639 --> 00:44:07.159
for you, and then you don't
need to do all those layout in at

580
00:44:07.199 --> 00:44:13.519
all. And that's what they ended
up doing, and they and it became

581
00:44:13.639 --> 00:44:20.199
from like a thirty second load to
being literally like a second, So it

582
00:44:20.800 --> 00:44:23.960
was like a huge win in terms
of performance. And that's definitely something that

583
00:44:24.039 --> 00:44:29.400
you can see in dev tools,
and I think these times now you can

584
00:44:29.440 --> 00:44:36.920
even see it better because I think
you even provide some attribution to the relayouts

585
00:44:36.960 --> 00:44:42.159
that occur. Yeah, we can't
detect every single instance, but if we

586
00:44:42.239 --> 00:44:45.760
can, we will draw arrows in
the flame chart which will take you from

587
00:44:46.039 --> 00:44:51.639
one event that caused another event,
so we can often attribute why a layout

588
00:44:51.719 --> 00:44:54.440
happened. Or simply say your Rome
code that has a set time out in

589
00:44:54.840 --> 00:44:58.519
when the function within the set time
out gets cooled and you find that on

590
00:44:58.559 --> 00:45:01.000
the flame shot will draw an arrow
back to the code that ran the set

591
00:45:01.039 --> 00:45:04.960
time out, so you can see
kind of why things happen. I think

592
00:45:05.000 --> 00:45:07.719
there's a lot more we could do
there, but yeah, we do try

593
00:45:07.760 --> 00:45:13.079
and draw the arrows to give you
some some idea if you can. Yeah,

594
00:45:13.079 --> 00:45:15.400
A big theme when you look at
the main flame chart and you see

595
00:45:15.440 --> 00:45:19.559
lots of stuff going on, is
is to ask firstly, you know,

596
00:45:19.559 --> 00:45:22.119
I've talked about can you spot functions
that you can optimize or reduce how long

597
00:45:22.159 --> 00:45:24.519
they take to run? But it's
also do you even need to run that

598
00:45:24.559 --> 00:45:27.960
code of tool? I think there
are plenty of cases like the one you

599
00:45:28.039 --> 00:45:34.440
just described where actually, especially now
if you're targeting modern browsers, CSS has

600
00:45:34.440 --> 00:45:37.519
got a lot more powerful, particularly
around layout, and I think there are

601
00:45:37.519 --> 00:45:39.360
a lot of cases where you can
actually get rid of jibscript to lean on

602
00:45:40.000 --> 00:45:44.239
lean on CSS a bunch more.
If you can optimize a function, great,

603
00:45:44.239 --> 00:45:46.519
If you don't ever need to run
it, that's even better. I'm

604
00:45:46.599 --> 00:45:51.159
kind of curious as people come into
this and they start, you know,

605
00:45:51.159 --> 00:45:54.320
because we've kind of talked about some
of the specific things that are in the

606
00:45:54.360 --> 00:45:58.760
performance tools. But I'm kind of
thinking through my head, Okay, what's

607
00:45:58.760 --> 00:46:02.400
the scenario right where somebody's gonna you
know, and maybe people are regularly checking

608
00:46:02.440 --> 00:46:07.639
this as they build their apps,
but I'm also thinking, you know,

609
00:46:07.719 --> 00:46:13.000
maybe somebody is looking at things and
realizes that they have poor scoring on some

610
00:46:13.079 --> 00:46:17.039
of their core web vitles. Right, So what what scenarios are you looking

611
00:46:17.039 --> 00:46:20.519
at? Is it one of those? Is it something else where you're finding

612
00:46:20.519 --> 00:46:24.039
that people are typically reaching for this
particular panel and the Chrome dev tools,

613
00:46:24.400 --> 00:46:29.800
and then what how do you how
do you pull the information out and know

614
00:46:29.840 --> 00:46:31.440
what to do with it? Because
it's it's one thing to say, Okay,

615
00:46:31.440 --> 00:46:34.639
all this information is in there,
and I think we've covered a lot

616
00:46:34.679 --> 00:46:38.199
of that, but you know,
okay, I've got this information. Now

617
00:46:38.320 --> 00:46:42.000
how do I know that it yeah, it's layout thrashing, or how do

618
00:46:42.079 --> 00:46:45.760
I know that it's you know,
something else, or you know, maybe

619
00:46:45.760 --> 00:46:49.280
it's something really simple and it's just
you know, I I load in an

620
00:46:49.280 --> 00:46:52.920
image and my whole paid shifts and
it takes a long time for it to

621
00:46:52.920 --> 00:46:55.119
grab it and pull it out.
So you know it's it's uh, you

622
00:46:55.199 --> 00:47:00.679
know it's impacting two or three scores. Yes. I think most common use

623
00:47:00.719 --> 00:47:07.199
case is people who run their website
through a Lighthouse report and see that something

624
00:47:07.280 --> 00:47:10.920
is scoring badly, or it will
be people who are getting reports from their

625
00:47:12.039 --> 00:47:16.119
users that their website is loading slowly. That was often the motivation of my

626
00:47:16.320 --> 00:47:21.239
previous job was it would normally be
a member of staff was on a really

627
00:47:21.280 --> 00:47:24.840
rubbish connection and would moan that there's
the site loaded very poorly. So I

628
00:47:24.880 --> 00:47:29.599
think that's mostly how we expect people
to come into the tool is some issue

629
00:47:29.800 --> 00:47:32.079
and obviously core where vitals can impact
search rankings. That tends to be the

630
00:47:32.079 --> 00:47:37.119
motivating factor for the majority of businesses
who want to invest in this area.

631
00:47:37.960 --> 00:47:43.679
Yeah, in terms of understanding the
information, that's really what the experimental Performance

632
00:47:43.719 --> 00:47:46.320
Insights panel that was one of the
goals of that. So when you use

633
00:47:46.360 --> 00:47:50.440
that panel, you get a right
hand sidebar that shows I think we call

634
00:47:50.519 --> 00:47:54.800
them insights, and it will highlight
things that were particularly problematic. Now,

635
00:47:55.039 --> 00:48:00.000
we didn't do a good job of
prioritizing those and helping people understand which one

636
00:48:00.079 --> 00:48:01.800
the most important, and that's something
we need to improve as we kind of

637
00:48:01.800 --> 00:48:07.360
bring that functionality into the performance panel. But it would highlight problems. So,

638
00:48:07.440 --> 00:48:09.840
for example, a network request that
is render blocking, as in until

639
00:48:09.840 --> 00:48:14.440
the browser is finished with that request, it can't continue laying out the page.

640
00:48:14.800 --> 00:48:16.199
We would highlight that as an issue
because if you can resolve that,

641
00:48:16.239 --> 00:48:21.800
the browser can can get rendering earlier
and therefore your page will appear loaded to

642
00:48:21.800 --> 00:48:25.119
the user much more quickly. I
think really a theme for us this year

643
00:48:25.199 --> 00:48:30.760
is trying to have actionable kind of
insights that we can provide people to give

644
00:48:30.800 --> 00:48:36.480
them a helping hand to figure out
what was going on. I think a

645
00:48:36.559 --> 00:48:45.960
key aspect and probably the biggest challenge
around improving performance is attribution, understanding the

646
00:48:45.079 --> 00:48:51.800
root cause for why something behaves the
way that it does. Like, Okay,

647
00:48:51.880 --> 00:48:57.880
this page is loading, or this
block, you know, the like

648
00:48:57.960 --> 00:49:04.039
the page is unresponsive. Why is
it unresponsible? What's actually running that's causing

649
00:49:04.079 --> 00:49:08.199
it to be unresponsive? What what
is the browser that's why? Yeah,

650
00:49:08.320 --> 00:49:15.119
exactly, And and I think and
and it's a it's a it's a it's

651
00:49:15.119 --> 00:49:19.840
a it's a challenge. It's it's
not easy to figure out the attribution.

652
00:49:20.159 --> 00:49:24.039
And you know, I'm I'm on
the web perform at the W three C

653
00:49:24.199 --> 00:49:29.599
Web Performance Working Group, and and
a lot of the discussions are about how

654
00:49:29.639 --> 00:49:35.920
to try to figure out like the
reasons the browser does what it does and

655
00:49:35.960 --> 00:49:39.400
then externalize this information and also how
to do it in a way that in

656
00:49:39.480 --> 00:49:46.719
itself is performance and also doesn't you
know, become a security or a privacy

657
00:49:46.800 --> 00:49:52.760
issue. So there's a lot of
problems around that, but part of it

658
00:49:52.840 --> 00:50:00.199
is that the browser is a sophisticated
system and and consequently understanding attribution is not

659
00:50:00.239 --> 00:50:05.719
a trivial problem. You need to
have a certain amount of understanding of how

660
00:50:05.760 --> 00:50:10.719
this thing works so you can make
it just so simple, but probably not

661
00:50:10.880 --> 00:50:17.719
simpler now as you might expect.
I'm also I also have the performance panel

662
00:50:17.800 --> 00:50:22.719
open well while we're talking, and
I just noticed something that I've never seen

663
00:50:22.760 --> 00:50:28.559
before. So I'm going to take
the opportunity and ask you jack about it

664
00:50:28.639 --> 00:50:34.159
now. I noticed that when I'm
floating over the various the strips or the

665
00:50:34.199 --> 00:50:38.000
tracks as you call them, they
now show like this, like a pencil

666
00:50:38.360 --> 00:50:43.920
at the left side that I can
click on, and then I get this

667
00:50:44.000 --> 00:50:49.280
weird view with eyes and check marks. What is that? Yeah? So

668
00:50:49.719 --> 00:50:52.320
this you I will change in the
next release of Chrome, which must be

669
00:50:52.360 --> 00:50:59.440
out very soon. But this was
or is a UI to enable people to

670
00:51:00.360 --> 00:51:06.480
reorder and hide and show particular tracks. So can you record a performance trace

671
00:51:06.519 --> 00:51:08.159
that you get a bunch of these
tracks, and obviously that some of them

672
00:51:08.159 --> 00:51:12.519
are really like network is obviously an
important one. The main thread activity is

673
00:51:12.519 --> 00:51:16.119
important, but you will get others, for say, GPU activity, rasterization,

674
00:51:16.559 --> 00:51:21.000
any workers that were on the page, and so on and so forth.

675
00:51:21.079 --> 00:51:22.400
Depending on your use case, those
may or may not be useful to

676
00:51:22.440 --> 00:51:25.920
you. And when the challenges of
the performance panel is embedded within dev tools,

677
00:51:25.920 --> 00:51:30.039
which not most people. Most people
don't have Devdel's open full screen because

678
00:51:30.039 --> 00:51:32.199
it's within Chrome, so vertical space
is tends to be at a bit of

679
00:51:32.199 --> 00:51:36.760
a premium for us. So this
is kind of we've been playing around with

680
00:51:36.800 --> 00:51:42.519
how can we enable people to hide
and show information? But yeah, we're

681
00:51:42.559 --> 00:51:45.480
not I'm not thrilled with the UI
that landed. Will change. It was

682
00:51:45.559 --> 00:51:47.400
kind of a first part of it, and we've tweaked a bunch of stuff

683
00:51:49.119 --> 00:51:52.039
for Chrome one two six which should
be out soon. So for example,

684
00:51:52.679 --> 00:51:59.519
so for example, if you know, there's the animations track, so you're

685
00:51:59.599 --> 00:52:02.119
yeh say saying if they don't actually
have animations on the page, or I'm

686
00:52:02.119 --> 00:52:07.000
not currently testing the performance of animations, maybe I'd like to hide it just

687
00:52:07.079 --> 00:52:13.239
to save some vertical space. Yeah, yeah, I think what we need

688
00:52:13.280 --> 00:52:17.960
to do is is potentially could we
do some of that automatically for you because

689
00:52:17.960 --> 00:52:22.199
also right now, I think if
you wanted to hide all the non important

690
00:52:22.199 --> 00:52:24.280
tracks you might have to click ten
or fifteen of them to get rid of.

691
00:52:24.800 --> 00:52:27.920
So I wonder there might be a
world that we can invert that and

692
00:52:27.960 --> 00:52:30.639
you can tell us the ones you
want to keep around. I don't quite

693
00:52:30.719 --> 00:52:32.880
know, but yeah, what you're
seeing is are sort of first steps into

694
00:52:32.920 --> 00:52:38.119
the water of allowing I think users
to customize the timeline they see better to

695
00:52:38.159 --> 00:52:42.719
suit their particular use case. Because
depending on the context that you're what the

696
00:52:42.760 --> 00:52:45.639
problem is you're trying to debug,
there are certain things you may or may

697
00:52:45.679 --> 00:52:49.800
not care about, and we can't
always know that for sure. That we're

698
00:52:49.840 --> 00:52:52.800
trying to get better at figuring out
what you're trying to debug and show you

699
00:52:52.840 --> 00:52:58.280
the right level of information. But
kind of going back to what we're doing

700
00:52:58.320 --> 00:53:01.280
about around attribution, Yeah, that
is the challenge and what we're trying to

701
00:53:01.280 --> 00:53:05.840
figure out is there are sometimes where
we can very confidently attribute a particular issue

702
00:53:05.840 --> 00:53:07.960
to a particular root cause. So, for example, layout shifts. A

703
00:53:08.119 --> 00:53:12.599
very common root cause of that is
we load an image into the page,

704
00:53:12.840 --> 00:53:15.079
but the developer didn't set the width
and height explicitly on the image. The

705
00:53:15.079 --> 00:53:20.079
browser kind of guesses or reserves a
certain amount of size. Then when the

706
00:53:20.119 --> 00:53:22.559
image loads in, it now knows
the correct size for the image and it

707
00:53:22.599 --> 00:53:25.079
resizes it down, which can cause
the pace to shift. So we can

708
00:53:25.440 --> 00:53:30.039
quite often very easily point to that, but other ones we're sometimes sort of

709
00:53:30.039 --> 00:53:32.800
guessing. We're trying to figure out
how we can say to users, this

710
00:53:32.960 --> 00:53:36.639
might be a problem that you should
look at, but it also might not,

711
00:53:36.760 --> 00:53:39.000
because we can't be one hundred percent
short, and that's a tougher kind

712
00:53:39.000 --> 00:53:44.920
of story to tell and guide people
on. Now will we still have a

713
00:53:44.920 --> 00:53:49.519
bit of time left, So we
were talking about the top part, which

714
00:53:49.599 --> 00:53:52.880
is the mini map. We were
talking about the central part, which actually

715
00:53:52.880 --> 00:53:58.559
contains the flame chart. There's also
a bottom part which has the summary bottom

716
00:53:58.639 --> 00:54:04.719
up poultry and event. Can you
briefly describe what that section is? Yeah,

717
00:54:04.760 --> 00:54:07.480
I'll try so that the summary trust
to show. It will show you

718
00:54:07.480 --> 00:54:09.840
one of two things, depending on
what you've selected. If you've selected a

719
00:54:09.920 --> 00:54:14.719
time range in the panel, it
will show some stats about how much of

720
00:54:14.760 --> 00:54:19.079
that time range is spent in various
activities, how much was spent like the

721
00:54:19.079 --> 00:54:22.960
browser paints or rendering versus scripting effect
for your JavaScript or not. If you

722
00:54:23.000 --> 00:54:27.760
select an actual individual event, say
a network request, it will show you

723
00:54:27.760 --> 00:54:31.840
some extra information about the particular event
you've selected. Then the next three bottom

724
00:54:31.920 --> 00:54:36.119
up, culture and event log.
They're all based on trying to get a

725
00:54:36.119 --> 00:54:40.679
better understanding of the JavaScript and the
flame chart. So bottom up the idea

726
00:54:40.760 --> 00:54:45.440
there is you get a view of
all these sort of events in the flame

727
00:54:45.559 --> 00:54:47.480
chart. You can filter them by
name, and you can also sort them

728
00:54:47.519 --> 00:54:52.039
by how long they took and the
duration that they took. The idea there

729
00:54:52.079 --> 00:54:57.079
being that it can sometimes be an
easier way to dig into where your pagevent

730
00:54:57.159 --> 00:55:04.000
most of its time executing. Tree
and event log are similar. Event log

731
00:55:04.119 --> 00:55:08.519
I never use and I don't remember. I think col tree is very similar

732
00:55:08.519 --> 00:55:13.920
to bottom up. Whereas bottom up
starts literally from the bottom and goes upwards,

733
00:55:13.920 --> 00:55:15.679
the bottom up starts with the sort
of leaf nodes of the tree.

734
00:55:15.679 --> 00:55:19.519
If you think of the flame chart, it starts with the things at the

735
00:55:19.519 --> 00:55:22.239
bottom that at the most time,
I think col tree might go the other

736
00:55:22.280 --> 00:55:28.840
way, but yes, I'd have
to double check yes it does. The

737
00:55:29.360 --> 00:55:34.480
main benefit of using these is that
they because you know, you might say,

738
00:55:34.599 --> 00:55:37.679
why do I need this information?
It's kind of a duplication of the

739
00:55:37.679 --> 00:55:42.920
information that they have in the flame
chart itself. The main benefit aside from

740
00:55:42.920 --> 00:55:46.960
filtering, which you mentioned, is
the fact that it's also it also aggregates

741
00:55:47.559 --> 00:55:52.559
because you know the example I gave
before where function A calls function B twice.

742
00:55:52.880 --> 00:55:58.920
So in the flame chart you see
each instant of the execution of function

743
00:55:59.039 --> 00:56:05.039
B separately, but in the bottom
up view, it starts from B and

744
00:56:05.079 --> 00:56:10.039
it aggregates all the time spent inside
of B. So, like you mentioned

745
00:56:10.840 --> 00:56:19.400
that a certain function may have a
significant impact on the execution on the loading

746
00:56:19.480 --> 00:56:22.960
time of a page. Might be
because that function ran once but ran for

747
00:56:22.000 --> 00:56:27.760
a very long time, or maybe
it ran really quickly but was involved a

748
00:56:27.800 --> 00:56:32.119
million times. So and the aggregated
view, in the case of that function

749
00:56:32.199 --> 00:56:37.800
being involved a million times, will
show the total amount of time that was

750
00:56:37.920 --> 00:56:45.280
spent inside that function in all those
individual invocations. Yes, yeah, that's

751
00:56:45.320 --> 00:56:49.679
a good additional point. I was
looking at this too, because it also

752
00:56:49.760 --> 00:56:53.079
shows I opened it up and just
ran it on stream yard, which is

753
00:56:53.079 --> 00:56:58.000
what we're using to record this.
And it also showed like the garbage collection

754
00:56:58.719 --> 00:57:02.079
and you know, some of the
other system calls as well as well as

755
00:57:02.159 --> 00:57:07.400
like paint and animation, frame fired
and things like that. And so if

756
00:57:07.480 --> 00:57:09.199
yeah, it really does give you
a drill down right, if you're if

757
00:57:09.199 --> 00:57:15.440
you're doing something that is heavily memory
intensive and it's going to trigger garbage collection

758
00:57:15.519 --> 00:57:19.039
on a regular basis, and you
know, maybe that's gonna, you know,

759
00:57:19.679 --> 00:57:22.760
affect your performance one way or another, right, because I mean,

760
00:57:22.239 --> 00:57:25.159
you know, I would assume that
most apps maybe don't have that problem,

761
00:57:25.480 --> 00:57:30.199
but I've seen people do some weird
stuff on the way. Yeah, so

762
00:57:30.320 --> 00:57:34.400
we actually hit that give you all
kinds of information. Yeah, we So

763
00:57:34.559 --> 00:57:37.679
because dev tools is a web app, we can debug dev tools using dev

764
00:57:37.760 --> 00:57:43.039
tools, which means we can profile
the performance panel's performance by using the performance

765
00:57:43.079 --> 00:57:46.400
panel in and other dev tools,
so profile inception. It gets a little

766
00:57:46.440 --> 00:57:51.639
bit confusing, but we the performance
panel. So the main sort of UI

767
00:57:51.719 --> 00:57:55.280
all these tracks is drawn via an
HML canvas, and so that means every

768
00:57:55.320 --> 00:57:59.159
time they use the scrolls or pans
or zooms in or out, we have

769
00:57:59.199 --> 00:58:01.960
to redraw the whole or canvas to
represent what they've just done. And so

770
00:58:02.559 --> 00:58:07.280
that is a lot of a lot
of function calls happening in a very short

771
00:58:07.280 --> 00:58:09.679
space of time to lay that all
out. And we had a situation where

772
00:58:09.679 --> 00:58:14.840
we were passing to function that got
called i think for every single event on

773
00:58:14.880 --> 00:58:19.320
the timeline, so potentially hundreds of
thousands of times, if not more.

774
00:58:20.400 --> 00:58:22.599
We called the function with an object, you know, so we could destructure

775
00:58:22.639 --> 00:58:29.159
the arguments from that object. Now, every time you do that, that

776
00:58:29.239 --> 00:58:31.320
object that you pass in has to
be garbage collected at the end of that

777
00:58:31.360 --> 00:58:36.159
functions life cycle for ninety nine percent
of the time. Ninety nine percent.

778
00:58:36.280 --> 00:58:38.599
Developers probably that's never a problem at
all, it's not a concern. But

779
00:58:38.639 --> 00:58:42.960
when you call that function a million
times in sort of a split second,

780
00:58:43.320 --> 00:58:45.480
that suddenly a million objects and now
had to be garbage collected. And so

781
00:58:45.519 --> 00:58:49.719
what we had to do was change
that function. So rather than taking an

782
00:58:49.719 --> 00:58:52.519
object with say five different keys and
values, we have to pass each of

783
00:58:52.519 --> 00:58:57.800
those individuals as an argument to the
function. So it sacrifices in that case

784
00:58:57.840 --> 00:59:01.360
a small amount of readability, but
it it massively improve the performance and the

785
00:59:02.360 --> 00:59:07.119
when you're talking about redrawing a canvas, as the user resuming or scrolling,

786
00:59:07.000 --> 00:59:12.039
you notice any slowdown in performance.
So that's kind of we have to be

787
00:59:12.119 --> 00:59:15.800
very hot on that sort of thing. There's another lesson here, and that

788
00:59:15.920 --> 00:59:22.719
lesson is that the Performance Panel is
an amazing profiling tool, and you should

789
00:59:22.800 --> 00:59:31.119
never start to optimize stuff, especially
micro optimizations, before you profile and identify

790
00:59:31.280 --> 00:59:37.239
the problem areas, because you know, like you said, like Jack just

791
00:59:37.280 --> 00:59:40.519
said, like you said, Jack, you sacrifice a little bit of readability.

792
00:59:42.119 --> 00:59:47.880
Well, you shouldn't sacrifice readability unless
it makes a measurable positive impact.

793
00:59:49.480 --> 00:59:52.719
You were able to prove that it
does and that it's worth that small amount

794
00:59:52.800 --> 01:00:04.119
of readability sacrifice in that particular case. And so yeah, that's support that's

795
01:00:04.199 --> 01:00:09.039
really important to make in that context. By the way, another important point

796
01:00:09.079 --> 01:00:15.159
to make that's kind of related to
what you said before that Chuck about whether

797
01:00:15.239 --> 01:00:20.360
or not that kind of activity is
a problem in most web applications. You

798
01:00:20.400 --> 01:00:25.880
can also use all these tools,
including the Performance Panel, to profile node

799
01:00:25.960 --> 01:00:32.360
based applications. You can attached to
note and profile node and node. Let's

800
01:00:32.360 --> 01:00:37.719
say you've got a note service that's
long running for example. Let's say it's

801
01:00:37.760 --> 01:00:42.280
not some sort of lambdau or something. It's it's an actual long running node

802
01:00:42.360 --> 01:00:52.199
process that's serving a ton of users. It can definitely have issues around memory

803
01:00:52.199 --> 01:00:58.599
allocations and stuff like that, so
it's not just extreme client side situations like

804
01:00:58.760 --> 01:01:02.960
the dep tools itself. You know
your average node service that happens to be

805
01:01:04.159 --> 01:01:10.599
servicing you know, ten thousand users. Ye makes sense. I actually used

806
01:01:10.599 --> 01:01:19.079
it specifically a couple of months ago. I made a contribution to the Prometheus

807
01:01:19.199 --> 01:01:24.559
client for Node around just that identifying
a problem like it's kind of similar to

808
01:01:24.639 --> 01:01:30.440
what you described Jack of allocating a
lot of objects and identifying that it could

809
01:01:30.519 --> 01:01:37.159
be done more efficiently. In that
particular case, they were building a huge

810
01:01:37.480 --> 01:01:44.320
string by concatenating strings into it,
which in most cases is fine, but

811
01:01:44.440 --> 01:01:50.239
in that case it was literally millions
of strings. So using a joint instead

812
01:01:50.880 --> 01:01:59.079
turned out to be significantly more performant
in that particular example. Yeah, we've

813
01:01:59.119 --> 01:02:02.199
had loads of insiness. There's a
blog post on the Developer Tools blogs we

814
01:02:02.239 --> 01:02:06.800
recently. We recently did a big
under a rewrite of sort some of the

815
01:02:06.800 --> 01:02:09.719
internals of the performance panel. Then
we were profiling it, and I think

816
01:02:09.760 --> 01:02:14.320
there was We have some test kind
of traces that we can load into the

817
01:02:14.320 --> 01:02:17.280
performance panel that are absolutely massive,
like far bigger than anyone's average website would

818
01:02:17.320 --> 01:02:20.679
generate. And for one of those, I think we were able to get

819
01:02:20.719 --> 01:02:24.000
the time the performance panel took to
process and load that trace I think down

820
01:02:24.039 --> 01:02:30.119
from something like twelve seconds to two
seconds just by recording with the performance panel

821
01:02:30.159 --> 01:02:34.880
and then going through and looking for
these problem areas. But you know,

822
01:02:34.920 --> 01:02:38.760
we couldn't have done that optimization without
looking at the performance panel because obviously we'd

823
01:02:38.760 --> 01:02:42.599
written all the code that caused it
to be slow, and in none of

824
01:02:42.800 --> 01:02:45.079
you wouldn't look at any of those
changes and think, oh, that's going

825
01:02:45.159 --> 01:02:47.239
to be a problem here. That
is going to be slow for us.

826
01:02:49.039 --> 01:02:51.480
Sometimes you can, but most of
the time you do need to wait and

827
01:02:51.519 --> 01:02:59.280
actually profile it. You know,
around it's always wrong. It's always wrong.

828
01:02:59.559 --> 01:03:02.760
Yeah, And that passing objects into
functions and rewriting those as arguments.

829
01:03:04.440 --> 01:03:07.320
We don't follow that everywhere in the
panel because it's only a problem in the

830
01:03:07.320 --> 01:03:10.599
code that redraws the canvas, because
that is our real hot path needs to

831
01:03:10.639 --> 01:03:15.519
be as optimized as we can,
and we may have to sacrifice readability in

832
01:03:15.599 --> 01:03:17.840
order to do that. But in
say the summary bit at the bottom that

833
01:03:17.880 --> 01:03:22.800
shows you information that doesn't rerender every
time of the user scrolls, So in

834
01:03:22.800 --> 01:03:25.440
that panel, for in that part
of the code, we probably would still

835
01:03:25.480 --> 01:03:29.239
pass an object in because we know
that that's not going to be a path

836
01:03:29.280 --> 01:03:32.840
that's going to cause us problems.
So yeah, the advice to always profile

837
01:03:32.880 --> 01:03:37.719
and not prematurely optimizes is very accurate
because it will always surprise you. And

838
01:03:37.800 --> 01:03:42.320
browsers are smart. Sometimes they can
optimize things that you might think would be

839
01:03:42.400 --> 01:03:45.199
slow because they recognize what you're doing. Sometimes something that intuitively you think won't

840
01:03:45.239 --> 01:03:49.800
be slow will be slow for some
very niche reason. So yeah, it's

841
01:03:49.880 --> 01:03:52.679
very important and to use the tools
available to figure that out before you go

842
01:03:52.880 --> 01:04:01.400
diving in. So we're kind of
at the end of our time. Are

843
01:04:01.400 --> 01:04:05.760
there places where people can go and
dive deeper into this stuff? Uh?

844
01:04:05.880 --> 01:04:11.039
Yeah, so, I mean the
performance panel is very heavily documented in the

845
01:04:11.079 --> 01:04:15.199
devtol's documentation online. In terms of
what we're sort of planning, there's some

846
01:04:15.320 --> 01:04:19.079
blog posts on the Chrome for Developers
blog that have more information on this,

847
01:04:19.519 --> 01:04:23.880
which I can kind of send links
to all the things that I think are

848
01:04:24.039 --> 01:04:29.280
useful. That's probably the best place
to start in terms of sort of keeping

849
01:04:29.320 --> 01:04:31.280
up to date with what's new in
dev tools. I think following the Chrome

850
01:04:31.760 --> 01:04:36.159
develop a YouTube account or Twitter and
all that stuff is probably best. At

851
01:04:36.199 --> 01:04:43.039
the Jesslyn, who's the Devtel's DevRel
does. Yeah, she's amazing. She

852
01:04:43.039 --> 01:04:45.800
does regular videos and will highlight new
features across the panel, including in any

853
01:04:45.840 --> 01:04:49.599
of the performance tooling. So that's
by the way. The What's News section,

854
01:04:50.360 --> 01:04:57.039
which is inside dev toels itself,
it's in the drawer part, actually

855
01:04:57.199 --> 01:05:02.360
contains the video showing what's new for
the latest version, and from there you

856
01:05:02.400 --> 01:05:06.599
can get to the what's new for
previous versions as well, So it's you

857
01:05:06.639 --> 01:05:12.519
can it's really worthwhile to review these
videos. They're short, they're sweet,

858
01:05:12.679 --> 01:05:19.360
they're very informative. Highly recommended.
Awesome, agreed. There is one thing

859
01:05:19.480 --> 01:05:24.000
before we let you go, before
we finish this episode. There's one request

860
01:05:24.360 --> 01:05:30.960
which I think I submitted like years
ago via your feature request mechanism, and

861
01:05:31.039 --> 01:05:39.440
that's the ability. So what you
can already inside the performance panel record have

862
01:05:39.599 --> 01:05:46.480
multiple recordings and like flip between them. What I'm really missing is the ability

863
01:05:46.559 --> 01:05:53.559
to compare recordings. So for example, if I made a change and I

864
01:05:53.599 --> 01:05:58.760
think it impacts and it seems to
impacted performance, I would love to have

865
01:05:58.920 --> 01:06:05.000
like subtract one view from the other
and only see the differences. That would

866
01:06:05.079 --> 01:06:11.639
be awesome. Yeah, you're not
the first person to bench that and that's

867
01:06:11.679 --> 01:06:18.159
certainly floating around the backlog. I
think it's something we It's hard because if

868
01:06:18.199 --> 01:06:21.400
you record to you know, if
you have the same website and you recorded

869
01:06:21.400 --> 01:06:27.840
too traces without changing anything due to
the variability of the Internet and computers and

870
01:06:27.840 --> 01:06:30.119
whatever else your computer was doing at
the time, those traces are going to

871
01:06:30.119 --> 01:06:33.719
be slightly different. So I think
the challenge there is figuring out how do

872
01:06:33.760 --> 01:06:40.239
we represent what changed and try to
figure out what changed just because variability and

873
01:06:40.239 --> 01:06:45.519
what changed because you did something.
So I think we can see the appeal

874
01:06:45.639 --> 01:06:49.639
and the reason it would be very
useful. The practical the practicalities of implenting

875
01:06:49.639 --> 01:06:55.760
it is potentially slightly challenging, along
with how we manage the real estate on

876
01:06:55.840 --> 01:07:00.000
the screen if you want to compare
these two traces and the panels already crammed

877
01:07:00.119 --> 01:07:02.519
full of stuff as it is.
But yeah, it's floating around as an

878
01:07:02.559 --> 01:07:05.360
idea we want to explore. For
sure. If it were easy, then

879
01:07:05.440 --> 01:07:14.480
everybody would be doing it. I
will mention that the awesome webpage test now

880
01:07:14.679 --> 01:07:20.360
has an interesting ability to compare two
recordings, which is which is also not

881
01:07:20.519 --> 01:07:26.679
perfect, but it is pretty good. I was just going to say,

882
01:07:26.719 --> 01:07:30.480
if you estimate it in your estimation
meetings as a medium, and then you

883
01:07:30.559 --> 01:07:32.000
come back after you start working at
it and go, actually, this is

884
01:07:32.039 --> 01:07:39.400
an extra large I didn't realize.
Then maybe we'll get it sooner. In

885
01:07:39.440 --> 01:07:45.199
other words, lie, I'll give
it a guy. Yeah, all right,

886
01:07:45.239 --> 01:07:47.320
Well, let's go ahead and do
some picks and wrap this up.

887
01:07:49.239 --> 01:07:53.719
Now, let's get the dad jokes
going first, Steve, do you have

888
01:07:53.760 --> 01:07:57.920
some picks for us? Well,
I can look at that one of two

889
01:07:57.920 --> 01:08:00.239
ways. It's either let's hurry up
and get them out of the way,

890
01:08:00.000 --> 01:08:02.599
or let's get I did not that. I did not say that for the

891
01:08:02.639 --> 01:08:05.679
best part first, So I'll uh, I didn't say that either. I'll

892
01:08:05.679 --> 01:08:10.519
cut you a little slack there on
that one. Check Jack, this is

893
01:08:10.519 --> 01:08:14.760
always the high point of any of
our episodes, according to statistics and comment

894
01:08:14.840 --> 01:08:21.039
forms. But sorry, I got
to license statistics. Huh live right,

895
01:08:21.800 --> 01:08:29.119
Uh, Just I gotta get my
branding thing here. Okay. So the

896
01:08:29.159 --> 01:08:33.479
other day, my son, who's
uh, I won't say how old,

897
01:08:33.640 --> 01:08:36.880
they had a bunch of coins,
and so I had to take him to

898
01:08:38.159 --> 01:08:40.760
er and after about an hour I
asked the doctor. I said, how's

899
01:08:40.800 --> 01:08:46.279
he doing? He said, no
change yet, almost every feet there,

900
01:08:46.319 --> 01:08:53.800
I go, okay, so just
that funny. I decided that I'm going

901
01:08:53.840 --> 01:08:57.159
to make some money off my dad
jokes. You know, since I've been

902
01:08:57.159 --> 01:08:59.199
doing it for free so long,
I have to write them all every day.

903
01:08:59.239 --> 01:09:02.119
It's a lot of stress. So
I'm going to put out a cologne

904
01:09:02.560 --> 01:09:09.720
for men who like dad jokes.
I'm going to call it pungent. That's

905
01:09:09.840 --> 01:09:15.279
nice right now, This one requires
a little bit of thinking, but I

906
01:09:15.399 --> 01:09:17.680
like I'm you know, I'm the
dad jokes for the smart person. So

907
01:09:17.760 --> 01:09:25.279
my nerdy friend, uh just got
a PhD in the history of palindromes.

908
01:09:25.560 --> 01:09:28.680
Now palindromes, for those who might
know off the top of your head,

909
01:09:29.039 --> 01:09:32.359
there's words that are spelled forward and
backwards. They're the same when you're doing

910
01:09:32.399 --> 01:09:38.760
forward and backwards. Now we call
him doctor awkward. Yeah, you need

911
01:09:38.840 --> 01:09:42.880
to see it to get it.
But it's it's great, right, very

912
01:09:42.920 --> 01:09:45.720
good. So those are my dad
jokes for the week. All right,

913
01:09:45.840 --> 01:09:50.600
Dan, what are your picks?
Okay? I to be honest, I

914
01:09:50.640 --> 01:09:56.359
don't have that much in the way
of picks. So the only the real

915
01:09:56.479 --> 01:10:01.920
pick I have is that I was
interviewed on another podcast. I was a

916
01:10:01.960 --> 01:10:09.039
guest on the Contagious Code podcast that
the tageous friend of our show. He's

917
01:10:09.039 --> 01:10:14.960
doing his own podcasting has had some
awesome guests like you know, Gier Morauch

918
01:10:15.600 --> 01:10:20.079
and others. I highly you know
if you like tech podcasts. I mean

919
01:10:20.199 --> 01:10:25.920
you're here so you probably do.
That's another one to look to look into.

920
01:10:26.000 --> 01:10:28.920
So I was a guest I will. We recorded, and actually a

921
01:10:28.920 --> 01:10:32.359
pretty lengthy one. I think it
was over an hour and a half because

922
01:10:32.399 --> 01:10:39.079
we really got into my tech history
and my tech journey and you know,

923
01:10:39.279 --> 01:10:43.439
things that I've done and how I
got into the whole performance thing, and

924
01:10:43.800 --> 01:10:45.960
well, I've had the long career
as you can probably tell by looking at

925
01:10:45.960 --> 01:10:50.199
me. For those of you are
actually watching the video, by the way,

926
01:10:50.359 --> 01:10:55.600
Ah, yes I am for sure. So that's that's one pick.

927
01:10:55.920 --> 01:11:00.600
The other pick is my new employer, I sense. I've been there for

928
01:11:00.640 --> 01:11:05.319
about a week and a half.
They welcomed me wonderfully. I'm enjoying myself.

929
01:11:05.680 --> 01:11:11.079
A funny thing though, So I
was getting into the code base after

930
01:11:11.199 --> 01:11:14.520
like and I thought, you know, after just three days being there,

931
01:11:14.560 --> 01:11:18.520
and I thought, you know,
what could be a better way than to

932
01:11:18.600 --> 01:11:25.720
do a small full request on the
code. So I started looking at something

933
01:11:25.760 --> 01:11:32.359
to fix, ended up changing twenty
files and what some people defined as core

934
01:11:32.439 --> 01:11:40.439
functionality of the product. But you
know, it got accepted, it got

935
01:11:40.520 --> 01:11:44.439
merged, so you know you're going
to go go big. Yeah, I

936
01:11:44.479 --> 01:11:50.640
did something right. Whenever I try
that, it always crashes, you know,

937
01:11:50.800 --> 01:11:58.319
but at the very least you get
noticed. And my final kind of

938
01:11:58.319 --> 01:12:03.720
an anti anti pick is that I
watched the movie Atlas on on Netflix,

939
01:12:04.399 --> 01:12:09.279
and the only good thing I can
say about it is that it that it's

940
01:12:09.359 --> 01:12:15.560
more watchable than Rebel Moon. What
is Atlas about? What? It's a

941
01:12:15.640 --> 01:12:23.840
sci fi movie with Jennifer Lopez.
It's no, she actually she's actually fine.

942
01:12:24.640 --> 01:12:30.600
Uh, It's it's the story that's
kind of stupid, but you know,

943
01:12:30.920 --> 01:12:36.119
and the action, the final boss
fight is not much of a fight

944
01:12:36.680 --> 01:12:43.399
in my opinion, and you know, so it's it's kind of met uh,

945
01:12:43.720 --> 01:12:46.680
which, like I said, meh, is much much better than Rebel

946
01:12:46.720 --> 01:12:54.319
Moon. I could not finish watching
the first one, so obviously I didn't

947
01:12:54.319 --> 01:12:59.079
even try watching the second one.
All right, Yeah, anyway, those

948
01:12:59.079 --> 01:13:03.760
are my picks. Good deal.
I'm gonna throw out a board game pick

949
01:13:03.840 --> 01:13:06.560
here real quick. Of course,
I should have thought ahead and thought,

950
01:13:06.560 --> 01:13:15.359
what I want to pick. I
think I'm gonna do another legendary expansion.

951
01:13:17.600 --> 01:13:25.479
So one of the ones that I've
really enjoyed playing is the Shield expansion,

952
01:13:28.840 --> 01:13:32.800
and I think a lot of it
was based around if you watch the Legend

953
01:13:32.840 --> 01:13:39.239
of Shield or not the Legend of
Shield the anyway, it was a TV

954
01:13:39.319 --> 01:13:46.600
show that that was the Shield Agents
of Shield TV show a thing. Yeah,

955
01:13:46.680 --> 01:13:53.800
it pulled in a lot of stuff
there. One of the one of

956
01:13:53.840 --> 01:13:58.960
the optional things that you can do
is you can buy a Shield Agent as

957
01:13:59.039 --> 01:14:03.399
part of your you know, one
of your actions if you have enough to

958
01:14:03.399 --> 01:14:10.079
recruit them. And this one gives
you basically you you have special characters and

959
01:14:10.119 --> 01:14:15.319
they're the characters from the TV show. But anyway, it's a fun expansion

960
01:14:15.359 --> 01:14:20.520
to play with. Nick Fury is
in the main set of heroes that you

961
01:14:20.520 --> 01:14:28.560
can play with from the main game. And so I'm trying to find it

962
01:14:28.600 --> 01:14:32.600
on board game geek. Give me
a second here, Oh, here we

963
01:14:32.680 --> 01:14:36.720
go. So board game weight on
this one is two point seventy five.

964
01:14:36.760 --> 01:14:42.239
I think the base games like two
point three five, so you know,

965
01:14:42.840 --> 01:14:45.880
it makes a little more complicated,
but it's not terribly complicated, and it's

966
01:14:45.960 --> 01:14:51.680
it's a fun expansion to play with. And so yeah, anyway, I'm

967
01:14:51.680 --> 01:14:56.239
gonna pick that, and then I
have a couple of other picks. One

968
01:14:56.239 --> 01:14:59.439
of them is sitting on my desk. My eight year old made me a

969
01:14:59.479 --> 01:15:04.359
card and so it says, I
love you Dad, and uh, anyhow

970
01:15:05.000 --> 01:15:08.920
I walked in this morning, it
was sitting on my desk. So don't

971
01:15:08.960 --> 01:15:13.159
you just love it when they're still
young and do things like that for you?

972
01:15:13.720 --> 01:15:16.359
Right? My seventeen year old's like, what you want something? Right,

973
01:15:16.520 --> 01:15:21.800
So try me to work. So
anyway, but yeah, so that

974
01:15:21.800 --> 01:15:27.319
that makes me smile for sure.
And then yeah, I mean, I've

975
01:15:27.319 --> 01:15:30.680
been pretty involved in the political political
scene here in Utah, and I just

976
01:15:30.720 --> 01:15:34.640
want to encourage folks if you're you
know, if you're out there and you

977
01:15:34.680 --> 01:15:40.840
care about what's going on in your
society. I'm getting ready to launch a

978
01:15:40.840 --> 01:15:44.439
podcast about this stuff. But I
really feel like a lot of the things

979
01:15:44.439 --> 01:15:46.720
that make the difference in the long
term are what you're doing at home and

980
01:15:46.760 --> 01:15:49.920
then what you're doing in local politics. A lot of the folks that are

981
01:15:49.960 --> 01:15:55.319
running for Congress or Senate here in
Utah or governor, they all kind of

982
01:15:55.359 --> 01:16:00.600
came out of local politics, and
then you know, kind of moved up

983
01:16:00.640 --> 01:16:03.319
a level and then another level,
right, And so if you're not happy

984
01:16:03.359 --> 01:16:08.319
with your politicians, a lot of
these folks kind of start at a smaller

985
01:16:08.399 --> 01:16:11.560
level and move their way up.
And so you've got to support the right

986
01:16:11.600 --> 01:16:15.920
people at the at the local level, because many of them will wind up

987
01:16:15.960 --> 01:16:20.560
being your people at the at the
higher or more more broad levels, I

988
01:16:20.560 --> 01:16:24.920
guess, or I don't want to
say higher levels, because in a lot

989
01:16:24.920 --> 01:16:30.199
of ways, the further away from
you they are, the less impact they

990
01:16:30.239 --> 01:16:35.359
have. It depends on the issue, obviously, but you know, you

991
01:16:35.399 --> 01:16:39.560
see the dysfunction at the at the
federal level here at the in the US,

992
01:16:39.720 --> 01:16:42.279
right, and you're just like,
you know, these knuckleheads that you

993
01:16:42.560 --> 01:16:45.159
know wind up in Congress, and
some of them really good and some of

994
01:16:45.159 --> 01:16:48.359
them really not. You know,
they came up the same way, right,

995
01:16:48.520 --> 01:16:54.239
And so go support your local folks
that believe what you believe and value

996
01:16:54.239 --> 01:16:58.239
the things you value. I do
have a comment about this, if I

997
01:16:58.319 --> 01:17:01.119
may. Yeah, first of all, I totally agree with everything you said,

998
01:17:01.640 --> 01:17:06.880
and I think you know, being
involved and you know, doing things

999
01:17:06.960 --> 01:17:14.399
for causes that are important to you
is definitely a good thing. But there

1000
01:17:14.479 --> 01:17:19.159
is a certain responsibility I would say
that goes with it, that you you

1001
01:17:19.359 --> 01:17:26.359
do need to kind of do a
bit of research and do some thinking and

1002
01:17:26.439 --> 01:17:31.800
some analysis and verify that the causes
that you support are actually, you know,

1003
01:17:32.439 --> 01:17:38.560
correct and proper and righteous causes and
that you're not just buying into some

1004
01:17:38.840 --> 01:17:45.960
demagogery because you know it seems cool
or or you know it's the thing doujour

1005
01:17:46.079 --> 01:17:51.800
or whatever that you actually you know
that you properly make up your mind and

1006
01:17:51.840 --> 01:17:57.720
not just go based on you know, what somebody has said. That's you

1007
01:17:57.760 --> 01:18:01.159
know, make it whichever way you
think is best, and you know,

1008
01:18:01.199 --> 01:18:05.680
according to your own principles. But
do the do the thinking, do the

1009
01:18:05.720 --> 01:18:12.359
research. I absolutely agree. Here
in Utah we have a caucus convention system

1010
01:18:12.800 --> 01:18:15.720
and the you know, so you
have the local caucuses, you elect delegates.

1011
01:18:16.199 --> 01:18:18.399
The delegates go and do a lot
of that kind of a thing.

1012
01:18:19.000 --> 01:18:23.399
But that doesn't mean you can't be
involved if you're not a delegate. But

1013
01:18:23.520 --> 01:18:27.399
yeah, you should be doing the
same kinds of research and the same kinds

1014
01:18:27.399 --> 01:18:30.359
of having the same kinds of conversation
with these folks as the delegates and being

1015
01:18:30.399 --> 01:18:34.239
okay, you know, this is
an issue. Where are you want it?

1016
01:18:34.600 --> 01:18:38.680
You know, this is a principle
that I hold to. How do

1017
01:18:38.680 --> 01:18:41.359
you feel about it? And then
talk to other people and you know,

1018
01:18:42.520 --> 01:18:45.520
inform yourself. Okay, they said
this thing, Now do they actually does

1019
01:18:45.520 --> 01:18:47.840
it actually bear out in the way
that they've voted or you know, done

1020
01:18:47.840 --> 01:18:55.079
their job as a you know,
representative in your local government. But yeah,

1021
01:18:55.119 --> 01:18:58.439
I entirely agree. And you know, the longer you do it,

1022
01:18:58.479 --> 01:19:02.279
the more you I guess it better
at sniffing out who really is where you

1023
01:19:03.000 --> 01:19:08.640
want to be and where or not. But there are also terrific organizations and

1024
01:19:08.640 --> 01:19:11.880
it's the same kind of thing.
Whereas Dan said, you know, sometimes

1025
01:19:11.960 --> 01:19:15.680
you get somebody that's, you know, the person at the top of the

1026
01:19:15.800 --> 01:19:19.119
organization. It turns out that they
were on an ego trip, right,

1027
01:19:19.199 --> 01:19:21.800
and so they got a bunch of
people that believe like you believe, to

1028
01:19:21.840 --> 01:19:26.239
back them up. And then it
turns out that there's some issue. You

1029
01:19:26.279 --> 01:19:29.600
know, there's something rotten at the
core of it. And it's not because

1030
01:19:29.600 --> 01:19:32.199
your principles were wrong. It was
because you backed the wrong person or because

1031
01:19:32.319 --> 01:19:34.680
you know, there was no way
of knowing that this person was a problem

1032
01:19:34.680 --> 01:19:39.039
and so yeah, you definitely have
to do your homework because you want to

1033
01:19:39.119 --> 01:19:43.960
get in and push where it's going
to make a difference and make sure that

1034
01:19:44.000 --> 01:19:46.600
you're backing these things. And I
don't bat a thousand on this stuff,

1035
01:19:46.680 --> 01:19:51.520
right. I don't always get it
right, but you know, more often

1036
01:19:51.560 --> 01:19:55.279
than not these days, I'm able
to figure out, oh, you know,

1037
01:19:56.439 --> 01:19:59.760
there's something here that's making me uncomfortable, and sometimes it's just a gut

1038
01:19:59.800 --> 01:20:03.479
fee and so I'll put my effort
elsewhere because yeah, and then it turns

1039
01:20:03.520 --> 01:20:09.079
out that a lot of times that
gut feel is right. Anyway, I'm

1040
01:20:09.079 --> 01:20:14.640
starting a podcast to this effect.
It's it's probably going to be focused mostly

1041
01:20:14.680 --> 01:20:18.079
on the US. That doesn't mean
that it can't apply to other countries,

1042
01:20:18.119 --> 01:20:23.439
but it's it's going to be called
America's Destiny, and it's essentially, yeah,

1043
01:20:23.439 --> 01:20:25.720
it's this idea. It's like,
okay, well, you know,

1044
01:20:25.960 --> 01:20:29.319
as these issues come up, how
do you address them at home, you

1045
01:20:29.359 --> 01:20:30.840
know, with your kids, and
then how do you address them with your

1046
01:20:30.840 --> 01:20:35.279
neighbors? And then you know,
how do you get involved and understand how

1047
01:20:35.279 --> 01:20:39.479
these things are going to affect you
at the local level, and then how

1048
01:20:39.479 --> 01:20:43.680
do you kind of find and reason
through. Okay, this is a good

1049
01:20:43.720 --> 01:20:47.359
person to support at the local level, and then how do I encourage them

1050
01:20:47.520 --> 01:20:53.600
when the right time comes along to
go and make a larger impact in a

1051
01:20:53.800 --> 01:20:58.720
you know, in a different arena. So anyway, and I get myself

1052
01:20:58.720 --> 01:21:00.720
in trouble sometimes for speaking up,
but that's the way that that goes sometimes.

1053
01:21:01.039 --> 01:21:04.760
So anyway, those are my picks, Jack, what are your picks?

1054
01:21:05.760 --> 01:21:09.920
Yeah, I'll throw in a couple
quickly. To briefly pull us back

1055
01:21:09.920 --> 01:21:14.199
to the performance panel. We ship
something in Chrome recently called selector stats,

1056
01:21:14.520 --> 01:21:18.680
which for recalculate stars event lets you
dive into where that time was spent the

1057
01:21:18.680 --> 01:21:21.600
CSS selectors causing it. The reason
I want to shout this out is because

1058
01:21:21.720 --> 01:21:26.000
we didn't build it. It was
built by the Microsoft folks who work on

1059
01:21:26.039 --> 01:21:30.119
the Edge Dev Tools team, but
they upstreamed it into Chromium until now it's

1060
01:21:30.119 --> 01:21:32.479
available to Chrome and as users,
which I think is just really nice that

1061
01:21:33.760 --> 01:21:38.760
you two big companies able to collaborate
and both share kind of features. So

1062
01:21:38.800 --> 01:21:42.319
I thought that was really nice.
I'll follow the board game theme as well,

1063
01:21:42.680 --> 01:21:45.640
a laatest addition to our ball game
collection. It is a co op

1064
01:21:45.680 --> 01:21:50.520
game called Sky Team, which is
I think fairly new. I think I

1065
01:21:50.560 --> 01:21:54.880
found it VI a YouTube channel that
does board game reviews. It's a corruptive

1066
01:21:54.920 --> 01:21:59.000
two player game where you're piloting a
plane and you have to roll dice to

1067
01:21:59.000 --> 01:22:03.000
make strategical decision to land the plane
successfully. But what's really quite cool about

1068
01:22:03.039 --> 01:22:05.279
it is once you've rolled these dice, which you then have to use in

1069
01:22:05.319 --> 01:22:10.000
certain slots on the board to achieve
things, you and your person you're collaborating

1070
01:22:10.039 --> 01:22:12.880
with you're not allowed to talk to
each other and the dice are hidden,

1071
01:22:13.079 --> 01:22:16.399
so you've rolled four dice with certain
numbers. Your other players rolled four dice

1072
01:22:16.439 --> 01:22:20.359
and have got four numbers, and
in silence, you have to decide,

1073
01:22:20.359 --> 01:22:25.039
one at a time where to put
these dice to achieve things. But you

1074
01:22:25.039 --> 01:22:27.720
know, it's classic. If you
put two dice here that sum up to

1075
01:22:27.720 --> 01:22:30.119
a number greater than ten, that's
bad. But if you put two dice

1076
01:22:30.119 --> 01:22:33.399
here that sum up less than three, that's also bad. So you're it's

1077
01:22:33.479 --> 01:22:38.000
kind of fun collaborating, but also
with a bit of silence, it's enjoyable

1078
01:22:38.000 --> 01:22:41.880
and normally ends up with you looking
at each other at aghast with horror as

1079
01:22:41.920 --> 01:22:45.840
your partner puts the wrong dice in
the wrong box, which you never would

1080
01:22:45.880 --> 01:22:48.399
have done. That's been fun.
So yeah, it's called the Sky Team.

1081
01:22:49.239 --> 01:22:51.960
Yeah. It reminds me a little
bit of some of the other sort

1082
01:22:53.000 --> 01:22:59.239
of blind collaboration games like Hanabi,
which is where you have your cards facing

1083
01:22:59.279 --> 01:23:00.760
out to everybody else can see what
cards you have, but you're the one

1084
01:23:00.760 --> 01:23:05.640
that has to play, and so
you're giving hints. You know, you

1085
01:23:05.760 --> 01:23:10.000
have some means of communication, but
not a ton. So I just looked

1086
01:23:10.000 --> 01:23:13.119
it up on board game Geek.
It has a weight of two point h

1087
01:23:13.159 --> 01:23:18.520
two and I keep telling people that's
kind of your average casual gamer that with

1088
01:23:18.600 --> 01:23:23.239
the game that has enough complexity to
make it fun and interesting. It says

1089
01:23:23.239 --> 01:23:26.960
it runs in about fifteen minutes.
Does that sound about right? Yeah?

1090
01:23:27.039 --> 01:23:29.760
I think it's the first one took
a bit longer as we figured out,

1091
01:23:29.840 --> 01:23:32.479
right, Yeah, it's pretty stappy, which we have a new child in

1092
01:23:32.520 --> 01:23:36.479
the house, so fifteen twenty minutes
is about the max time we get to

1093
01:23:36.479 --> 01:23:40.439
play a game, so yeah,
that's about right. Yeah, and then

1094
01:23:41.399 --> 01:23:45.399
it's rated for kids age twelve plus. The community says that ten plus can

1095
01:23:45.399 --> 01:23:49.600
play it, so you know,
this is something that. You know,

1096
01:23:49.680 --> 01:23:53.199
maybe I coach my eight year old
on a little bit, but my other

1097
01:23:53.239 --> 01:23:57.079
kid could probably play fine. I'm
very into board games. I really enjoy

1098
01:23:57.119 --> 01:23:59.960
them, So thanks for that.
I'll check it out, No worries,

1099
01:24:00.760 --> 01:24:01.800
all right, Jack. If people
want to find you on the internet,

1100
01:24:01.800 --> 01:24:05.960
where do they find you? Uh? Yeah, so Twitter is Jack underscore

1101
01:24:06.000 --> 01:24:13.239
Franklin on that It's Jackfranklin dot co
dot uk for links to various other websites

1102
01:24:13.279 --> 01:24:15.960
and blog posts and all that kind
of stuff. Awesome, all right,

1103
01:24:16.000 --> 01:24:19.520
well up here, Yeah, thanks
for coming. Until next time, folks,

1104
01:24:19.520 --> 01:24:20.000
mats out.