WEBVTT 1 00:00:05.240 --> 00:00:11.480 Hello everybody, and welcome to another exciting episode of JavaScript Jabber. Today, 2 00:00:11.679 --> 00:00:14.599 I'm all on my lonesome Dan Shapier coming to you 3 00:00:14.640 --> 00:00:18.239 from Tel Aviv in Israel, and I'll be interviewing Aidan 4 00:00:18.320 --> 00:00:24.039 by Hi. Aidan, Hi, how are you? I'm doing well overall? 5 00:00:24.239 --> 00:00:26.800 How about yourself doing well? 6 00:00:27.519 --> 00:00:30.679 It's a not so hot, not too cold day in 7 00:00:30.719 --> 00:00:31.960 San Francisco. 8 00:00:31.519 --> 00:00:36.719 So that's lovely. It's kind of same over here in 9 00:00:36.759 --> 00:00:41.880 Tel Aviv, so please we're sharing good weather, and we 10 00:00:41.960 --> 00:00:46.560 are here today to talk about React performance. But before 11 00:00:46.600 --> 00:00:48.880 we start, Aidan, maybe you can tell us a little 12 00:00:48.920 --> 00:00:52.159 bit about yourself and your very lengthy career in tech. 13 00:00:53.399 --> 00:00:57.479 Yeah. I gotta started hooting in middle school. But like 14 00:00:57.560 --> 00:01:01.679 you might know me for a million, Jess, it's like 15 00:01:01.759 --> 00:01:04.840 I tried to make a compiler for React and then 16 00:01:05.400 --> 00:01:08.200 more recently React scan, which is all like the purple 17 00:01:08.280 --> 00:01:11.040 flashing boxes on all these popular websites. I U see 18 00:01:11.040 --> 00:01:16.680 it on Twitter. I've mainly mainly focused on performance most 19 00:01:16.719 --> 00:01:19.359 of my life because I think it's an interesting problem. 20 00:01:20.159 --> 00:01:22.680 Not many people focus on it, and it's also very hard. 21 00:01:23.400 --> 00:01:26.920 Yeah, tell me about it. It's been one of my 22 00:01:27.079 --> 00:01:31.040 main focuses for the last couple of years. For those 23 00:01:31.079 --> 00:01:33.079 of you don't know, I also happen to be an 24 00:01:33.120 --> 00:01:36.400 invited expert on the W three C where Performance working Group. 25 00:01:36.439 --> 00:01:39.519 Maybe you should join us there as well. We talk 26 00:01:39.560 --> 00:01:42.840 about things not so much related to React, more about 27 00:01:43.200 --> 00:01:46.519 the relevant web standards, things like core vitals and stuff 28 00:01:46.560 --> 00:01:48.840 like that, and the APIs in the browser that can 29 00:01:48.879 --> 00:01:51.680 be used to retrieve them, to measure them, et cetera. 30 00:01:53.319 --> 00:01:55.319 I know that it's not our topic, but I do 31 00:01:55.439 --> 00:01:57.959 want to talk a little bit about million js because 32 00:01:58.000 --> 00:02:02.439 it seems so interesting. So so as I recall it, 33 00:02:02.439 --> 00:02:07.120 it's kind of a drop in replacement for the mechanism 34 00:02:07.200 --> 00:02:12.680 in React that transforms the virtual dome into the actual dome. 35 00:02:12.919 --> 00:02:15.520 Is that a more or less correct description. 36 00:02:16.080 --> 00:02:19.759 Yeah, that's correct. Like basically how React works under the 37 00:02:19.800 --> 00:02:23.759 hood is it takes like two versions of the view, 38 00:02:23.800 --> 00:02:26.039 so like the old version and the new version, and 39 00:02:26.080 --> 00:02:28.240 then it reconciles it, like it figures out the differences 40 00:02:28.240 --> 00:02:30.879 between those and then it applied it to the actual dome. 41 00:02:31.800 --> 00:02:35.719 But like this is like an an operation or some large, 42 00:02:35.960 --> 00:02:41.159 big old notation that's over one. And the problem with 43 00:02:41.199 --> 00:02:46.199 that is if when the versions get really big, like 44 00:02:46.280 --> 00:02:48.840 the trees get really big, you're doing a lot of computation. 45 00:02:49.800 --> 00:02:51.439 So I was like, okay, wouldn't be cool if you 46 00:02:51.439 --> 00:02:54.520 could pre compile this, Like okay, based on the JSX 47 00:02:54.599 --> 00:02:58.800 you provide. There's like obvious points where it actually changes, 48 00:02:59.039 --> 00:03:02.080 like when you have those JSX container expressions, like the 49 00:03:02.680 --> 00:03:05.879 when you passing some data in, So I pre compile 50 00:03:05.960 --> 00:03:09.199 that and then found like the specific code paths that 51 00:03:09.240 --> 00:03:12.159 matter to make the dom changes. So every time you 52 00:03:12.199 --> 00:03:15.360 render a component, instead of doing that whole reconciliation process, 53 00:03:15.719 --> 00:03:20.479 it just changes the dom like like pinpoint processes, basically. 54 00:03:21.360 --> 00:03:26.000 Kind of implementing fine grain reactivity in a sense over 55 00:03:26.159 --> 00:03:27.159 on top of React. 56 00:03:27.280 --> 00:03:30.719 I guess, yeah, like benef it's a fine grain reactivity, 57 00:03:30.719 --> 00:03:32.560 but without using fine grain reactivity. 58 00:03:33.800 --> 00:03:38.479 Yeah. I think you kind of mentioned several things that 59 00:03:38.520 --> 00:03:41.919 are kind of important in the context of React performance 60 00:03:42.000 --> 00:03:45.280 as you were describing this. I think that first and 61 00:03:45.360 --> 00:03:50.520 foremost is this whole thing about virtual dom and the reconciliation. 62 00:03:52.080 --> 00:03:56.120 We actually had a couple of chapters in JavaScript jabber 63 00:03:56.240 --> 00:03:59.840 talking about the virtual dom, what it is, why it exists, 64 00:04:00.000 --> 00:04:03.280 et cetera. But I still think it might be worthwhile 65 00:04:03.319 --> 00:04:05.680 to talk a little bit about what it is because 66 00:04:05.719 --> 00:04:08.439 it's so central to everything we'll be talking about today. 67 00:04:08.960 --> 00:04:10.800 So can you tell us a little bit about you 68 00:04:10.919 --> 00:04:13.400 the virtual dorm from your perspective. 69 00:04:14.439 --> 00:04:20.480 Yeah, virtual dom is basically it's kind of an overloaded term. 70 00:04:21.000 --> 00:04:24.600 It's basically taking two like versions of the UI and 71 00:04:24.600 --> 00:04:28.079 figuring out the princess between them and then actually changing 72 00:04:28.120 --> 00:04:32.439 the UI. React doesn't actually hold the dom tree inside 73 00:04:32.439 --> 00:04:34.079 of itself. I mean it kind of does, but like 74 00:04:34.600 --> 00:04:36.959 when it does when it figures out what to change, 75 00:04:36.959 --> 00:04:40.079 it doesn't actually store the dominodes as the whole tree 76 00:04:40.120 --> 00:04:42.240 and then dip the dominance. It difts like a virtual 77 00:04:42.319 --> 00:04:46.680 version of it. This can lead to some problems. So 78 00:04:47.000 --> 00:04:49.959 for example, like for Facebook, it might be somewhat okay, 79 00:04:50.360 --> 00:04:54.600 like when you were switching pages, but like if you 80 00:04:54.720 --> 00:04:57.800 are creating like a stock trading app, like a stock 81 00:04:57.839 --> 00:05:02.480 treating dashboard, where like there needs to be like updates 82 00:05:02.519 --> 00:05:06.160 every several like some amount of milliseconds, or you're making 83 00:05:06.199 --> 00:05:11.160 like significant dom mutations every single second, or if your 84 00:05:11.240 --> 00:05:15.439 website targets it targets like very low end devices, then 85 00:05:15.639 --> 00:05:20.160 that sort of mechanism can lead to some performance problems. 86 00:05:20.480 --> 00:05:25.160 I think the key aspect here is that React took 87 00:05:25.279 --> 00:05:28.759 what I considered to be kind of an idealized approach 88 00:05:29.360 --> 00:05:34.959 to UI generation, which is, let's in an ideal world, 89 00:05:35.000 --> 00:05:39.120 I would say react. The React approach is, let's take 90 00:05:39.160 --> 00:05:44.399 the entire application state and apply like a function to it, 91 00:05:45.120 --> 00:05:50.519 a pure function even that generates the UI that the 92 00:05:50.639 --> 00:05:56.360 user sees, and that every change in the state would 93 00:05:57.240 --> 00:06:02.480 ideally again regenerate the entire UI. So you know, you 94 00:06:03.199 --> 00:06:06.079 check or uncheck a small checkbox in the UI, and 95 00:06:06.279 --> 00:06:10.639 theoretically the entire user interface of the application gets re 96 00:06:10.639 --> 00:06:14.560 rendered because then you don't need to think about state 97 00:06:14.680 --> 00:06:18.439 changes in the user interface. It's just everything again and 98 00:06:18.480 --> 00:06:22.959 again from scratch. But the problem with this approach is 99 00:06:23.279 --> 00:06:29.120 that a naive implementation would obviously be just way too slow. 100 00:06:30.399 --> 00:06:33.399 It's kind of taking, by the way, the approach that 101 00:06:33.480 --> 00:06:36.800 we had in the old days of the multipage applications 102 00:06:37.360 --> 00:06:41.319 and kind of applying it to the client side rendering 103 00:06:41.360 --> 00:06:45.800 mechanism that we have in JavaScript code that updates the 104 00:06:45.879 --> 00:06:49.759 don in that in the old days you would go 105 00:06:49.800 --> 00:06:51.399 to the back end and then you would get the 106 00:06:51.519 --> 00:06:53.639 entire page back each and every time. So it's kind 107 00:06:53.680 --> 00:06:56.199 of like doing that, but again but doing everything on 108 00:06:56.240 --> 00:06:59.920 the client side and doing it for every state logical change. 109 00:07:00.759 --> 00:07:04.879 And the virtual dom was like the first thing that 110 00:07:04.920 --> 00:07:08.560 they implemented in order to make it viable the from 111 00:07:09.000 --> 00:07:11.920 the perspective of performance, that is the virtual dom. By 112 00:07:11.920 --> 00:07:15.000 the way, it's a fancy term, but really really all 113 00:07:15.040 --> 00:07:20.000 it means is JavaScript objects. Really, that's all the virtual 114 00:07:20.000 --> 00:07:24.560 dom is. So instead of having actual dom elements, which 115 00:07:24.600 --> 00:07:28.639 are rather heavy because of all the functionality that they encapsulate, 116 00:07:28.759 --> 00:07:34.160 you just use JavaScript objects simple JavaScript objects as stand ins. 117 00:07:34.199 --> 00:07:37.279 And like you said, when the state changes and the 118 00:07:37.319 --> 00:07:41.120 new virtual dom is created, React then takes the new 119 00:07:41.199 --> 00:07:46.439 virtual dome the old virtual dome, does a comparison, finds 120 00:07:46.439 --> 00:07:52.519 the differences, and then calculates the minimal amount of actual 121 00:07:52.600 --> 00:07:55.680 dom changes to transition from the first state to the 122 00:07:55.720 --> 00:07:59.839 second state. And that's the reconciliation process. And for a 123 00:08:00.079 --> 00:08:03.040 long time it was thought that it was that approach 124 00:08:03.160 --> 00:08:06.000 was good enough in terms of performance. But like you said, 125 00:08:06.639 --> 00:08:11.800 when user interfaces started becoming more complex, complicated or more complex, 126 00:08:12.600 --> 00:08:17.800 and as we needed to support lower end devices like 127 00:08:18.040 --> 00:08:22.879 more mobile devices for example, and as we needed more 128 00:08:22.920 --> 00:08:27.360 frequent updates, even this type of optimization started to break 129 00:08:27.399 --> 00:08:35.840 down because doing all this reconciliation work still has overhead, 130 00:08:35.879 --> 00:08:38.720 and this is when million js, I guess came in 131 00:08:38.759 --> 00:08:41.399 to start to try to reduce that. But like you said, 132 00:08:42.240 --> 00:08:46.200 being able to be smart about pinpointing the exact locations 133 00:08:46.200 --> 00:08:49.200 of the differences and not having to do the entire 134 00:08:49.240 --> 00:08:53.879 comparison of the entire virtual dom tree, right, yeah, exactly. 135 00:08:55.080 --> 00:08:58.600 I view like virginal dom is more of in historical context, 136 00:08:58.679 --> 00:09:02.600 like it's more of getting things correct. Like before people 137 00:09:02.679 --> 00:09:05.799 use like Backbone or they roll their own JavaScript libraries 138 00:09:06.399 --> 00:09:10.799 and this would literally results in like like there were 139 00:09:10.840 --> 00:09:14.279 literally so many frameworks like bugs and these frameworks. Virtial 140 00:09:14.320 --> 00:09:17.519 dom is like a very exhaustive approach to the problem. 141 00:09:17.960 --> 00:09:20.679 But it's more likely to get things correct than that. 142 00:09:21.679 --> 00:09:24.799 Yeah, because when you're essentially building the entire UI from 143 00:09:24.879 --> 00:09:28.480 scratch from the current state, you don't have to worry 144 00:09:28.559 --> 00:09:34.840 about an incorrect UI transition or state transition messing up 145 00:09:34.840 --> 00:09:39.960 your display. I think, uh, Facebook had they had this 146 00:09:40.080 --> 00:09:43.559 story about one of the motivations for creating React in 147 00:09:43.559 --> 00:09:48.039 the first place, is that they had a counter in 148 00:09:48.120 --> 00:09:52.120 their user interface about the number of messages that you 149 00:09:52.240 --> 00:09:56.840 had pending or something like that. And any change to 150 00:09:56.960 --> 00:10:01.120 that mechanism was always buggy because they always had to 151 00:10:01.159 --> 00:10:04.120 somehow sync with everything else that was changing on the page, 152 00:10:04.200 --> 00:10:08.799 and because so many things were changing more or less 153 00:10:08.799 --> 00:10:13.360 concurrently in the UI, all of them as synchronous to 154 00:10:13.360 --> 00:10:16.240 each other, they would always get into age cases and 155 00:10:16.279 --> 00:10:19.679 age situations. And being able to just re render the 156 00:10:19.799 --> 00:10:25.039 entire UI from scratch virtually solve that problem very neatly. 157 00:10:26.759 --> 00:10:31.039 But again, so we had a couple of performance issues. 158 00:10:31.320 --> 00:10:33.919 One performance issue is the one that you addressed with 159 00:10:33.919 --> 00:10:37.399 the mini and JS, which is the fact that even 160 00:10:37.519 --> 00:10:44.080 that sophisticated reconciliation could be too slow, especially if the 161 00:10:44.200 --> 00:10:47.399 virtual dome was really large, especially if the device was 162 00:10:47.440 --> 00:10:50.039 low end, and especially if you did it very frequently. 163 00:10:51.080 --> 00:10:54.159 The other problem, I think is that even building the 164 00:10:54.240 --> 00:11:00.159 virtual dome, which is mostly just running your code that 165 00:11:00.320 --> 00:11:06.879 generates the JAX from the state, can be heavy and 166 00:11:07.200 --> 00:11:12.799 performance intensive if done too often, or if if it's 167 00:11:12.919 --> 00:11:16.799 just too complicated. And I think that this is where 168 00:11:17.120 --> 00:11:21.759 reacts can comes in, because it's that's your new project, 169 00:11:21.759 --> 00:11:24.240 the one that we're going to talk about, because it 170 00:11:24.399 --> 00:11:28.960 strives to, if I understand, correctly, minimize the amount of 171 00:11:29.039 --> 00:11:32.519 redundant helps you help you to minimize the amount of 172 00:11:32.559 --> 00:11:35.200 redundant rerenders that you perform. Correct. 173 00:11:36.080 --> 00:11:40.919 Yeah, exactly. I can give a brief introduct. Basically, react 174 00:11:40.919 --> 00:11:43.320 scan is a tool that helps you find like re 175 00:11:43.320 --> 00:11:46.519 rendering performance problems and you react ap today. You can 176 00:11:46.559 --> 00:11:48.200 just drop it in your app as a script tag 177 00:11:48.360 --> 00:11:52.240 and it basically highlights the components that render and potentially 178 00:11:52.279 --> 00:11:57.039 slow down your app. I spent like maybe three years 179 00:11:57.080 --> 00:12:01.639 optimizing websites, everything from like webar you see, like virtual 180 00:12:01.679 --> 00:12:04.720 camera websites to e commerce websites. There's like static sites, 181 00:12:05.919 --> 00:12:09.279 and when I try to debug these performance problems on 182 00:12:09.320 --> 00:12:12.639 these sites, it's really hard. Like it's either like I 183 00:12:12.679 --> 00:12:15.440 do console that time and time end, or I use 184 00:12:15.519 --> 00:12:18.440 Lighthouse scores, which is like at skill level zero to 185 00:12:19.440 --> 00:12:22.559 profiling tools and Chrum dept tools. React to have tools 186 00:12:22.879 --> 00:12:24.879 at like skill level one hundred, and so there's like 187 00:12:25.000 --> 00:12:29.480 nothing in between those those two types of tools. And 188 00:12:29.559 --> 00:12:32.639 this made me really frustrate, right, I Like I spent 189 00:12:32.799 --> 00:12:35.360 so long just trying to understand how these level one 190 00:12:35.480 --> 00:12:39.159 hundred tools work that that I realized that most people 191 00:12:39.320 --> 00:12:42.399 don't have the time or ability to figure it out 192 00:12:44.279 --> 00:12:48.039 exactly so react Skain helps bridge the gap. Today we 193 00:12:48.120 --> 00:12:52.200 do renders, but soon we'll support more stuff. More stuff 194 00:12:52.200 --> 00:12:55.360 in that like I n p cls LCP which are 195 00:12:55.440 --> 00:13:00.480 like the lighthouse Google Lighthouse scores, as well as stuff 196 00:13:00.480 --> 00:13:04.200 like lung tasks. F he has all of this, like 197 00:13:04.559 --> 00:13:08.159 metrics and stuff that take They are decently like, not 198 00:13:09.159 --> 00:13:14.039 like decently hard like recently not easy to measure correctly 199 00:13:14.519 --> 00:13:15.840 and interpret. 200 00:13:15.879 --> 00:13:20.279 Basically, so you threw out a bunch of metrics and then, 201 00:13:20.399 --> 00:13:24.399 as I mentioned, metrics are near and dear to my heart. 202 00:13:24.559 --> 00:13:26.960 They're part of what I do on the W three 203 00:13:26.960 --> 00:13:30.600 C Web Performance Working Group, which I'm an invited expert on. 204 00:13:33.559 --> 00:13:38.960 I think the three main ones referred to as unsurprisingly 205 00:13:39.000 --> 00:13:41.679 as core web vitals because they are the core ones. 206 00:13:42.080 --> 00:13:45.039 We talked about them on the show on several occasions. 207 00:13:45.799 --> 00:13:48.919 I think we even had specific episodes dedicated to them. 208 00:13:48.960 --> 00:13:52.799 But still again, it might be worthwhile to mention what 209 00:13:52.840 --> 00:13:55.000 they are and what they measured. Do you want to 210 00:13:55.039 --> 00:13:57.879 do that or should I? 211 00:13:57.879 --> 00:14:00.399 I can explain like ten seconds like I'm he is 212 00:14:00.399 --> 00:14:04.080 basically interacting in a page and getting the result back visually. 213 00:14:04.799 --> 00:14:09.919 LCP is basically the largest like content fil basically any 214 00:14:09.960 --> 00:14:13.360 elements with text or some big text in it. In 215 00:14:13.440 --> 00:14:17.320 it is the like however, time it loads and then 216 00:14:17.960 --> 00:14:22.799 CLS is basically how much your page layout shifts. You 217 00:14:22.840 --> 00:14:25.080 want your IMP to be as low as possible, you 218 00:14:25.120 --> 00:14:27.879 want your LCP to be low as possible, and CLS 219 00:14:27.919 --> 00:14:29.360 to be low as well. 220 00:14:29.639 --> 00:14:34.679 Yeah, exactly. And it's interesting because there they are not 221 00:14:35.000 --> 00:14:39.919 trivial in the context of React especially. Yeah, and it's 222 00:14:39.960 --> 00:14:47.759 interesting because different facets of React address different these different metrics. So, 223 00:14:47.840 --> 00:14:51.360 for example, if we're talking about the largest content for paint, 224 00:14:51.519 --> 00:14:54.080 which like you said, is the amount of time from 225 00:14:54.080 --> 00:14:56.679 when the page starts loading until the largest piece of 226 00:14:56.720 --> 00:15:01.159 content is actually rendered on the browser screen, if we 227 00:15:01.200 --> 00:15:04.240 think about what React does to try to optimize it. 228 00:15:04.279 --> 00:15:07.799 So initially React, for those who who may not recall, 229 00:15:08.320 --> 00:15:12.799 was just client side rendered, and that kind of guarantees 230 00:15:12.960 --> 00:15:19.240 slow LCP by definition, because nothing is shown until all 231 00:15:19.279 --> 00:15:23.799 the JavaScript is downloaded, including React, and then the client 232 00:15:23.919 --> 00:15:26.799 side javascripts need to do the ajax calls to get 233 00:15:26.840 --> 00:15:30.440 the data and then render the UI based on the 234 00:15:30.559 --> 00:15:33.360 data and the code, and only then do you actually 235 00:15:33.679 --> 00:15:38.720 see anything on the screen. So that's when React introduced 236 00:15:38.720 --> 00:15:42.679 service side rendering, or SSR and static side generation or 237 00:15:42.799 --> 00:15:51.919 SSG with meta frameworks like next JS or remix. So 238 00:15:53.879 --> 00:15:56.559 it's by the way, it's interesting in this context that 239 00:15:57.159 --> 00:16:02.559 still many organizations that I ounter don't really care that 240 00:16:02.759 --> 00:16:07.799 much about LCP in the context of React applications, because 241 00:16:07.840 --> 00:16:10.960 a lot of the web applications that are built using 242 00:16:11.039 --> 00:16:16.440 React are things like dashboard or internal enterprise applications, and 243 00:16:16.559 --> 00:16:20.360 there the approach is that it's loaded once and then 244 00:16:20.519 --> 00:16:24.399 used all day long, and therefore the loading time is 245 00:16:24.799 --> 00:16:29.159 less important. I actually think that in many cases this 246 00:16:29.240 --> 00:16:33.840 is a misguided view because, for example, let's say you're 247 00:16:33.879 --> 00:16:36.759 commuting to work on a train. You want to use 248 00:16:36.799 --> 00:16:41.279 that time you're connecting via VPN into your internal network, 249 00:16:41.320 --> 00:16:44.759 you're loading your internal application, and it takes your entire 250 00:16:44.840 --> 00:16:51.919 train ride to actually load, which isn't fun. But be 251 00:16:52.000 --> 00:16:55.679 that as it may. So that's LCP. There's the IP 252 00:16:55.919 --> 00:16:59.639 which you mentioned, which is how responsive the pages to 253 00:16:59.720 --> 00:17:04.160 interac actions, how long it takes the page from when 254 00:17:04.240 --> 00:17:07.240 you actually click on a button to actually render the 255 00:17:07.279 --> 00:17:11.799 result of clicking on that button. And again, React can 256 00:17:11.880 --> 00:17:16.240 be really problematic there because if it's doing very lengthy 257 00:17:17.920 --> 00:17:22.400 rendering operations or re rendering operations and you click in 258 00:17:22.440 --> 00:17:24.920 the middle of one of these operations, then it won't 259 00:17:24.960 --> 00:17:28.839 actually respond or do anything until all that JavaScript finish 260 00:17:28.920 --> 00:17:33.519 is running. And CLS, I think, is the one that 261 00:17:33.680 --> 00:17:39.480 is least directly related to React itself, because it's more 262 00:17:39.720 --> 00:17:42.440 it has more to do I think with how you 263 00:17:42.519 --> 00:17:47.359 start your CSS stuff like that. I would say though, 264 00:17:47.440 --> 00:17:55.319 that for people who are using what's it called React suspense, 265 00:17:56.319 --> 00:18:02.079 they need to watch out for CLS because if they're 266 00:18:02.640 --> 00:18:08.880 loading code doesn't match the size of the actual finally 267 00:18:08.960 --> 00:18:13.240 rendered component, then things will shift after the after the 268 00:18:13.359 --> 00:18:17.559 load the loader is done, So so you do need 269 00:18:17.599 --> 00:18:20.119 to watch out for that if you're using suspense in 270 00:18:20.160 --> 00:18:23.440 the context of React, I think would you agree with that? Yeah? 271 00:18:23.440 --> 00:18:24.720 Also for images, right. 272 00:18:25.680 --> 00:18:28.839 Yeah, but images are there, you know that's a universal 273 00:18:28.880 --> 00:18:34.960 issue that's not reacts butific Yeah, so million js kind 274 00:18:34.960 --> 00:18:39.799 of addressed I guess both LCP because you were running 275 00:18:40.759 --> 00:18:47.559 the rendering code faster, and also it kind of addressed 276 00:18:47.640 --> 00:18:52.240 I n P because it blocks the rendering time for 277 00:18:52.279 --> 00:18:56.359 a shorter period of time. What I understand that you're 278 00:18:56.359 --> 00:19:02.799 addressing with reacts scan is most about figuring out how 279 00:19:02.839 --> 00:19:08.000 to do less rendering and also generally make the rendering 280 00:19:08.039 --> 00:19:13.599 itself faster, which again will would primarily benefit I n P. 281 00:19:13.839 --> 00:19:15.359 I guess. 282 00:19:16.839 --> 00:19:22.200 I see it as like rendering is always somehow related 283 00:19:22.200 --> 00:19:24.039 to some performance problem on the page if you use 284 00:19:24.079 --> 00:19:29.000 it reacts site like I'll give a couple examples, like 285 00:19:29.160 --> 00:19:33.559 for example with with with CLS, right, it could be 286 00:19:33.559 --> 00:19:36.519 a styling issue, but as a user, I want to 287 00:19:36.559 --> 00:19:42.400 know like where that specific uh specific like layout ship 288 00:19:42.519 --> 00:19:46.279 is occurring with i MP. I want to click a 289 00:19:46.319 --> 00:19:48.200 button and I want and there's like maybe a bunch 290 00:19:48.200 --> 00:19:50.599 of renders. I don't know why it's slow. A rendering 291 00:19:50.680 --> 00:19:53.640 is somehow always somehow related to that, even LCP, as 292 00:19:53.640 --> 00:19:55.680 you said, right, like like if there's a lot of 293 00:19:55.680 --> 00:19:58.720 rendering on the page that doesn't need to render, like 294 00:19:58.799 --> 00:20:04.279 maybe below the folder outside the viewpoort, then it's not good, right, 295 00:20:05.559 --> 00:20:08.400 even like other performance issues like when FPS drops or 296 00:20:08.480 --> 00:20:13.160 like I'm trying to think of other examples, but like 297 00:20:13.160 --> 00:20:16.960 whenever the page feels sluggish, it's always rendering is always 298 00:20:17.039 --> 00:20:18.480 somehow related to the problem. 299 00:20:19.079 --> 00:20:21.599 So FPS, can you elaborate on what that is? 300 00:20:22.519 --> 00:20:26.079 FPS is frames per second? Basically this is important for 301 00:20:26.680 --> 00:20:29.279 movement or animation tasks, so like when you scroll the 302 00:20:29.319 --> 00:20:35.359 page or something is animating like rainbow gradient. For some reason, 303 00:20:37.000 --> 00:20:40.039 that FS is important. You want to usually keep it 304 00:20:40.079 --> 00:20:41.319 over sixty fps. 305 00:20:42.160 --> 00:20:46.359 It is the standard. And again JavaScript gets in the 306 00:20:46.359 --> 00:20:51.200 way because the main thread, well the browser is kind 307 00:20:51.200 --> 00:20:54.519 of not exactly but mostly single threaded, so whenever you're 308 00:20:54.599 --> 00:20:57.920 running JavaScript, it kind of blocks everything. And if you're 309 00:20:57.920 --> 00:21:01.920 blocking everything too much, then you get jank or jitter 310 00:21:02.519 --> 00:21:04.559 because you're not able, like you said, to hit that 311 00:21:04.680 --> 00:21:10.680 sixty fps. I totally agree with what you said about 312 00:21:11.039 --> 00:21:15.519 identifying things that render needlessly. My own experience is that 313 00:21:16.240 --> 00:21:21.079 a lot of React teams don't even ever get there. Basically, 314 00:21:21.319 --> 00:21:26.039 when they see that something that the UI renders correctly, 315 00:21:26.839 --> 00:21:30.160 that's good enough for them, and they don't care about 316 00:21:30.160 --> 00:21:33.319 the fact that it's rendering correctly over and over and 317 00:21:33.359 --> 00:21:37.319 over again, effectively doing a lot of work at the 318 00:21:37.440 --> 00:21:41.839 virtual dome level without actually ever updating the actual dome, 319 00:21:42.400 --> 00:21:47.799 because the reconciliation basically notices that they're just recreating the 320 00:21:47.880 --> 00:21:52.279 exact same virtual dome over and over again. But even that, 321 00:21:52.920 --> 00:21:57.480 even though it's cheaper than updating the dome, still you know, 322 00:21:58.400 --> 00:22:02.359 accumulates if you concer doing that you're literally just running 323 00:22:02.400 --> 00:22:06.200 an infinite loop of JavaScript that's doing nothing. Is that 324 00:22:06.240 --> 00:22:08.759 has that been also your experience that it happens in 325 00:22:08.839 --> 00:22:11.079 a lot of organizations and a lot of websites. 326 00:22:11.680 --> 00:22:15.240 Yeah, that's definitely one of the problems. It's also I 327 00:22:15.240 --> 00:22:18.799 don't think it's necessarily engineer's fault, right, it's really hard 328 00:22:18.799 --> 00:22:20.920 to care about these things because they're not visible. Just 329 00:22:20.960 --> 00:22:24.359 like if the page UI is not correct, it's very visible. 330 00:22:24.440 --> 00:22:26.799 You have to fix it. If there's an error, you 331 00:22:26.960 --> 00:22:28.519 have to fix it, right, It's not like you can 332 00:22:28.559 --> 00:22:31.559 avoid these things. The performance you can really easily avoid 333 00:22:31.599 --> 00:22:34.720 because most developers use like a really high end MacBook 334 00:22:34.839 --> 00:22:37.880 or high end PC where you can like any performance 335 00:22:37.920 --> 00:22:40.319 problem you can blaze through and like basically hit with 336 00:22:40.359 --> 00:22:43.920 no problem. And also developers are so used to slow 337 00:22:43.960 --> 00:22:48.599 build tools and slow like development startups that like one 338 00:22:49.160 --> 00:22:52.440 hundred three or real seconds it feels like nothing. So 339 00:22:52.480 --> 00:22:54.759 the problem is performance is not visible, and developers are 340 00:22:54.759 --> 00:22:58.079 really out of touch in touch with users for performance, 341 00:23:00.920 --> 00:23:04.119 like even even if even for like performance experts who 342 00:23:04.119 --> 00:23:08.880 like think about performance every day, they're also not super 343 00:23:09.000 --> 00:23:12.519 in tune with like the actual products performance Like maybe 344 00:23:12.519 --> 00:23:14.119 they go to data Dog and they see the metrics 345 00:23:14.119 --> 00:23:15.839 and they're like, okay, how can I improve this today? 346 00:23:16.119 --> 00:23:18.559 Or they see a regression in performance after a specific 347 00:23:18.640 --> 00:23:21.880 git commit, But then it's like, okay, what do I do? 348 00:23:22.039 --> 00:23:24.279 Like how do I reproduce this? It's kind of hard 349 00:23:24.319 --> 00:23:29.160 to do those things. Reacts again is our attempt to 350 00:23:29.440 --> 00:23:32.319 try to fix some of this, right, Like how how 351 00:23:32.359 --> 00:23:35.039 do we make performance visible? Like how can we show 352 00:23:35.079 --> 00:23:39.079 developers that there's problems on the side without like having 353 00:23:39.079 --> 00:23:41.279 them loaded up on a Moto G four or something. 354 00:23:42.559 --> 00:23:44.440 Moto G four, by the way, for those of you 355 00:23:44.519 --> 00:23:49.000 are too young to know, is an old Motorola phone 356 00:23:49.039 --> 00:23:55.720 that Google still uses virtually for simulating performance of websites 357 00:23:55.759 --> 00:23:59.680 on low end devices. If you're using Lighthouse, that's what 358 00:23:59.680 --> 00:24:06.720 they there. Okay, then so you want to visualize the 359 00:24:06.799 --> 00:24:10.400 performance issues, how do you go about it? What do 360 00:24:10.480 --> 00:24:12.960 you actually show? How do I see that I have 361 00:24:13.359 --> 00:24:16.440 a performance issue in my React website? By the way, 362 00:24:16.640 --> 00:24:19.480 the tool is for React, right It's not you know, 363 00:24:19.599 --> 00:24:21.720 for websites that aren't React based. 364 00:24:21.759 --> 00:24:27.039 Correct, Yeah, React for now? Right now? We highlight renders 365 00:24:27.119 --> 00:24:29.599 and if there is some sort of long task or 366 00:24:29.640 --> 00:24:32.720 FPS drop or imp that's really high. We turn the 367 00:24:32.720 --> 00:24:34.960 color of the renders to like from purple to like 368 00:24:35.039 --> 00:24:38.920 red or something. In the future, we wanted to have 369 00:24:38.920 --> 00:24:41.640 more visualizations, like when I click a button, what is 370 00:24:41.640 --> 00:24:46.039 the IMP or like the local tested imp we have 371 00:24:46.200 --> 00:24:50.519 like or like what is the like long animation frame? 372 00:24:50.839 --> 00:24:52.680 Like when a long animation frame happens. I want to 373 00:24:52.720 --> 00:24:55.599 see that the long animation frame happens. I want to understand, 374 00:24:55.640 --> 00:24:58.319 like when jink happens, or when jink happens, what is 375 00:24:58.720 --> 00:25:01.920 the cause of that. Jink renders is like our base 376 00:25:02.000 --> 00:25:06.039 abstraction basically, like usually it's always related to It's like 377 00:25:06.119 --> 00:25:11.119 always somewhere within the problem, and so we show it 378 00:25:11.240 --> 00:25:12.279 via renders basically. 379 00:25:13.240 --> 00:25:19.279 So basically, if I understand correctly, you're adding rectangles around 380 00:25:19.400 --> 00:25:24.240 the React components that get rendered. And these components and 381 00:25:24.279 --> 00:25:31.680 these borders kind of highlight whenever the component renders. So 382 00:25:31.880 --> 00:25:36.759 if it's constantly highlighted, you know that this component is 383 00:25:36.839 --> 00:25:42.640 for some reason being constantly re rendered. Right and and 384 00:25:42.680 --> 00:25:45.119 by the way, again, re rendering is at the virtual 385 00:25:45.160 --> 00:25:48.440 dome level, so even a component might be re rendered 386 00:25:48.519 --> 00:25:51.920 even if nothing actually is changed for it in the 387 00:25:51.960 --> 00:25:58.200 actual browser dom. Correct, yes, yes, So it's it's your 388 00:25:58.279 --> 00:26:02.119 code and React code doing work for that component, whether 389 00:26:02.279 --> 00:26:07.720 or not anything actually gets updated in the actual display. Yep. 390 00:26:09.400 --> 00:26:13.960 And usually the border would have one color what is it, 391 00:26:14.000 --> 00:26:17.440 Like you said, purple or something like that. But if 392 00:26:17.839 --> 00:26:23.559 it's resulting, if it's causing the browser itself to actually 393 00:26:23.880 --> 00:26:27.720 experience delays, then it will actually change color and become red. 394 00:26:28.279 --> 00:26:28.640 Exactly. 395 00:26:28.759 --> 00:26:34.799 Yeah, very cool. So I assume you've tested it on 396 00:26:34.880 --> 00:26:38.680 various websites and saw them flashing rectangles all over the place. 397 00:26:39.480 --> 00:26:42.759 It gives like interesting examples. 398 00:26:43.119 --> 00:26:46.400 A month ago, I founded this performance problem on the 399 00:26:46.440 --> 00:26:49.240 GitHub site when you would scroll on the code every 400 00:26:49.640 --> 00:26:53.759 line of coder Revender. So I tweeted it, got a 401 00:26:53.799 --> 00:26:57.039