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.