Hey everybody, welcome back to another episode of JavaScript Jabber. This week on
our panel we have Dan Shapiir. Hello from a woman Sunny TELEVIV. I'm
Charles Maxwood and I ducked out a stand up to come to this, so
I'm excited. We have a special guest this week that is Jack Franklin.
And Jack, you're based out in the UK. You want to tell us
a little about yourself? Yeah, hey, thanks having me. Yeah,
manas Jack, I work Google on the Chrome dev tools, focusing on the
performance tooling. Yeah, based just outside of London, where it is sadly
not so sunny as it is for Dan, a little bit cooler here.
Yeah, we get that all the time. It'll be like, you know,
minus eighty one hundred degrees here in Utah and he's like yeah, it's
like sixty degrees and it's like okay, just go away and come back next.
Yeah. There's a downside to that, which is how hot it'll get
around Lion August soya. Yeah, yeah, it gets hot here, but
it's a dry heat. Like I lived in Italy for two years and boy
gets muggy there. It's like, yeah, it's one hundred degrees but it's
a completely different hundred degrees, so that's for sure. Yeah. All right,
Well, let's dive in and talk about Chrome dev Tools Jack. Before
we get too far in, I just want to get a little bit of
a story here, like, how do you wind up being a Chrome dev
tools person? Yeah? A lot due to good timing, I think.
So. I've been working in the front end space for all my career,
really since leaving university, and then I've been at Google now just over four
years. And it was sort of four and a half years ago to a
conference in the Netherlands. I did a talk on how the company I was
at before Google, we were using React and building components and it's kind of
rearchitecting our front end component driven manner, talking about kind of design systems and
the reason reusability and all that kind of stuff. And someone sat in the
audience happened to be working at Google on dev tools and had a space on
their team looking to hire someone in the London office, and so he spoke
to me afterwards, and I applied and kind of went through the interview process
and all that stuff, and thankfully came out the other side intact and with
a job offer. So that was that, and then yeah, four years,
four years later, I'm still still here. Oh wow, Yeah,
yeah it was. It's been an interesting ride for sure. So your background
is all web tech, because you know, obviously, when you think about
somebody who's working effectively in the Chrome browser, you also think about, hey,
that person needs to be coding in C plus plus or stuff like that.
Yeah. So I have a computer science degree, but after that,
the majority of my experience has been frontend. I've certainly never done any C
C plus plus or anything in that region. I was a Ruby developer for
a while. I've kind of dabbled with various languages, but professionally, yeah,
the majority of my time has been JavaScript, Typescript and various front end
tech. The thing with devtils is there's actually a web application itself, So
the entire Creme devtils is built with HTMLCSS and typescript and it gets embedded into
Chrome. So although I don't have the background to dive into the sort of
blank chromeum backend side, I'm very able to be very productive on the front
end, you know, and work on devtels. So when I was a
new developer, one of the my mentor Basically, we would joke that we
were going to write an application that it was code quality, not performance,
but it was going to be a really simple app that you would submit your
code and it would just come back and say, this code is terrible,
right, because everybody's code is terrible. So so isn't the correctness problem like
an NP complete problem? I don't know, But how do you write a
performance tool that's useful and not just your performances offul Yeah? Yeah, that's
the challenge I think. I think as well, a lot of performance is
about contextualizing it. So you know, depending on the type of app you
have or website and how it's used and the average user and what technology they
use to access, the sort of what we mean by good or bad performance
can vary a lot. So I think the constant challenge for us is trying
to strike that balance. And also I think that the balance we have is
we hear the feedback all the time. If you load up, you know,
go to a big website and run a use the Devitol's performance panel to
reload the page and recorder trace, you get presented with this this flame chart
and this stuff, and there's just boxes and different colors everywhere, and there's
various lines and markers and all sorts, and it is very overwhelming if you've
never used the tool before. Even if you have used the tool before,
it can be like, oh my goodness, where do I even begin to
start with. So, yeah, that's kind of what you're alluding to is
similar to the battle we have of we want to show all this information so
you can debug and dive in and understand truly why your website is, let's
say, loading slowly, but equally we don't want to we'd want to try
and not overwhelm me with all this information upfront. And that's kind of the
never ending tension that we we have. And I don't think right now we've
kind of struck the right balance, but it's something we're trying to resolve and
work on. Yeah, it's funny you said flame chart. In my brain
immediately went to there's a fire here, and there's a fire here there.
In the case of the tools, it's an upside down flame chart. The
fire is burning downwards, right yeah, yeah, yeah, so yeah,
and other tools will show it the other way. With the you know,
flipped there's a lot of different ways you can slice the data, and I
think, yeah, one of the challenges as well is how do how do
we get people to understand interpret what we're showing them correctly? Right, and
that is different. But before we dive into the details of this or that
death tools performance well dep Tools panel in general, I want to first of
all point out what an amazing tool dev tools are, and people and the
people today kind of take them for granted. And we've actually had an episode
about dev tools. It's more in general, I forget who came on the
show to talk about this from somebody else on your team will need to check
afterwards, Michael Halis, I think, yes, yes, it was,
Yes, it was. Thank you for reminding me. I still remember the
days. You know, I'm old enough to remember when we didn't have such
tooling, and you know how we would debug things with alerts and and afterwards
we got it that what are you talking about? And how Yeah, well,
at least now you can console log which is at least a bit better.
Uh. And then we got it for desktops, but initially didn't have
it for mobile, and then we got the ability to actually do it on
mobiles. So I think to a great extent, the modern web as we
know it today could not exist without dev tools. And of all the dev
tools in all the browsers, I like Chrome dev tools or you know,
Chromium depth tools, let's say the most. So kudos for that. Also.
The other thing I wanted to mention is that if we look at the
panels in Chrome depv tools, like half of them they have to do with
performance, and in one way or another, like the network tab, the
performance tab, the Performance info tab, the lighthouse tab, the memory tab
keeps on. The list goes on and on. Yeah, I have to
say just to add to this. You know, initially, when I got
into and realized that there were dev tools in there, right, I think
the first ones I saw were on Firefox, Right, I was like,
oh, this is him, right, And so then I'm starting to use
some of the same tools on Chrome. Once I start using Chrome, and
then somebody showed me the network tab and my mind was blown, right,
and then somebody showed me one of the other tabs I don't remember, and
you know, it was like, whoa, this does so much more.
And so you know, I have to admit I haven't really deeply used the
performance tab. So I'm hoping you're gonna tell me, Yeah, well you've
been missing out and here's here's what it does, hopefully. Yeah. I
think that the first development tools I remember using were Firebug. I think it
was called I think it was an extension to five fox, like a third
party thing. I'm to install it. Yeah. Yeah. And the first
time, I think, I think I was debugging some CSS issue and the
first time I realized that using Firebug I could adjust the CSS in the tool
and have it real time update was just incredible to me. Yeah, And
obviously the tools have come a long way since that. Fire Bug will always
I'll always remember that whenever we talk about the tools in any any situation.
I think, yeah, I had the neat little bug icon in the toolbar.
Yeah. So, so you want to give us kind of the ten
thousand foot view on the performance panel, and what I guess what I'm looking
for is sort of a how do you expect developers to use it? And
also, well, let's just start there because I can't remember what the other
piece was. Sure. Yeah, So really, I think when we talk
about performance, or when people think about web performance within the context of Chrome
and Google and all of that, we're really talking about the core web vitals,
which are these metrics that the Google has that we want that we think
represent kind of better performing websites that provide better experiences to use us. So
we expect most people using the Performance channel would be debugging their core web vital
scores. Two of the cowed vitals broadly. In fact one sorry LCP,
which is largest contemporal paint. We can divers deep into what these mean or
or don't mean, but LCP really represents how quickly or not your page was
loaded and visible to the user and they could kind of read it and see
kind of what the content is. And so that's really all about loading speed,
what is delaying loading your website, And that's one thing that the Performance
Panel is really good at. You will record your website loading. It shows
you screenshots of the process as various elements loaded and were rendered. It shows
you the network requests, and it shows you all the JavaScript that was happening
at the same time. So that becomes a very good way to see ol
there's this bundle of JavaScript that was five megabytes in size that took ten seconds
to download that that I can see visually that stopped my page rendering and showing.
Then you also have CLS, which is layout shifts, so that's content
shifting around the page as it's loading. In the classic example here is like
the user goes to click a button and as they do it, another button
loads in and they click the wrong button. Can probably frustrating, as they
happened to me before for and it didn't make me really really angry either.
I've had it. I've had it before, Like a banner has popped into
the tops by fifty pixels. It's very frustrating on especially the banners. It's
mostly the banners. Yeah, that's what we'll do it most of the time.
But again that's the kind of thing we'll show you, and you again
using screenshots you can see kind of before and after those and try and figure
out what element was responsible for that and go from there. And the final
web vital is called i NP. It stands for Interaction to Next Paint.
Broadly, it measures how responsive and interactive your pages. So when the user
clicks on let's say button, how long is it until the UI updates to
show them that you know, your your app has dealt with that button click
and is processing or has registered it, or is doing whatever I'd say,
typically because that's newer and debugging sort of interactions where users have to interact with
your page is harder. Debugging loading speed is a bit easier because normally you
can run the page, load, you might change locally, rerun it again,
and you can kind of replicate that fairly straightforwardly. Interactions where you have
to try and you know, click a textbox type in at a certain time
to hit some ed case which is causing slowness can be trickier. But those
are kind of what when we think about what features we should be building and
working on in the performance panel and what kind of user journeys we want to
make easier, it's those web vitals that we're kind of motivated by. Really,
gotcha? So how does that actually show up in the panel? Right?
Yeah? So the main panel is made up of a series of what
we call tracks, and these are kind of horizontal roads that go all the
way across the screen. These show specific categories of events or things that happened.
So and obvious one is the network track. This will show you all
the network requests that happened during that timeframe, and it shows them as rectangles
where these are representive time. So the wider the rectangle, the longer that
particular request took its flight. Simpification because there are there are additional bars on
over end which represent different parts of the network. I wanted to you mentioned
it. It's for those you know, it's kind of duplicate information with the
network tab in the sense that you can in both cases you can see the
rectangles the kind of the waterfall that represents the network activities. If just analyzing
the network itself, and often that's where I start. Then to be fair,
I prefer doing that on the network tab initially simply if for no other
reason reason that it's much less busy. And but like you mentioned with the
bars at the end, once I start analyzing the overall activity of the page
and start correlating the downloads with the JavaScript activity, because I'd say a JavaScript
is triggering a fetch request, and then when that fetch request finishes, then
JavaScript is triggered again to process the results of that fetch request. So when
I do that holistic analysis, that's where the performance panel really shines. And
you might want to explain, you know, either an now or later those
lines at the end, because like you said, there's the actual bar itself
that has like a like a lighter color and a darker color for the but
it also has the bars at the beginning like the mustache. I think you
call it at the beginning and the end. Yeah, we call them whiskers.
Whiskers Okay, yeah, same concept, you love it and yees.
So I think you're right. If you're debugging purely network issues, the network
panel, I mean, just real estate wise, has more room because it's
only showing you network things, whereas the force we have to get the network
in alongside or the various the things that we show. And yeah, the
key thing with the performance panel, I think is what Dan is touching on,
is that you've got all these tracks that have different types of information in
but crucially they're all aligned based on timestamp, so you can look vertically down
and see exactly what all of these different you know, what stuff was happening
at this particular timestamp, so what network requests were happening. Then we jumped
to a track that shows a screenshot of your page at that given time.
Okay, so this is what the pagent like. Then we jumped to any
layout shifts that happened at that time, and then it's main thread activity,
which really is what heavy jobscript was running, let's say re rendering you know,
an Angular component or a React component or whatever else it may be.
So where the performance panel, I think it is power comes from is at
any point in time you can see across a load of different categories what the
browser was having to do to provide the user with your website or web application.
You know, it's funny you're talking about all of this, and I
can imagine why it's hard for you to figure out how to give people a
concise picture of the thing. Yeah, oh yeah, for sure. The
performance panel is I think by far the busiest of all the panels. To
the extent, I think that you created the Performance Insights panel to provide a
slightly less busy view, as it were. But on the other hand,
once you grasp it and you master it, I think it really becomes a
superpower like it definitely takes you to the next level in terms of your abilities
to analyze and understand what the web page is doing. Yeah, and so
to touch on the Performance Insights panel, so this is a distinct panel from
the performance panel, very confusingly named. I'll give you that one. We
noted this I think last year. It's very much an experimental panel. The
goal is to kind of explore how we could without without hiding away all this
detail, which, as Dan said, once you kind of understand it and
what it's repped venting, is really powerful and really actually dive deep. But
for users maybe newer to the sort of this topic is very overwhelming. So
the Performance Insights panel was an experiment and how can we pull out what we
call insights and try and guide the user to, hey, here's here's a
problem that caused your page load in a way that didn't need them to dive
into all the nitty gritty detail. It was I think semi successful. The
feedback was at a good mix of hey, this is really useful this sort
of high level view to hey, this is cool, but because I want
another level of detail, I will never use this, I will always use
the performance panel. And long term, we didn't really ever want to maintain
two distinct panels for the foreseeable future. So actually the Performance Insights panel will
eventually be removed, but what we learned from that in terms of insights will
be coming into the performance panel. There's a blog post, which we can
link to, I guess in the show notes, so I can put on
chat where we kind of talk more about these plans. But yeah, we're
trying to figure out a world where we can give people these useful kind of
insights like hey, this particular network request was the source of a lot of
problems for you in this this pageload, but also provide all the data so
people like Dan can dive in and find exactly what they're looking for. So
first of all, it's news to me that performance insights is kind of a
temporary thing. So thank you for highlighting this. And you know what you
should do? The answer is AI the chace. Yeah, we're still figuring
out exactually how AI slots into all this. But yeah, yeah you're at
Google. So I was going to say you handed off to chet GPT,
but you handed off to Gemini and say, yeah, here's the output.
What do you what do you make of this? Yeah, something like that.
It's so hard as well, because I really learned this when I started
working on building the performance panel and understanding behind the scenes the thing that powers
the performance panel in these flame charts, So what are called trace events?
And these are really just objects of data that Chrome emits during a page load,
and you begin to see, Okay, so every time I have this
event, I'll always have this other event that is named like this, and
you can try and build relationships between these events. But then you release this
feature into the world, and you know, a thousand people use it across
a thousand different websites, and they just blow all your assumptions out of the
window because there's such a variety of technologies and approaches and all the rest of
it. And so the challenge with ANYAI would be useful, whilst not kind
of pigeonhole and I think into a few certain categories, but yeah, who
knows. I'm sure it'll be a space will be exploring along with the rest
of the Internet at some point. So one of the going back to the
details of the performance panel, I think one of the things that confuses people
them boast about it is the fact that it simultaneously shows two timelines. At
the very top, you have a timeline that encompasses the entirety of the recorded
period, while slightly below it you have like a partial timeline. Yeah,
so we have the mini map I would call it the top, which shows
sort of the activity over the whole trace period. But then what we let
people do is there's two kind of handles which you can drag to select a
subset, and then the rest of the panel is scoped to that subset.
The idea being that you can quickly zoom in on a period of time that
is particularly interesting to you. That's one of the things we shipped I Lose
Track of Time earlier this year is the ability to once you zoomed in,
you can actually click a button and kind of zoom in again and save that
zoomed in state. But one of the things we're thinking about it was something
we want to do with the Performance Insights panel didn't ever get around to it
was could we, for example, automatically detect areas of interest and provided with
short cuts to to particular time spans that we think contain the most relevant information.
So if you've got a page that takes five six seconds to load,
clearly that's not good and you'd like to get that down. But normally there'll
be three or four culprits within that six seconds where where your attention is best
focused. Well, you do kind of do it already, don't you.
I mean already. When you record the page load, you often like zoom
into a particular period of interest in issue. We will, but that's not
because it's we've identified that period as interesting. It's because we've identified the rest
of the traces effectively dead space. So this is the example here is say
you record for ten seconds and all the activity happens in the first three seconds,
We'll try and zoom into those three seconds. So really we're just trying
to trim if there's dead space at the start or end of your timeline,
we're trying to get rid of that. We're not really identifying like this is
where there was a slow network requests, and so we should draw the users
attention to that. That's kind of something I think on our radar to to
explore that that idea generally of can we highlight areas of interest? And it's
something that in Lighthouse, if you do a Lighthouse report on a page,
will also show you estimated savings for a bunch of the audits. So Lighthouse
will say this image that you loaded was you know, ex megabyte big.
If you convert it to whatever and optimize it, you might save one second
on this network request. And so what we could do is we could begin
to rank, you know, things we find based on how much potential savings
we think there might be to help the developer prioritize as well, because I
think, you know, in a perfect world, developers have endless amounts of
time to spend optimizing every millisecond of their page load. But you know,
we all know that's not true, and sometimes this work is prioritized against other
work and you don't get to spend as much time as you like on it.
So, like, can we direct you to the most impactful things sooner,
so that if you only have a few hours or a day to work
on this thing for your company, you can have the most impact. By
the way, you kind of mentioned here how you can maybe cross pollinate between
Lighthouse and the DEPV tools by bringing Lighthouse insights into the performance panel. I
would like to mention that one cool feature of the Lighthouse that is built into
DEAV tools is that you can jump from Lighthouse into the performance panel for that
Lighthouse session. Oh wow. Yeah, So you can click a link and
it will take you into the performance panel with the recording of the pageload that
Lighthouse used, so you can dive in and it's actually something we're working on,
and this is in our blog posts from earlier this year, is we
are literally working on integrating lighthouses kind of analysis tools deeply into the performance panel.
So the long time vision is that there won't be a distinct lighthouse panel
within death Tools, not because we're removing that functionality, but it will kind
of be combined into the performance panel. The exact details obviously to be ironed
out, and there will be a lot of experimentation on how we do this,
but that is something that we're kind of working on, and just to
be very explicit, that isn't lighthouse going away. It's it's meaning. So
if you want to work on performance and dev tools, you go to the
Performance panel and you don't have to decide between the performance panel or the Performance
Insights panel or the lighthouse panel. We're trying to kind of collate the better
everything into one panel. That is the place to go. So when we
record a session within the Performance panel, one the obvious way is simply just
click the record button, which start a recording, and then you can do
whatever you want, including reloading the page, and then you explicitly stop the
recording when you want. The other option is to click the reload button,
which automatically instigate a reload of the page with the recording and and then also
automatically stops the recording when loading is complete. How do you determine when to
stop the loading? By the way, in that scenario, Oh, you're
pushing my memory of the code. But I'm pretty sure it's after a particular
event, a particular page load event. I think we wait a few more
seconds, I think, but you I'd have to, I'd have to look
up the exact inmentation, But I think it's it's something fairly straightforward, like
wait for this particular event and then allow a few seconds of grace for anything
else to flow in. But yeah, the idea with that one is is
we expect people to use that when they're explicitly debugging their pages load time.
So we wait for when the event that basically tells us that the page is
loaded, give a few extra seconds just in case, and then and then
stop if I remember rightly, but don't quote beyond that. So usually when
I'm loading a page, you know, in some if in some cases,
let's put it differently, when it works, I like to use the reload
button simply because it's the faster option. I have run into some cases with
some websites where it stopped too soon, and then my only recourse was to
actually click the record explicitly, reload explicitly, and then stop it explicitly when
it's done. But yeah, when the reload works automatically, it's the cleaner,
it's the nicer option. Now, as long as we're talking about that,
though, another thing or another suggestion that I have or a gotcha to
watch out for is a lot of people just analyze the loading performance in a
regular tab in the regular browser, and that means that they're also kind of
profiling all their extensions, which may not be what they want to do.
So very often what you really want to do is to try to analyze it
in you know, in the middle at least to begin with, in in
the most in the cleanest environment possible. And in that context, I wanted
to ask you because there are really two ways to achieve it. One way
is to simply open up an incognito window and and you know, do the
recording and that. Another option is to create a profile just for debugging purposes,
So basically, just create a local profile has no extensions in it and
use that, which would you recommend. I don't think it makes too much
difference. I think I'm trying to remember if people would have to think about
casing if they had a distinct profile, because also you need to often you
want to make sure in dentals that the in the network panel you've you've de
selected or ticked rather disabled cash in order to get kind of a fresh page
load. So trying to remember if incognito effectively, But it wouldn't matter if
you has the same website a few times in the same incompanies have tabed,
So I think it's really a matter of personal preference. But yeah, that
is a common kind of gotcha that when you're reloading the page, you are
reloading the page within your your active Creren profile, and we can't do anything
to stop all those various extensions and whatnot running. So yeah, we do
recommend one of those approaches IDV for traces, if you're trying to be the
most accurate. I think another kind of on that same theme, we see
people testing a lot on their very fast Ethernet connection in their office in the
center of some big city which has amazing connection speeds. Generally, I think
people need to consider they should be throttling the network, which is something you
can do from within the panel before you start a recording, to try and
emulate, say a three G connection or something slower, if your users maybe
are typically on mobile a bit more, or if generally your users just aren't
on a big Ethernet connection. So one other thing with mobile is and I
think I've seen people do this, but I'm not sure exactly how. And
I guess this is more a general dev tools question than a performance question.
But if I load the app on my phone sometimes it does things a little
differently anyway. Yeah, so is there a way to hook up my dev
tools on my computer so that I can watch the performance on my phone?
Yeah? There is, So you would plug in your phone via a USB
lead, And then there is there's deb tools remote debugging. I don't quite
remember the steps get it working, but there'll be documentation. But yeah,
that isn't it explicitly supported use case you can do it? I think yes,
you definitely can. There's just one really important caveat which goes to the
episode we recently recorded with Bruce Lawson, and that's the fact that Chrome on
iPhone is not Chrome. So if you want to if you want to debug
Chrome on a mobile device, you can debug Chrome on an Android device.
But if you want to debug Chrome on an iPhone, that's kind of a
problem because it's not really Chrome. Yeah. Well that's just another reason.
Since it's a different engine and everything, right, because it's all using the
WebKit engine exactly, then then I definitely want to be checking it out right
because it may it may do something entirely completely different or do it in a
different way. It will, but the problem is that you I don't think
you can use Chrome dev tools to debug uh and Safari Safari and Chrome on
iPhone is effectively Safari. So you know, until we finally get Chrome on
an iPhone, you know, fingers crossed. I you know, it's so
for now, if you if you really want to do the mobile debugging rather
than simulating a mobile device, you really have to use an Android device.
Yeah, yeah, correct. Now, so we we talked about the the
tracks, thet the structure of of the panel that on the on the at
the top you have you called it the mini view. How how did you
call it the mini map? The mini map, and and you know,
it's it's really a useful starting point, and you've added a lot of useful
information into it. So you know, you've got the screenshots, You've got
the graph showing periods of CPU activity and even color coded to show what the
CIPU is busy doing. I not so long ago learned that when it's thatched,
it means that it's activity. It's the CIPU is busy, but it's
off of the main thread. Is that correct? I honestly couldn't tell you
after my head about checking. So there are there are kind of is this
like the horizontal bars of the pair or is this kind of thatched in the
sort of Yeah, I'm so, I'm talking about you know the graph at
at the very top of the mini map, you know where you see the
yellow graph for the JavaScript for example, and occasionally you would see like a
thatched pattern. Yeah, you also have those small bars that are either dark
red or light red for to indicate long tasks. Sorry, yeah, yeah,
so then the long tasks. I don't remember the exact heuristic for why
error is at thatched, but yeah, it will be something problematic, But
I don't remember the exact criteria for what it is off to my head.
I would take that later on. But by the way, long tasks or
or or long frames sometimes they're called, are basically again, correct me if
I'm wrong, are basically when the main thread is busy and consequently is unable
to produce the desired frame rate. In other words, it's check yeah,
exactly that. So the browser wants to create a frame but is not able
to. It's not here. Create a frame basically means, you know,
paint and update to the user, update the website. It's unable to because
jobscript is keeping the main thread busy and therefore it browser doesn't get a chance
to do it. So the best way to kind of deal with that is
ideally split up your jobscript into smaller tasks. There are now APIs. I
don't remember the stage there up, but they're coming around scheduling. So there
will be a scheduler API where you'll be able to incue some code like a
callback function to run, but tell the browser what priority that callback functions should
have. So there's more powerful scheduling tools coming to the browser. They may
already be in there, I don't quite remember. But the kind of the
way other people do this is you can use the request animation frame call back.
Historically, people you set time out and gave it a function and then
with a zero time which really just gives the browser you know, a chance
a gap to do some other work. So that's that's the main thing that
is important with long task is it's too much jobscript running without a break.
Yeah. I'm kind of amused by that because you know, we talk about
ways to do splitting on IDOL, callbacks, set time out like you mentioned,
and other APIs that are coming. But realistically, I think unfortunately a
lot of web devs are not really using these APIs directly anymore because we're working
primarily inside frameworks like React or View or Angular, and you know, they
control where when our code runs and how execution is partitioned. So for example,
if you're using React, it's probably about using suspense and use transition and
stuff like that rather than you know, manually scheduling code in most cases,
I mean, you know, obviously there are other different scenarios, but but
that's for better for worse, what I'm seeing. That's the reality, and
more often than not, like a long period. For example, when using
React, the long task would be the hydration and you know, a lot
of a lot of developers aren't really you know, sure what you know,
what they can do about it anyway, So it's like leaving it up to
the framework to resolve such issues. Yeah, I think he's trying to get
my sister off the phone when I was a teenager. Yeah, I think
some of those APIs. I think some of the motivation is that they will
be able to be used by frameworks. So I think some of the APIs
around scheduling, particularly. I wasn't involved in the design process of them at
all, but it is thinking about how can developers use this to break up
their jobscip But it's also thinking about how can framework authors use this to very
easily introduce kind of batched or scheduling or scheduled updates using what's built into the
web platform and the browser, which has a couple of benefits. Really,
firstly, it should be more accurate and bluntly better implemented. Unless you spend
a lot of a lot of time working on scheduled kind of updates, they
can be very fiddly. And it also means that those framework authors don't have
to write code themselves to manage the scheduling and batching, or at least they
have to write less because they can also lean on a kind of built in
browser API. So some of the work in these APIs is not necessarily aimed
at developers building websites. It's saimed at those building the abstractions that a lot
of people are building on top of. So you mentioned what is probably the
most colorful, colorful part of the performance panel, which is the flame chart.
So obviously it's kind of difficult to explain without showing, but can you
briefly describe what it is and how it's how you read it as it were.
Yeah, I'll give it a go. This really is a picture paints
a thousand words, but I'll try and say fewer than a thousand words.
So the flame chart represents activity that was happening in your page. We're talking
here JavaScript that ran, and the way to look at it is, you
know, a rectangle on the flame chart was a bit of code that ran
for a certain period of time, represented by how long or short or wide
I should say the rectangle is what people will also see is there's a level,
there's nesting within the flame chart. So when you look at it,
it almost looks like a tree structure. So you can see that there are
rectangles. Then below that rectangle there will be a smaller rectangle, and then
below that there could be many levels of these sort of nestage rectangles. But
if you look at the rectangle at the top and then go down the flame
chart, all the rectangles below the first one will be smaller or contained within
its parent. So you think of this as a tree or a parent with
a child, and that child might have more children. And so what this
lets you do is it lets you look at the top row, which might
say long task, and it might say it was a second long. Then
as you take that and you look vertically down the flame chart, you're going
to see all the functions and code that ran within that long task that added
up to make its total duration. The reason this is so helpful is you
might have a long task that's the second long. If you look one level
deeper in its children, you might see that one of its children took point
zero one of a second, so that's really not useful. The other child
took you know, zero point nine nine of the second. And so what
that lets you do is it lets you see, okay, there was a
long task, you could look down to see the culprits or the causes of
that long task, could really dive in to the weeds of it. And
just to add and potentially it helps clarify. Think about the function A that
calls function beat twice, so you'll have a wider rag tangle four it A
and contain with it. One level down would be two rectangles for the you
know, consecutive rectangles for the separate calls to be. And in this in
this context is useful to remember that JavaScript is essentially a single threaded language.
You know, we have workers, but they are effectively run independently of each
other, so it's always contained within as it were, Yeah, correct,
Yeah, And that you know, long task can be caused by one or
two things, broadly, either one function that took an absolute age to run
or one function that doesn't take very long to run but got called you know,
a million times, And so that the flame show lets you figure out
which one of those two it was. Obviously, the resolution or the way
you fix that is different. You know. Generally, it all boils down
to can we do less work? Can we run less less lines of code?
But sometimes it can also be highlighting where you might have a function that
you think you don't need to optimize because it it isn't very complicated, But
if it's been called loads and loads of times, then it may well need
to be have a bit more attention given to it. Now it's called a
flame chart, I guess because of the shape. But it's also called a
flame chart I think because of the colors, which are often yellow, red,
purplation, et cetera. Ye, that color coding. How does it
work? What's kind of the logic behind which color which each direct angle gets?
Dan, you're really pushing my memory of all these details. That's what
I'm here for. So yeah, yellow, if I rightly, is scripting,
and most of the time the ones that particularly interesting is purple. Is
like browser layout type events. This might be recalculate styles event, which is
where something happened which made the browser have to a bunch of work to check
that it's latest layout of the page is accurate. The kind of the most
common got you with those is if you call method like get bounding client wrecked
on an element or if you read an element's Paul Irish has got a great
get hub page with all the different ways you can trigger this, but there's
if you read an elements with or height or scroll top and various things.
The browser before it gives you that value back has to make sure that what
it thinks the layout is is what the layout is, so it will do
some extra work to kind of verify that. And so what you want to
do is minimize how often that happens, because that can be quite expensive on
a complicated page. So that's purple. I'd like to tell a short story
about that. So a while back, a friend of mine contacted me about
the problem that they were having within the application. It happened to be within
Angular, but it's neither here or there in that regard, which was taking
a very long time to render it in its primary view. And when I
talked to them and we looked at at the flame chart, it became very
pretty obvious that it was laying out a whole lot of time. Effectively,
it had layout thrashing. And because the way that this application, the UI
was structured, it was structured as a lot of rectangles, and they built
those rectangles in a way that certain amount of texts and images needed to fit
nicely within them. And now instead of using CSS to kind of properly factor
those sizes, they actually used Java initially used JavaScript for it. So they
would, you know, put the content in a rectangle, get the dimensions
for the rectangle, fixed the content, and then do it for the next
rectangle, then do it for the next rectangle. So effectively, each rectangle
required a relayout, so they were changing some position and with aspects and then
querying the and high aspects. So for every rectangle, relayout, and there
were hundreds of such rectangles on the page. And that's what's known as layout
thrashing, which you're when you're forcing the browser to relayout multiple times in or
to just to render that initial one view. And basically what I told them
is one of two things that the less ideal solution would be to put to
have instead of one loop doing putting in the content, then getting the layout
information, putting in more content getting layout information, do it is two separate
loops, like you know, even three loops, do all the positioning,
get all the layouts, and then do all the fixes. And that actually
turns out to be faster, even though it's potentially counterintuitive because the browser can
do the just the one layout instead of the layouts rushing, I just discret
or even better, just do it in CSS. Let the CSS do it
for you, and then you don't need to do all those layout in at
all. And that's what they ended up doing, and they and it became
from like a thirty second load to being literally like a second, So it
was like a huge win in terms of performance. And that's definitely something that
you can see in dev tools, and I think these times now you can
even see it better because I think you even provide some attribution to the relayouts
that occur. Yeah, we can't detect every single instance, but if we
can, we will draw arrows in the flame chart which will take you from
one event that caused another event, so we can often attribute why a layout
happened. Or simply say your Rome code that has a set time out in
when the function within the set time out gets cooled and you find that on
the flame shot will draw an arrow back to the code that ran the set
time out, so you can see kind of why things happen. I think
there's a lot more we could do there, but yeah, we do try
and draw the arrows to give you some some idea if you can. Yeah,
A big theme when you look at the main flame chart and you see
lots of stuff going on, is is to ask firstly, you know,
I've talked about can you spot functions that you can optimize or reduce how long
they take to run? But it's also do you even need to run that
code of tool? I think there are plenty of cases like the one you
just described where actually, especially now if you're targeting modern browsers, CSS has
got a lot more powerful, particularly around layout, and I think there are
a lot of cases where you can actually get rid of jibscript to lean on
lean on CSS a bunch more. If you can optimize a function, great,
If you don't ever need to run it, that's even better. I'm
kind of curious as people come into this and they start, you know,
because we've kind of talked about some of the specific things that are in the
performance tools. But I'm kind of thinking through my head, Okay, what's
the scenario right where somebody's gonna you know, and maybe people are regularly checking
this as they build their apps, but I'm also thinking, you know,
maybe somebody is looking at things and realizes that they have poor scoring on some
of their core web vitles. Right, So what what scenarios are you looking
at? Is it one of those? Is it something else where you're finding
that people are typically reaching for this particular panel and the Chrome dev tools,
and then what how do you how do you pull the information out and know
what to do with it? Because it's it's one thing to say, Okay,
all this information is in there, and I think we've covered a lot
of that, but you know, okay, I've got this information. Now
how do I know that it yeah, it's layout thrashing, or how do
I know that it's you know, something else, or you know, maybe
it's something really simple and it's just you know, I I load in an
image and my whole paid shifts and it takes a long time for it to
grab it and pull it out. So you know it's it's uh, you
know it's impacting two or three scores. Yes. I think most common use
case is people who run their website through a Lighthouse report and see that something
is scoring badly, or it will be people who are getting reports from their
users that their website is loading slowly. That was often the motivation of my
previous job was it would normally be a member of staff was on a really
rubbish connection and would moan that there's the site loaded very poorly. So I
think that's mostly how we expect people to come into the tool is some issue
and obviously core where vitals can impact search rankings. That tends to be the
motivating factor for the majority of businesses who want to invest in this area.
Yeah, in terms of understanding the information, that's really what the experimental Performance
Insights panel that was one of the goals of that. So when you use
that panel, you get a right hand sidebar that shows I think we call
them insights, and it will highlight things that were particularly problematic. Now,
we didn't do a good job of prioritizing those and helping people understand which one
the most important, and that's something we need to improve as we kind of
bring that functionality into the performance panel. But it would highlight problems. So,
for example, a network request that is render blocking, as in until
the browser is finished with that request, it can't continue laying out the page.
We would highlight that as an issue because if you can resolve that,
the browser can can get rendering earlier and therefore your page will appear loaded to
the user much more quickly. I think really a theme for us this year
is trying to have actionable kind of insights that we can provide people to give
them a helping hand to figure out what was going on. I think a
key aspect and probably the biggest challenge around improving performance is attribution, understanding the
root cause for why something behaves the way that it does. Like, Okay,
this page is loading, or this block, you know, the like
the page is unresponsive. Why is it unresponsible? What's actually running that's causing
it to be unresponsive? What what is the browser that's why? Yeah,
exactly, And and I think and and it's a it's a it's a it's
a it's a challenge. It's it's not easy to figure out the attribution.
And you know, I'm I'm on the web perform at the W three C
Web Performance Working Group, and and a lot of the discussions are about how
to try to figure out like the reasons the browser does what it does and
then externalize this information and also how to do it in a way that in
itself is performance and also doesn't you know, become a security or a privacy
issue. So there's a lot of problems around that, but part of it
is that the browser is a sophisticated system and and consequently understanding attribution is not
a trivial problem. You need to have a certain amount of understanding of how
this thing works so you can make it just so simple, but probably not
simpler now as you might expect. I'm also I also have the performance panel
open well while we're talking, and I just noticed something that I've never seen
before. So I'm going to take the opportunity and ask you jack about it
now. I noticed that when I'm floating over the various the strips or the
tracks as you call them, they now show like this, like a pencil
at the left side that I can click on, and then I get this
weird view with eyes and check marks. What is that? Yeah? So
this you I will change in the next release of Chrome, which must be
out very soon. But this was or is a UI to enable people to
reorder and hide and show particular tracks. So can you record a performance trace
that you get a bunch of these tracks, and obviously that some of them
are really like network is obviously an important one. The main thread activity is
important, but you will get others, for say, GPU activity, rasterization,
any workers that were on the page, and so on and so forth.
Depending on your use case, those may or may not be useful to
you. And when the challenges of the performance panel is embedded within dev tools,
which not most people. Most people don't have Devdel's open full screen because
it's within Chrome, so vertical space is tends to be at a bit of
a premium for us. So this is kind of we've been playing around with
how can we enable people to hide and show information? But yeah, we're
not I'm not thrilled with the UI that landed. Will change. It was
kind of a first part of it, and we've tweaked a bunch of stuff
for Chrome one two six which should be out soon. So for example,
so for example, if you know, there's the animations track, so you're
yeh say saying if they don't actually have animations on the page, or I'm
not currently testing the performance of animations, maybe I'd like to hide it just
to save some vertical space. Yeah, yeah, I think what we need
to do is is potentially could we do some of that automatically for you because
also right now, I think if you wanted to hide all the non important
tracks you might have to click ten or fifteen of them to get rid of.
So I wonder there might be a world that we can invert that and
you can tell us the ones you want to keep around. I don't quite
know, but yeah, what you're seeing is are sort of first steps into
the water of allowing I think users to customize the timeline they see better to
suit their particular use case. Because depending on the context that you're what the
problem is you're trying to debug, there are certain things you may or may
not care about, and we can't always know that for sure. That we're
trying to get better at figuring out what you're trying to debug and show you
the right level of information. But kind of going back to what we're doing
about around attribution, Yeah, that is the challenge and what we're trying to
figure out is there are sometimes where we can very confidently attribute a particular issue
to a particular root cause. So, for example, layout shifts. A
very common root cause of that is we load an image into the page,
but the developer didn't set the width and height explicitly on the image. The
browser kind of guesses or reserves a certain amount of size. Then when the
image loads in, it now knows the correct size for the image and it
resizes it down, which can cause the pace to shift. So we can
quite often very easily point to that, but other ones we're sometimes sort of
guessing. We're trying to figure out how we can say to users, this
might be a problem that you should look at, but it also might not,
because we can't be one hundred percent short, and that's a tougher kind
of story to tell and guide people on. Now will we still have a
bit of time left, So we were talking about the top part, which
is the mini map. We were talking about the central part, which actually
contains the flame chart. There's also a bottom part which has the summary bottom
up poultry and event. Can you briefly describe what that section is? Yeah,
I'll try so that the summary trust to show. It will show you
one of two things, depending on what you've selected. If you've selected a
time range in the panel, it will show some stats about how much of
that time range is spent in various activities, how much was spent like the
browser paints or rendering versus scripting effect for your JavaScript or not. If you
select an actual individual event, say a network request, it will show you
some extra information about the particular event you've selected. Then the next three bottom
up, culture and event log. They're all based on trying to get a
better understanding of the JavaScript and the flame chart. So bottom up the idea
there is you get a view of all these sort of events in the flame
chart. You can filter them by name, and you can also sort them
by how long they took and the duration that they took. The idea there
being that it can sometimes be an easier way to dig into where your pagevent
most of its time executing. Tree and event log are similar. Event log
I never use and I don't remember. I think col tree is very similar
to bottom up. Whereas bottom up starts literally from the bottom and goes upwards,
the bottom up starts with the sort of leaf nodes of the tree.
If you think of the flame chart, it starts with the things at the
bottom that at the most time, I think col tree might go the other
way, but yes, I'd have to double check yes it does. The
main benefit of using these is that they because you know, you might say,
why do I need this information? It's kind of a duplication of the
information that they have in the flame chart itself. The main benefit aside from
filtering, which you mentioned, is the fact that it's also it also aggregates
because you know the example I gave before where function A calls function B twice.
So in the flame chart you see each instant of the execution of function
B separately, but in the bottom up view, it starts from B and
it aggregates all the time spent inside of B. So, like you mentioned
that a certain function may have a significant impact on the execution on the loading
time of a page. Might be because that function ran once but ran for
a very long time, or maybe it ran really quickly but was involved a
million times. So and the aggregated view, in the case of that function
being involved a million times, will show the total amount of time that was
spent inside that function in all those individual invocations. Yes, yeah, that's
a good additional point. I was looking at this too, because it also
shows I opened it up and just ran it on stream yard, which is
what we're using to record this. And it also showed like the garbage collection
and you know, some of the other system calls as well as well as
like paint and animation, frame fired and things like that. And so if
yeah, it really does give you a drill down right, if you're if
you're doing something that is heavily memory intensive and it's going to trigger garbage collection
on a regular basis, and you know, maybe that's gonna, you know,
affect your performance one way or another, right, because I mean,
you know, I would assume that most apps maybe don't have that problem,
but I've seen people do some weird stuff on the way. Yeah, so
we actually hit that give you all kinds of information. Yeah, we So
because dev tools is a web app, we can debug dev tools using dev
tools, which means we can profile the performance panel's performance by using the performance
panel in and other dev tools, so profile inception. It gets a little
bit confusing, but we the performance panel. So the main sort of UI
all these tracks is drawn via an HML canvas, and so that means every
time they use the scrolls or pans or zooms in or out, we have
to redraw the whole or canvas to represent what they've just done. And so
that is a lot of a lot of function calls happening in a very short
space of time to lay that all out. And we had a situation where
we were passing to function that got called i think for every single event on
the timeline, so potentially hundreds of thousands of times, if not more.
We called the function with an object, you know, so we could destructure
the arguments from that object. Now, every time you do that, that
object that you pass in has to be garbage collected at the end of that
functions life cycle for ninety nine percent of the time. Ninety nine percent.
Developers probably that's never a problem at all, it's not a concern. But
when you call that function a million times in sort of a split second,
that suddenly a million objects and now had to be garbage collected. And so
what we had to do was change that function. So rather than taking an
object with say five different keys and values, we have to pass each of
those individuals as an argument to the function. So it sacrifices in that case
a small amount of readability, but it it massively improve the performance and the
when you're talking about redrawing a canvas, as the user resuming or scrolling,
you notice any slowdown in performance. So that's kind of we have to be
very hot on that sort of thing. There's another lesson here, and that
lesson is that the Performance Panel is an amazing profiling tool, and you should
never start to optimize stuff, especially micro optimizations, before you profile and identify
the problem areas, because you know, like you said, like Jack just
said, like you said, Jack, you sacrifice a little bit of readability.
Well, you shouldn't sacrifice readability unless it makes a measurable positive impact.
You were able to prove that it does and that it's worth that small amount
of readability sacrifice in that particular case. And so yeah, that's support that's
really important to make in that context. By the way, another important point
to make that's kind of related to what you said before that Chuck about whether
or not that kind of activity is a problem in most web applications. You
can also use all these tools, including the Performance Panel, to profile node
based applications. You can attached to note and profile node and node. Let's
say you've got a note service that's long running for example. Let's say it's
not some sort of lambdau or something. It's it's an actual long running node
process that's serving a ton of users. It can definitely have issues around memory
allocations and stuff like that, so it's not just extreme client side situations like
the dep tools itself. You know your average node service that happens to be
servicing you know, ten thousand users. Ye makes sense. I actually used
it specifically a couple of months ago. I made a contribution to the Prometheus
client for Node around just that identifying a problem like it's kind of similar to
what you described Jack of allocating a lot of objects and identifying that it could
be done more efficiently. In that particular case, they were building a huge
string by concatenating strings into it, which in most cases is fine, but
in that case it was literally millions of strings. So using a joint instead
turned out to be significantly more performant in that particular example. Yeah, we've
had loads of insiness. There's a blog post on the Developer Tools blogs we
recently. We recently did a big under a rewrite of sort some of the
internals of the performance panel. Then we were profiling it, and I think
there was We have some test kind of traces that we can load into the
performance panel that are absolutely massive, like far bigger than anyone's average website would
generate. And for one of those, I think we were able to get
the time the performance panel took to process and load that trace I think down
from something like twelve seconds to two seconds just by recording with the performance panel
and then going through and looking for these problem areas. But you know,
we couldn't have done that optimization without looking at the performance panel because obviously we'd
written all the code that caused it to be slow, and in none of
you wouldn't look at any of those changes and think, oh, that's going
to be a problem here. That is going to be slow for us.
Sometimes you can, but most of the time you do need to wait and
actually profile it. You know, around it's always wrong. It's always wrong.
Yeah, And that passing objects into functions and rewriting those as arguments.
We don't follow that everywhere in the panel because it's only a problem in the
code that redraws the canvas, because that is our real hot path needs to
be as optimized as we can, and we may have to sacrifice readability in
order to do that. But in say the summary bit at the bottom that
shows you information that doesn't rerender every time of the user scrolls, So in
that panel, for in that part of the code, we probably would still
pass an object in because we know that that's not going to be a path
that's going to cause us problems. So yeah, the advice to always profile
and not prematurely optimizes is very accurate because it will always surprise you. And
browsers are smart. Sometimes they can optimize things that you might think would be
slow because they recognize what you're doing. Sometimes something that intuitively you think won't
be slow will be slow for some very niche reason. So yeah, it's
very important and to use the tools available to figure that out before you go
diving in. So we're kind of at the end of our time. Are
there places where people can go and dive deeper into this stuff? Uh?
Yeah, so, I mean the performance panel is very heavily documented in the
devtol's documentation online. In terms of what we're sort of planning, there's some
blog posts on the Chrome for Developers blog that have more information on this,
which I can kind of send links to all the things that I think are
useful. That's probably the best place to start in terms of sort of keeping
up to date with what's new in dev tools. I think following the Chrome
develop a YouTube account or Twitter and all that stuff is probably best. At
the Jesslyn, who's the Devtel's DevRel does. Yeah, she's amazing. She
does regular videos and will highlight new features across the panel, including in any
of the performance tooling. So that's by the way. The What's News section,
which is inside dev toels itself, it's in the drawer part, actually
contains the video showing what's new for the latest version, and from there you
can get to the what's new for previous versions as well, So it's you
can it's really worthwhile to review these videos. They're short, they're sweet,
they're very informative. Highly recommended. Awesome, agreed. There is one thing
before we let you go, before we finish this episode. There's one request
which I think I submitted like years ago via your feature request mechanism, and
that's the ability. So what you can already inside the performance panel record have
multiple recordings and like flip between them. What I'm really missing is the ability
to compare recordings. So for example, if I made a change and I
think it impacts and it seems to impacted performance, I would love to have
like subtract one view from the other and only see the differences. That would
be awesome. Yeah, you're not the first person to bench that and that's
certainly floating around the backlog. I think it's something we It's hard because if
you record to you know, if you have the same website and you recorded
too traces without changing anything due to the variability of the Internet and computers and
whatever else your computer was doing at the time, those traces are going to
be slightly different. So I think the challenge there is figuring out how do
we represent what changed and try to figure out what changed just because variability and
what changed because you did something. So I think we can see the appeal
and the reason it would be very useful. The practical the practicalities of implenting
it is potentially slightly challenging, along with how we manage the real estate on
the screen if you want to compare these two traces and the panels already crammed
full of stuff as it is. But yeah, it's floating around as an
idea we want to explore. For sure. If it were easy, then
everybody would be doing it. I will mention that the awesome webpage test now
has an interesting ability to compare two recordings, which is which is also not
perfect, but it is pretty good. I was just going to say,
if you estimate it in your estimation meetings as a medium, and then you
come back after you start working at it and go, actually, this is
an extra large I didn't realize. Then maybe we'll get it sooner. In
other words, lie, I'll give it a guy. Yeah, all right,
Well, let's go ahead and do some picks and wrap this up.
Now, let's get the dad jokes going first, Steve, do you have
some picks for us? Well, I can look at that one of two
ways. It's either let's hurry up and get them out of the way,
or let's get I did not that. I did not say that for the
best part first, So I'll uh, I didn't say that either. I'll
cut you a little slack there on that one. Check Jack, this is
always the high point of any of our episodes, according to statistics and comment
forms. But sorry, I got to license statistics. Huh live right,
Uh, Just I gotta get my branding thing here. Okay. So the
other day, my son, who's uh, I won't say how old,
they had a bunch of coins, and so I had to take him to
er and after about an hour I asked the doctor. I said, how's
he doing? He said, no change yet, almost every feet there,
I go, okay, so just that funny. I decided that I'm going
to make some money off my dad jokes. You know, since I've been
doing it for free so long, I have to write them all every day.
It's a lot of stress. So I'm going to put out a cologne
for men who like dad jokes. I'm going to call it pungent. That's
nice right now, This one requires a little bit of thinking, but I
like I'm you know, I'm the dad jokes for the smart person. So
my nerdy friend, uh just got a PhD in the history of palindromes.
Now palindromes, for those who might know off the top of your head,
there's words that are spelled forward and backwards. They're the same when you're doing
forward and backwards. Now we call him doctor awkward. Yeah, you need
to see it to get it. But it's it's great, right, very
good. So those are my dad jokes for the week. All right,
Dan, what are your picks? Okay? I to be honest, I
don't have that much in the way of picks. So the only the real
pick I have is that I was interviewed on another podcast. I was a
guest on the Contagious Code podcast that the tageous friend of our show. He's
doing his own podcasting has had some awesome guests like you know, Gier Morauch
and others. I highly you know if you like tech podcasts. I mean
you're here so you probably do. That's another one to look to look into.
So I was a guest I will. We recorded, and actually a
pretty lengthy one. I think it was over an hour and a half because
we really got into my tech history and my tech journey and you know,
things that I've done and how I got into the whole performance thing, and
well, I've had the long career as you can probably tell by looking at
me. For those of you are actually watching the video, by the way,
Ah, yes I am for sure. So that's that's one pick.
The other pick is my new employer, I sense. I've been there for
about a week and a half. They welcomed me wonderfully. I'm enjoying myself.
A funny thing though, So I was getting into the code base after
like and I thought, you know, after just three days being there,
and I thought, you know, what could be a better way than to
do a small full request on the code. So I started looking at something
to fix, ended up changing twenty files and what some people defined as core
functionality of the product. But you know, it got accepted, it got
merged, so you know you're going to go go big. Yeah, I
did something right. Whenever I try that, it always crashes, you know,
but at the very least you get noticed. And my final kind of
an anti anti pick is that I watched the movie Atlas on on Netflix,
and the only good thing I can say about it is that it that it's
more watchable than Rebel Moon. What is Atlas about? What? It's a
sci fi movie with Jennifer Lopez. It's no, she actually she's actually fine.
Uh, It's it's the story that's kind of stupid, but you know,
and the action, the final boss fight is not much of a fight
in my opinion, and you know, so it's it's kind of met uh,
which, like I said, meh, is much much better than Rebel
Moon. I could not finish watching the first one, so obviously I didn't
even try watching the second one. All right, Yeah, anyway, those
are my picks. Good deal. I'm gonna throw out a board game pick
here real quick. Of course, I should have thought ahead and thought,
what I want to pick. I think I'm gonna do another legendary expansion.
So one of the ones that I've really enjoyed playing is the Shield expansion,
and I think a lot of it was based around if you watch the Legend
of Shield or not the Legend of Shield the anyway, it was a TV
show that that was the Shield Agents of Shield TV show a thing. Yeah,
it pulled in a lot of stuff there. One of the one of
the optional things that you can do is you can buy a Shield Agent as
part of your you know, one of your actions if you have enough to
recruit them. And this one gives you basically you you have special characters and
they're the characters from the TV show. But anyway, it's a fun expansion
to play with. Nick Fury is in the main set of heroes that you
can play with from the main game. And so I'm trying to find it
on board game geek. Give me a second here, Oh, here we
go. So board game weight on this one is two point seventy five.
I think the base games like two point three five, so you know,
it makes a little more complicated, but it's not terribly complicated, and it's
it's a fun expansion to play with. And so yeah, anyway, I'm
gonna pick that, and then I have a couple of other picks. One
of them is sitting on my desk. My eight year old made me a
card and so it says, I love you Dad, and uh, anyhow
I walked in this morning, it was sitting on my desk. So don't
you just love it when they're still young and do things like that for you?
Right? My seventeen year old's like, what you want something? Right,
So try me to work. So anyway, but yeah, so that
that makes me smile for sure. And then yeah, I mean, I've
been pretty involved in the political political scene here in Utah, and I just
want to encourage folks if you're you know, if you're out there and you
care about what's going on in your society. I'm getting ready to launch a
podcast about this stuff. But I really feel like a lot of the things
that make the difference in the long term are what you're doing at home and
then what you're doing in local politics. A lot of the folks that are
running for Congress or Senate here in Utah or governor, they all kind of
came out of local politics, and then you know, kind of moved up
a level and then another level, right, And so if you're not happy
with your politicians, a lot of these folks kind of start at a smaller
level and move their way up. And so you've got to support the right
people at the at the local level, because many of them will wind up
being your people at the at the higher or more more broad levels, I
guess, or I don't want to say higher levels, because in a lot
of ways, the further away from you they are, the less impact they
have. It depends on the issue, obviously, but you know, you
see the dysfunction at the at the federal level here at the in the US,
right, and you're just like, you know, these knuckleheads that you
know wind up in Congress, and some of them really good and some of
them really not. You know, they came up the same way, right,
And so go support your local folks that believe what you believe and value
the things you value. I do have a comment about this, if I
may. Yeah, first of all, I totally agree with everything you said,
and I think you know, being involved and you know, doing things
for causes that are important to you is definitely a good thing. But there
is a certain responsibility I would say that goes with it, that you you
do need to kind of do a bit of research and do some thinking and
some analysis and verify that the causes that you support are actually, you know,
correct and proper and righteous causes and that you're not just buying into some
demagogery because you know it seems cool or or you know it's the thing doujour
or whatever that you actually you know that you properly make up your mind and
not just go based on you know, what somebody has said. That's you
know, make it whichever way you think is best, and you know,
according to your own principles. But do the do the thinking, do the
research. I absolutely agree. Here in Utah we have a caucus convention system
and the you know, so you have the local caucuses, you elect delegates.
The delegates go and do a lot of that kind of a thing.
But that doesn't mean you can't be involved if you're not a delegate. But
yeah, you should be doing the same kinds of research and the same kinds
of having the same kinds of conversation with these folks as the delegates and being
okay, you know, this is an issue. Where are you want it?
You know, this is a principle that I hold to. How do
you feel about it? And then talk to other people and you know,
inform yourself. Okay, they said this thing, Now do they actually does
it actually bear out in the way that they've voted or you know, done
their job as a you know, representative in your local government. But yeah,
I entirely agree. And you know, the longer you do it,
the more you I guess it better at sniffing out who really is where you
want to be and where or not. But there are also terrific organizations and
it's the same kind of thing. Whereas Dan said, you know, sometimes
you get somebody that's, you know, the person at the top of the
organization. It turns out that they were on an ego trip, right,
and so they got a bunch of people that believe like you believe, to
back them up. And then it turns out that there's some issue. You
know, there's something rotten at the core of it. And it's not because
your principles were wrong. It was because you backed the wrong person or because
you know, there was no way of knowing that this person was a problem
and so yeah, you definitely have to do your homework because you want to
get in and push where it's going to make a difference and make sure that
you're backing these things. And I don't bat a thousand on this stuff,
right. I don't always get it right, but you know, more often
than not these days, I'm able to figure out, oh, you know,
there's something here that's making me uncomfortable, and sometimes it's just a gut
fee and so I'll put my effort elsewhere because yeah, and then it turns
out that a lot of times that gut feel is right. Anyway, I'm
starting a podcast to this effect. It's it's probably going to be focused mostly
on the US. That doesn't mean that it can't apply to other countries,
but it's it's going to be called America's Destiny, and it's essentially, yeah,
it's this idea. It's like, okay, well, you know,
as these issues come up, how do you address them at home, you
know, with your kids, and then how do you address them with your
neighbors? And then you know, how do you get involved and understand how
these things are going to affect you at the local level, and then how
do you kind of find and reason through. Okay, this is a good
person to support at the local level, and then how do I encourage them
when the right time comes along to go and make a larger impact in a
you know, in a different arena. So anyway, and I get myself
in trouble sometimes for speaking up, but that's the way that that goes sometimes.
So anyway, those are my picks, Jack, what are your picks?
Yeah, I'll throw in a couple quickly. To briefly pull us back
to the performance panel. We ship something in Chrome recently called selector stats,
which for recalculate stars event lets you dive into where that time was spent the
CSS selectors causing it. The reason I want to shout this out is because
we didn't build it. It was built by the Microsoft folks who work on
the Edge Dev Tools team, but they upstreamed it into Chromium until now it's
available to Chrome and as users, which I think is just really nice that
you two big companies able to collaborate and both share kind of features. So
I thought that was really nice. I'll follow the board game theme as well,
a laatest addition to our ball game collection. It is a co op
game called Sky Team, which is I think fairly new. I think I
found it VI a YouTube channel that does board game reviews. It's a corruptive
two player game where you're piloting a plane and you have to roll dice to
make strategical decision to land the plane successfully. But what's really quite cool about
it is once you've rolled these dice, which you then have to use in
certain slots on the board to achieve things, you and your person you're collaborating
with you're not allowed to talk to each other and the dice are hidden,
so you've rolled four dice with certain numbers. Your other players rolled four dice
and have got four numbers, and in silence, you have to decide,
one at a time where to put these dice to achieve things. But you
know, it's classic. If you put two dice here that sum up to
a number greater than ten, that's bad. But if you put two dice
here that sum up less than three, that's also bad. So you're it's
kind of fun collaborating, but also with a bit of silence, it's enjoyable
and normally ends up with you looking at each other at aghast with horror as
your partner puts the wrong dice in the wrong box, which you never would
have done. That's been fun. So yeah, it's called the Sky Team.
Yeah. It reminds me a little bit of some of the other sort
of blind collaboration games like Hanabi, which is where you have your cards facing
out to everybody else can see what cards you have, but you're the one
that has to play, and so you're giving hints. You know, you
have some means of communication, but not a ton. So I just looked
it up on board game Geek. It has a weight of two point h
two and I keep telling people that's kind of your average casual gamer that with
the game that has enough complexity to make it fun and interesting. It says
it runs in about fifteen minutes. Does that sound about right? Yeah?
I think it's the first one took a bit longer as we figured out,
right, Yeah, it's pretty stappy, which we have a new child in
the house, so fifteen twenty minutes is about the max time we get to
play a game, so yeah, that's about right. Yeah, and then
it's rated for kids age twelve plus. The community says that ten plus can
play it, so you know, this is something that. You know,
maybe I coach my eight year old on a little bit, but my other
kid could probably play fine. I'm very into board games. I really enjoy
them, So thanks for that. I'll check it out, No worries,
all right, Jack. If people want to find you on the internet,
where do they find you? Uh? Yeah, so Twitter is Jack underscore
Franklin on that It's Jackfranklin dot co dot uk for links to various other websites
and blog posts and all that kind of stuff. Awesome, all right,
well up here, Yeah, thanks for coming. Until next time, folks,
mats out.