Hello everybody, and welcome to another exciting episode of JavaScript Jabber. Today, I'm all on my lonesome Dan Shapier coming to you from Tel Aviv in Israel, and I'll be interviewing Aidan by Hi. Aidan, Hi, how are you? I'm doing well overall? How about yourself doing well?
It's a not so hot, not too cold day in San Francisco.
So that's lovely. It's kind of same over here in Tel Aviv, so please we're sharing good weather, and we are here today to talk about React performance. But before we start, Aidan, maybe you can tell us a little bit about yourself and your very lengthy career in tech.
Yeah. I gotta started hooting in middle school. But like you might know me for a million, Jess, it's like I tried to make a compiler for React and then more recently React scan, which is all like the purple flashing boxes on all these popular websites. I U see it on Twitter. I've mainly mainly focused on performance most of my life because I think it's an interesting problem. Not many people focus on it, and it's also very hard.
Yeah, tell me about it. It's been one of my main focuses for the last couple of years. For those of you don't know, I also happen to be an invited expert on the W three C where Performance working Group. Maybe you should join us there as well. We talk about things not so much related to React, more about the relevant web standards, things like core vitals and stuff like that, and the APIs in the browser that can be used to retrieve them, to measure them, et cetera.
I know that it's not our topic, but I do want to talk a little bit about million js because it seems so interesting. So so as I recall it, it's kind of a drop in replacement for the mechanism in React that transforms the virtual dome into the actual dome. Is that a more or less correct description.
Yeah, that's correct. Like basically how React works under the hood is it takes like two versions of the view, so like the old version and the new version, and then it reconciles it, like it figures out the differences between those and then it applied it to the actual dome. But like this is like an an operation or some large, big old notation that's over one. And the problem with that is if when the versions get really big, like the trees get really big, you're doing a lot of computation.
So I was like, okay, wouldn't be cool if you could pre compile this, Like okay, based on the JSX you provide. There's like obvious points where it actually changes, like when you have those JSX container expressions, like the when you passing some data in, So I pre compile that and then found like the specific code paths that
matter to make the dom changes. So every time you render a component, instead of doing that whole reconciliation process, it just changes the dom like like pinpoint processes, basically.
Kind of implementing fine grain reactivity in a sense over on top of React.
I guess, yeah, like benef it's a fine grain reactivity, but without using fine grain reactivity.
Yeah. I think you kind of mentioned several things that are kind of important in the context of React performance as you were describing this. I think that first and foremost is this whole thing about virtual dom and the reconciliation. We actually had a couple of chapters in JavaScript jabber talking about the virtual dom, what it is, why it exists,
et cetera. But I still think it might be worthwhile to talk a little bit about what it is because it's so central to everything we'll be talking about today. So can you tell us a little bit about you the virtual dorm from your perspective.
Yeah, virtual dom is basically it's kind of an overloaded term. It's basically taking two like versions of the UI and figuring out the princess between them and then actually changing the UI. React doesn't actually hold the dom tree inside of itself. I mean it kind of does, but like when it does when it figures out what to change, it doesn't actually store the dominodes as the whole tree and then dip the dominance. It difts like a virtual
version of it. This can lead to some problems. So for example, like for Facebook, it might be somewhat okay, like when you were switching pages, but like if you are creating like a stock trading app, like a stock treating dashboard, where like there needs to be like updates every several like some amount of milliseconds, or you're making like significant dom mutations every single second, or if your website targets it targets like very low end devices, then
that sort of mechanism can lead to some performance problems.
I think the key aspect here is that React took what I considered to be kind of an idealized approach to UI generation, which is, let's in an ideal world, I would say react. The React approach is, let's take the entire application state and apply like a function to it, a pure function even that generates the UI that the user sees, and that every change in the state would
ideally again regenerate the entire UI. So you know, you check or uncheck a small checkbox in the UI, and theoretically the entire user interface of the application gets re rendered because then you don't need to think about state changes in the user interface. It's just everything again and again from scratch. But the problem with this approach is that a naive implementation would obviously be just way too slow.
It's kind of taking, by the way, the approach that we had in the old days of the multipage applications and kind of applying it to the client side rendering mechanism that we have in JavaScript code that updates the don in that in the old days you would go to the back end and then you would get the entire page back each and every time. So it's kind of like doing that, but again but doing everything on the client side and doing it for every state logical change.
And the virtual dom was like the first thing that they implemented in order to make it viable the from the perspective of performance, that is the virtual dom. By the way, it's a fancy term, but really really all it means is JavaScript objects. Really, that's all the virtual dom is. So instead of having actual dom elements, which are rather heavy because of all the functionality that they encapsulate, you just use JavaScript objects simple JavaScript objects as stand ins.
And like you said, when the state changes and the new virtual dom is created, React then takes the new virtual dome the old virtual dome, does a comparison, finds the differences, and then calculates the minimal amount of actual dom changes to transition from the first state to the second state. And that's the reconciliation process. And for a long time it was thought that it was that approach
was good enough in terms of performance. But like you said, when user interfaces started becoming more complex, complicated or more complex, and as we needed to support lower end devices like more mobile devices for example, and as we needed more frequent updates, even this type of optimization started to break down because doing all this reconciliation work still has overhead, and this is when million js, I guess came in
to start to try to reduce that. But like you said, being able to be smart about pinpointing the exact locations of the differences and not having to do the entire comparison of the entire virtual dom tree, right, yeah, exactly.
I view like virginal dom is more of in historical context, like it's more of getting things correct. Like before people use like Backbone or they roll their own JavaScript libraries and this would literally results in like like there were literally so many frameworks like bugs and these frameworks. Virtial dom is like a very exhaustive approach to the problem. But it's more likely to get things correct than that.
Yeah, because when you're essentially building the entire UI from scratch from the current state, you don't have to worry about an incorrect UI transition or state transition messing up your display. I think, uh, Facebook had they had this story about one of the motivations for creating React in the first place, is that they had a counter in their user interface about the number of messages that you
had pending or something like that. And any change to that mechanism was always buggy because they always had to somehow sync with everything else that was changing on the page, and because so many things were changing more or less concurrently in the UI, all of them as synchronous to each other, they would always get into age cases and age situations. And being able to just re render the entire UI from scratch virtually solve that problem very neatly.
But again, so we had a couple of performance issues. One performance issue is the one that you addressed with the mini and JS, which is the fact that even that sophisticated reconciliation could be too slow, especially if the virtual dome was really large, especially if the device was low end, and especially if you did it very frequently.
The other problem, I think is that even building the virtual dome, which is mostly just running your code that generates the JAX from the state, can be heavy and performance intensive if done too often, or if if it's just too complicated. And I think that this is where reacts can comes in, because it's that's your new project, the one that we're going to talk about, because it strives to, if I understand, correctly, minimize the amount of redundant helps you help you to minimize the amount of
redundant rerenders that you perform. Correct.
Yeah, exactly. I can give a brief introduct. Basically, react scan is a tool that helps you find like re rendering performance problems and you react ap today. You can just drop it in your app as a script tag and it basically highlights the components that render and potentially slow down your app. I spent like maybe three years optimizing websites, everything from like webar you see, like virtual
camera websites to e commerce websites. There's like static sites, and when I try to debug these performance problems on these sites, it's really hard. Like it's either like I do console that time and time end, or I use Lighthouse scores, which is like at skill level zero to profiling tools and Chrum dept tools. React to have tools at like skill level one hundred, and so there's like
nothing in between those those two types of tools. And this made me really frustrate, right, I Like I spent so long just trying to understand how these level one hundred tools work that that I realized that most people don't have the time or ability to figure it out exactly so react Skain helps bridge the gap. Today we do renders, but soon we'll support more stuff. More stuff in that like I n p cls LCP which are like the lighthouse Google Lighthouse scores, as well as stuff
like lung tasks. F he has all of this, like metrics and stuff that take They are decently like, not like decently hard like recently not easy to measure correctly and interpret.
Basically, so you threw out a bunch of metrics and then, as I mentioned, metrics are near and dear to my heart. They're part of what I do on the W three C Web Performance Working Group, which I'm an invited expert on. I think the three main ones referred to as unsurprisingly as core web vitals because they are the core ones. We talked about them on the show on several occasions. I think we even had specific episodes dedicated to them. But still again, it might be worthwhile to mention what
they are and what they measured. Do you want to do that or should I?
I can explain like ten seconds like I'm he is basically interacting in a page and getting the result back visually. LCP is basically the largest like content fil basically any elements with text or some big text in it. In it is the like however, time it loads and then CLS is basically how much your page layout shifts. You want your IMP to be as low as possible, you want your LCP to be low as possible, and CLS to be low as well.
Yeah, exactly. And it's interesting because there they are not trivial in the context of React especially. Yeah, and it's interesting because different facets of React address different these different metrics. So, for example, if we're talking about the largest content for paint, which like you said, is the amount of time from when the page starts loading until the largest piece of content is actually rendered on the browser screen, if we think about what React does to try to optimize it.
So initially React, for those who who may not recall, was just client side rendered, and that kind of guarantees slow LCP by definition, because nothing is shown until all the JavaScript is downloaded, including React, and then the client side javascripts need to do the ajax calls to get the data and then render the UI based on the data and the code, and only then do you actually
see anything on the screen. So that's when React introduced service side rendering, or SSR and static side generation or
SSG with meta frameworks like next JS or remix. So it's by the way, it's interesting in this context that still many organizations that I ounter don't really care that much about LCP in the context of React applications, because a lot of the web applications that are built using React are things like dashboard or internal enterprise applications, and there the approach is that it's loaded once and then used all day long, and therefore the loading time is
less important. I actually think that in many cases this is a misguided view because, for example, let's say you're commuting to work on a train. You want to use that time you're connecting via VPN into your internal network, you're loading your internal application, and it takes your entire train ride to actually load, which isn't fun. But be
that as it may. So that's LCP. There's the IP which you mentioned, which is how responsive the pages to interac actions, how long it takes the page from when you actually click on a button to actually render the
result of clicking on that button. And again, React can be really problematic there because if it's doing very lengthy rendering operations or re rendering operations and you click in the middle of one of these operations, then it won't actually respond or do anything until all that JavaScript finish is running. And CLS, I think, is the one that is least directly related to React itself, because it's more it has more to do I think with how you
start your CSS stuff like that. I would say though, that for people who are using what's it called React suspense, they need to watch out for CLS because if they're loading code doesn't match the size of the actual finally rendered component, then things will shift after the after the load the loader is done, So so you do need to watch out for that if you're using suspense in the context of React, I think would you agree with that? Yeah?
Also for images, right.
Yeah, but images are there, you know that's a universal issue that's not reacts butific Yeah, so million js kind of addressed I guess both LCP because you were running the rendering code faster, and also it kind of addressed I n P because it blocks the rendering time for
a shorter period of time. What I understand that you're addressing with reacts scan is most about figuring out how to do less rendering and also generally make the rendering itself faster, which again will would primarily benefit I n P. I guess.
I see it as like rendering is always somehow related to some performance problem on the page if you use it reacts site like I'll give a couple examples, like for example with with with CLS, right, it could be a styling issue, but as a user, I want to know like where that specific uh specific like layout ship is occurring with i MP. I want to click a button and I want and there's like maybe a bunch
of renders. I don't know why it's slow. A rendering is somehow always somehow related to that, even LCP, as you said, right, like like if there's a lot of rendering on the page that doesn't need to render, like maybe below the folder outside the viewpoort, then it's not good, right, even like other performance issues like when FPS drops or like I'm trying to think of other examples, but like whenever the page feels sluggish, it's always rendering is always somehow related to the problem.
So FPS, can you elaborate on what that is?
FPS is frames per second? Basically this is important for movement or animation tasks, so like when you scroll the page or something is animating like rainbow gradient. For some reason, that FS is important. You want to usually keep it over sixty fps.
It is the standard. And again JavaScript gets in the way because the main thread, well the browser is kind of not exactly but mostly single threaded, so whenever you're running JavaScript, it kind of blocks everything. And if you're blocking everything too much, then you get jank or jitter because you're not able, like you said, to hit that sixty fps. I totally agree with what you said about identifying things that render needlessly. My own experience is that
a lot of React teams don't even ever get there. Basically, when they see that something that the UI renders correctly, that's good enough for them, and they don't care about the fact that it's rendering correctly over and over and over again, effectively doing a lot of work at the virtual dome level without actually ever updating the actual dome, because the reconciliation basically notices that they're just recreating the
exact same virtual dome over and over again. But even that, even though it's cheaper than updating the dome, still you know, accumulates if you concer doing that you're literally just running an infinite loop of JavaScript that's doing nothing. Is that has that been also your experience that it happens in a lot of organizations and a lot of websites.
Yeah, that's definitely one of the problems. It's also I don't think it's necessarily engineer's fault, right, it's really hard to care about these things because they're not visible. Just like if the page UI is not correct, it's very visible. You have to fix it. If there's an error, you have to fix it, right, It's not like you can
avoid these things. The performance you can really easily avoid because most developers use like a really high end MacBook or high end PC where you can like any performance problem you can blaze through and like basically hit with no problem. And also developers are so used to slow build tools and slow like development startups that like one
hundred three or real seconds it feels like nothing. So the problem is performance is not visible, and developers are really out of touch in touch with users for performance, like even even if even for like performance experts who like think about performance every day, they're also not super in tune with like the actual products performance Like maybe they go to data Dog and they see the metrics and they're like, okay, how can I improve this today?
Or they see a regression in performance after a specific git commit, But then it's like, okay, what do I do? Like how do I reproduce this? It's kind of hard to do those things. Reacts again is our attempt to try to fix some of this, right, Like how how do we make performance visible? Like how can we show developers that there's problems on the side without like having them loaded up on a Moto G four or something.
Moto G four, by the way, for those of you are too young to know, is an old Motorola phone that Google still uses virtually for simulating performance of websites on low end devices. If you're using Lighthouse, that's what they there. Okay, then so you want to visualize the performance issues, how do you go about it? What do you actually show? How do I see that I have
a performance issue in my React website? By the way, the tool is for React, right It's not you know, for websites that aren't React based.
Correct, Yeah, React for now? Right now? We highlight renders and if there is some sort of long task or FPS drop or imp that's really high. We turn the color of the renders to like from purple to like red or something. In the future, we wanted to have more visualizations, like when I click a button, what is the IMP or like the local tested imp we have like or like what is the like long animation frame? Like when a long animation frame happens. I want to
see that the long animation frame happens. I want to understand, like when jink happens, or when jink happens, what is the cause of that. Jink renders is like our base abstraction basically, like usually it's always related to It's like always somewhere within the problem, and so we show it via renders basically.
So basically, if I understand correctly, you're adding rectangles around the React components that get rendered. And these components and these borders kind of highlight whenever the component renders. So if it's constantly highlighted, you know that this component is for some reason being constantly re rendered. Right and and by the way, again, re rendering is at the virtual dome level, so even a component might be re rendered even if nothing actually is changed for it in the
actual browser dom. Correct, yes, yes, So it's it's your code and React code doing work for that component, whether or not anything actually gets updated in the actual display. Yep. And usually the border would have one color what is it, Like you said, purple or something like that. But if it's resulting, if it's causing the browser itself to actually experience delays, then it will actually change color and become red.
Exactly.
Yeah, very cool. So I assume you've tested it on various websites and saw them flashing rectangles all over the place. It gives like interesting examples.
A month ago, I founded this performance problem on the GitHub site when you would scroll on the code every line of coder Revender. So I tweeted it, got a lot of likes, a lot of views, and then I don't remember their name, but someone from the VP of the roll GitHub was like, hey, one day later, hey, we fixed this issue. When I tested it, the fs increased. Now it was like, holy crap, like's it was really cool.
How just this random package we made and then just tweeting it out and just showing a video of it actually made a real performance change on the site.
Yeah, yeah, that's really cool. And my experience is that it's exactly that that it's very difficult to notice that the problems exist, especially like you said, when developers have really high end max and stuff like that. But once you understand where the problem is in a lot of cases, not all cases, but in a lot of cases, the
fix is fairly straightforward. You've got let's say, some use effect that's updating a state, which is retriggering the use effect, which is again updating the state and over and over and over again in this kind of an infinite rendering loop, something along these lines. Yeah.
Yeah, the main hard part of performance isn't the solution. The solution space is actually really small. It's usually like one to five solutions for every problem, But finding the problem is the hard part. It's almost ninety nine percent of the work.
Yeah, I totally, I totally agree with that. By the way, I'm just there are a whole bunch of sirens in the background, so I apologize for being a bit distracted. Yeah, that totally matches my own experience that it's sometimes that being able to pinpoint the cause of a performance issue is the hardest problem. But you know what, in that regard,
it's not that different from a lot of bugs. You know, the famous Heisen bugs that happen occasionally are very difficult to reproduce and figure out, and then you know, you smack your head when you realize what the problem is because the fix is often very very straightforward. My question then is how were you able to get this information out of React? I mean, you know, React doesn't exactly
tell you that, hey, you've got a performance issue. It just does this whole rerendering thing kind of automatically behind your back. So how did you figure this out?
Yeah? Most simply so, React dept Tools has information about componentry and renders. Well how does it do this? Well, React internally has it attaches like a property on the window object called React depth tools Global hook, and it has much of information about the fiber tree, and so reacts can internally uses that to get information about fibers just for context. A fiber is basically like the virtual
do on how React internally represents the user interface. We can use the fibers to detect renders, and then we show those renders using a canvas on the screen.
So base, ah, you're using You're not modifying the CSS, You're actually using canvas in order to draw the stuff on the screen.
Yes, if we modify the CSS, there would be like some overhead on that, so any performance score you would see is going to be noticeably like it's going to be artificially inflated. So what we did was we put the canvas on a worker thread, so it doesn't have as much performance impact as if you actually modify the CSS.
Ah cool, So what you're saying is you kind of put an invisible canvas on top of the entire rendered screen. I guess, and you're and canvas can be updated from a worker thread off of the main thread, which is not something you can do with the regular browser dome. So you're able to draw into this wholly separate user interface GPU layer without impacting the rendering time of the actual browser at all. That's very very cool.
There's a little bit overhead because we have to still send the data over to the worker thread, but from our testing it's pretty minimal. It doesn't affect like the standard metrics as much.
I understand, but for example, you still need to for example, get the rectangle the actual rectangles on the display of the dome elements, and if they there scroll, you kind of need to move the rectangle along with them. Or something or things along that line. Correct, So that does still take a little bit of overhead in terms of work on the main thread. But basically you're just firing that throwing that over into that worker and it does
the heavy lifting exactly. Yeah, have you measured the impact the performance impact that having reacts can on the site actually has, because that's that's indeed a real problem that you know, it's kind of like quantum physics, where you're measuring things can actually impact the behavior of the application. Like I recently saw a tweet about somebody saying that he had a bug in there in his code. He added the log, the bug went away, he removed the log,
the bug came back. So sometimes even the act of measuring can really impact the performance and behavior of the of an application. So how how did you actually verify that you have hardly any impact on the run time of the application itself?
Measuring here, Like it's like not really a good way to figure out the overhead. Like, basically we run on dev, which means they're using development builds, which is not the same as a production build. So development bills will likely be slower than production builds on a basic app. It's around, it's like less than one percent. At more heavy apps
still less than one percent. But like in reality, we like you can you have to like measure on like a large scale applications and actually on the correct build of the app to understand the overhead. Right now, it doesn't matter too much, but like as I said, like it maybe for some edge case it might be much more question.
As you said, you're using the same APIs that React dev tools uses internally, in fact, by the way undocumented APIs. As I understand, what is the advantage then of using React scan over just using the React's own developer tools for essentially the same purpose because they also have a performance view in there. If you install the Chrome extension for the React Developer tools, for example, you get a performance tab, a React performance tab in the developer tools.
So what's the advantage of using a React scan over that capability that React provides themselves out of the box.
Yeah, Like I view React Depth tools as like the endgame of debt tools. Like it's it's a great version. There's obviously improvements that can be made, but it's like the best React depth tools React.
Right.
The problem is, like you need kind of like a there, there's there's like a very low like you have to be decently skilled at using React deaf tools or crumb debt tools in order to use those depth tools, and most people don't really know how to do it. React scin is a more accessible version of it, specifically for rendering and performance app performance issues inside your React app. React deptols is more general, more advanced depth tools for interacting with your app. Uh yeah, I use React and
React depth tools. Uh for my use case.
Oh okay, cool. So when I used React scan is it Does it even require the depv tools to be open? Or do I just see everything on the browsers display.
Itself undevelopment in development, you just drop a script tag into your like head tags and then it should.
Work and you don't need to open depth tools at all.
No, no, yeah, you just have it. It just runs you know where.
That's potentially a very significant advantage on mobile devices. The fact that I can just drop in a script tag and see the issues on the browser screen itself is a big advantage in terms of identifying such issues versus having to attach the phone a physical phone via a physical wire to a mac or PC in order to open a remote debugger and then debug everything that way.
It's a much more convoluted process. If I can just see all the problems directly on my mobile screen, that's a huge advantage from my perspective.
Yeah, that seems like a really good use case.
Now do you only show the squares with the colors or do you sew additional information there?
So induce us shows some additional information on the screen itself. So each rectangle will have a little label on it showing the component name and also how many times renders and how much time it took. You can also there's like a in browser toolbar. You can inspect any component or render to see when it renders. You can replay them.
You can see what props change, what state changed, where context changed, and you can just figure out exactly what are the props or attributes or information about the React component that are causing the problematic performance.
Wow, that's really really cool. By the way, when I drop in that script tag, does it automatically enable this you AI, or do I also need to do something in the browser itself to enable it, Because I'm thinking that in some cases people will want to have that script tag be present, you know, all the way is but not have all the users seeing those rectangles.
Yeah, by default it only runs in developments. We do offer like programmatic off and on APIs. So like companies like Notion or Shopify, what they do is they are sorry, yeah, Shopify Notion, they have an internal to bar and basically you can click like turn React scan on and it turns the and opens the React skan overlay and two bar.
What you might want to do as well is maybe add the support for a special URL parameter m HM, so that you could turn it on or off using a URL parameter that you know doesn't hopefully doesn't conflict with anybody's URL parameter, but that would make it especially easy, especially on mobile. I thinking that that would be very useful.
We did similar things at Wix where we added special debugging capabilities into Wix websites, but they were only enabled with a very specialized, well not document not externally documented URL parameter, obviously nothing that could actually break a website. You know, you need to be careful because their potential
security issues around that. You know, somebody could send the link with that URL parameter to somebody and then they would see the red lines and then they would get all freaked out because they would think something is wrong or something along these lines. But in general, I think that this can be a useful feature.
Yeah, that's awesome.
Right after this podcast, I'm glad that I can help make the product better. I also saw various demos that you were showing about all sorts of ways to graph the component hierarchies in the React application. Is that also part of the same thing.
We haven't shipped that, but we're just playing around with what visualizations would work. So, like for context, I was working in this really large enterprise e commerce app and they had a bunch of components depending on the same context. But it was really commolluted, right because they were like nested hooks. There was nested components, Like a bunch of stuff was re rendering. I didn't know why. So I spent like ten hours just on tl draw graphing out the entire code base from the route that.
Was re rendering.
And I was like, why the why the heck am I doing this? Like like this is like so much work just to figure out why all these components are rendering. One thing we want to do this, dude, try is
doing this automatically? Like, can we graph out the component tree and also the hooks tree and show where the source of the problem is most like re rendering issues, like they can be caused by a higher component or a context, but usually they're systemic, right, Like, it's usually like one context causing all these components to rerender, and all these components have faulty implementations that cause this performance issue. So we're trying it. We're trying some visualizations to help exces.
So we have a user from LinkedIn to asked, what is the business model for the react scan project? Is there a cost to using react scan? I'll fill in the blank. Is it open source? Is it free? What's what's your business model around this tool? Are is it already released? Is it beta? Where are we at?
Yes, it's it's not one point oh, but you can it's stable, you can try in your app. It's free, open source, you can copy the code, you can fork it, you can do anything with it. If your company requires it's a host on our internal package. You can do whatever you want. The way we make money is through monitoring and observability. So we have a different product that uses is React scan on in like et or staging environments,
so you can run your playwright test. We figure out the performance scores of these playwright test and tell you whether the performance increase or decreased. This is a This is a real problem because like most observability tools like Century data DOT, they're really confusing, right, you have to like read profiles, the graphs are somewhat like we'd like, and it doesn't really tell me like what is the root cause of the problem. We're trying to solve this.
We're trying to do this specifically solve this for React.
So it's it's essentially a performance budget tool for React applications.
Yeah, exactly.
By the way, for again, performance budget is something that we mentioned in previous episodes for those of you don't
remember or don't know what it is. A performance budget is a way to say, like, specify how much how performance I expect my application to be, and then during the testing process in your CICD flow, you can measure the performance of the latest build, compare it to your budget limits, and if you exceed your budget limits, you essentially break the build like you would for any other bug.
And then the only way in which you can release it is either fix the performance issue that you're under budget again, or unfortunately, in some cases, you might need to increase the budget because maybe you just made the UI more complicated and sophisticated, and therefore it's a legitimate decision to make. But you're doing it with full awareness of what you're changing. It's not just something that happens and you're not even aware that it's going on, that
your application is becoming slower. So you're building a performance budgeting tool that's focused on React application. It's not just working at the co word vital is level. It's focused on React and it helps you understand how you React application is actually working in terms of performance, and if you exceed your budget, not only does it break your build, but it also tells you where the problem is likely act.
We do also do quero vital So basically, the data hierarchy is interactions. So if interaction becomes slower or your playwright test that's a problem, then we go a little bit deeper out like if an interaction is slow, what components may have caused that? Or what components underwhere may have caused that? And then potentially like down to the render, like what props, context or state may have changed.
Now, what I'm thinking that might be really useful in this context is something although off the top, I'm not exactly it's more of a vague idea that I have rather than a plan. But you know, one way in which REACT performance is improved in at least in perceived performance, if not actual performance, is using suspense by deferring rendering of certain non urgent UI components. Maybe they are maybe they're outside the visual display area, or maybe they show
lower important information or stuff like that. How do you handle those? Can you recommend to me that this thing should be should use suspense or stuff like that? Is that something that you're thinking about or looking at?
Yeah, of course that's all on scope basically.
Cool, and so any like hints about what you're thinking about doing in this.
Context specifically, For so, there's a couple applications like things outside the viewport well and it if it renders, we
mark that as like an unnecessary render. M hmm, like there, I mean, like obviously there are different solutions here, like first, maybe don't render it, or maybe there are some like hacky solutions for like partial hydration, like don't hydrate unless it's viewed, or like suspense as you're saying, we don't do recommendations yet, but we do detect the problems itself right now.
Okay, So when you're doing when you're doing the that rectangle highlight, if the rectangle is wholly outside the visual the visual viewport, then it gets kind of flagged and logged that, hey, this was an unnecessary render. You should be doing something about avoiding avoiding.
That exactly, Yeah.
Or postponing that or so something along these lines. That's very very nice. So you said that you're using both React scan together with uh the with the React dev tools. What where do you focus? What information do you get where? Like what's the benefit of using them both together? Yeah?
Anywhere from like skill level zero to skill level maybe seventy or eighty percent, which is basically like looking at the renders where they occur inspecting components with props change or components change. I use React scan for for React deb tools, I use the profiler component so like it shows like a timeline of like what functions ran. I also use the Chrome dev tools profiler, and then sometimes
I use the componentry provided within React obt tools. Like obviously, if React debt tools works for you, you should use it. I recommend giving reactscan a try. If it works better for certain use cases, you should use it for use case. If it doesn't, then then don't.
One more thing that you might try to do, assuming it's not too complicated or doesn't have too high over it in and of itself, is that if the user hovers on top of one of those tooltips then that you render on the canvas, then you can could display additional information like what caused the latest surrender or stuff like that, things that wouldn't fit inside the tooltip of itself. Again, anything that can save me the need to have to open Chrome dev tools and go back in history would
be very beneficial. Obviously a problem with hovering is that it doesn't actually work on mobile devices, or maybe a click on those you know, tapping on the tooltip or something along these lines that could be that could be useful. Again, especially because on mobile devices, accessing DEPV tools becomes a lot more challenging. So anything you can show on the mobile display itself is very ben official.
That's an amazing idea. Yeah, perfect, I'm just getting this is like a user interview.
Well, you know, performance is my jam, so you know I've been doing this for a long time, longer I wouldn't say longer than you've been alive, but starting to come on that. So, yeah, anything else you want to tell us about your tools or things that you're looking at doing, or things that you want the listeners to know about.
Yeah, I mean, if there's one thing you should listen do is performance matters a lot, like probably more than you expect. And even if it I mean, like even if it doesn't matter your company, like people leadership doesn't really care, you should try at least see if it maybe will improve some metric for users or improve your sales. If you're just an individual user, try learning how performance works,
upskill yourself performance. Like my experience, there are not that many performance experts, and there's a lot of need for performance experts, and so from a job opportunity perspective, there's also there's an opportunity there, So learned performance har we x scan if you want to. And yeah, in this context.
By the way, there's the actual excellent web dot dev website which is actually run by the Google Chrome DevRel team I think, and they have a section there called case studies Case Studies on Web dot Dev, which basically is just this huge list of case studies of companies that improve their performance and got a huge boost to their sales or bottom line or whatever as a result.
So if your company doesn't care about performance and you need to convince management that performance is actually important, then web dot dev Slash case studies is a great resource to use in this context. And I totally agree with you that having good performance is a game changer in many cases. It's the whole difference between an application that's pleasant to use, that's engaging, versus one that you hate using because it's janky and unresponsive.
For sure.
Yeah, and it's also an accessibility thing, and it's about enabling people who might otherwise not be able to use your application to actually use it and benefit from it.
Because again, like you said, if your application was written by people with really high end devices fast max fast iPhones, and they never bother to check on lower end device is or they just don't care about performance because it's good enough on their own devices, they not may not be aware that people on lower end devices just found find their application wholly unusable.
Yeah, exactly. And you'd be surprised the amount of e commerce companies where performance actually matters to sales that don't monitor, monitor performance or care that much, and so what happens is they are literally losing out on like seven to eight figures sales every year.
By the way, again speaking about React, we had Rick Wickskomi from Google on our show or a few years back, and he runs this great service. I don't know if you're familiar with it. It's h it's a Chrome User Experience Report or CRUs. Yes, uh. And they have this website where you can actually see the performance graphs by technology.
So Google literally grabs performance in information from your browser unless you opt out from your Chrome browser, and they upload it into their database anonymously of course at least so they say. And then they and there they run all sorts of analyzes on it, including which technologies it uses. And that makes it possible, for example, to see how good REACT websites in general are in terms of performance.
So we mentioned the three co ed vitals. A A site is considered to have good performance if it has if it's good for all three cowed vitals. That means that it's fast enough at the seventy fifth percentile for LCP, for CLS, and for IMP for example, LCP needs to be faster than two and a half seconds at the
seventy fifth percentile. As I recall, and it turns out that if you look at React websites, can you guess what percentage of React websites in the totality of all React websites actually get good COVID vitals.
If I were to guess, maybe like ten, No.
You're being overly harsh. It turns out, well, it used to be that way, but it turns out that the browser makers have been doing a phenomenal job of improving the performance of the platform itself. So even though React websites in and of themselves may not have improved that much, just because the browsers have been getting better and faster and more sophisticated, then the React scores have gone up.
In fact, all websites scores have gone up amazing. So if I look, so, we were at twenty percent on React websites back in twenty twenty one. So in April twenty twenty one we cross the twenty percent threshold. Now React websites are forty one percent have good coed vitals. That's phenomenal. That means that almost well fifty nine percent don't, which is the majority of React websites, which is truly unfortunate. By the way, if we compare to other technologies, WordPress
slightly ahead of React. So people building WordPress websites, they are at forty three percent, so they are two percent better than React. So you're thinking you're a hot shot React developer, and I'm talking to our listeners, there's a good chance that the WordPress website built by some web designer has better performance than your sophisticated React website. And if I'm looking at other technologies like you mentioned Shopify, Shopify is at seventy six percent and wis for example,
is at sixty five percent. So seventy six percent of all shops of all the Shopify websites have good coed vitals and that's almost double React. That's pretty that's pretty unfortunate from my perspective. Yeah, and hopefully with hopefully, with tools like React scan, people can make their React websites more like load faster, be more responsive, and generally be
more pleasant and more accessible to use. By the way, have you also thought about doing things related to accessibility in your application or you for now focusing only on performance?
For now on performance, but that'd be a cool extension if there if there is enough of a need for.
That, I think there there should be. But you know, it's your business. So if people want to try out react scan, like you said, it's open source, it's free to use, how can they go about it? And if they want to try out your more sophisticated tools for the c I c D pipeline, how should they go about it?
Yeah, you can just got to react scan dot com. Let's react scan dot com or just look up react scan and google there there's research. It tells you how to install the basic react scan and we have another page called monitoring, which should be on the website. You can click on and then try the demo and then add your website yourself. It should. React scan takes lesson a minute to set up. Our minoring service takes also probably less than five minutes.
Is it also possible to add it to a page using NPM or is it just via script tag?
NPM script tag you can run to be your cl I. There's there's like four ways to do it.
Anything else that you want to mention and talk about in this context, not at all.
I'm just really really grateful to be a on this podcast and good to talk to you again, Dan.
Yeah, same here. I love talking about performance and I love seeing somebody so young, so into it and making such an impact in this context. You know, bringing anything we can do to improve the situation with React is great in my book. I mean, at the very least we need to be above fifty percent. I mean, at the very least more than half React websites should have good performance. By the way, what is also surprising to
me and even more unfortunate. Can you guess what the situation is with next js?
Is it lower than React?
Surprisingly? It is. You would expect it to be higher because it provides SSR and SSG, which are great for LCP, but it isn't. I actually have a talk that I give on this topic trying to kind of analyze why that is. But the bottom line is that, as I said, with React, it's forty one percent of React websites. Our websites using React would be a better way of phrasing it have good core vitals. With NEXTGS it's only twenty eight percent.
Yeah, I'll be curious why. That's interesting.
Yeah, I'll be curious why as well. I'm guessing part of it is maybe having to do with the long tail of old NEXTGS versions, maybe not installed on VERSELL, maybe installed on AWS and not properly optimized. But it's a good but it's a good question of why that is. And like I said, I have several theories and I've even given talks on this topic. So if you're running a conference and you want to hear my opinion about why some frameworks are faster than others, then invite me
to speak at your conference. Anyway, Okay, I think with that, I'll be pushing us to that final part of our episode, which is the picks part. I didn't give your heads up for it. I hope that you can't prepare. Nonetheless, I'll go first, so you have time to choose. Basically, picks is where we shout out whatever. It can be
technical things, it can be non technical things. It can be your favorite movie, TV show, band, whatever book you still read books and and you know, or technical things that you want to just you know, shout out about, including your own. So I'll start with mine. I don't have a lot in the way of picks. I have
just one. So I'm from Israel, from television Israel, obviously, the situation here has been really unfortunate over the past year, the over a year, almost a year and a half, with the war going on and a lot of suffering and loss of life. At least we got some really great news as yesterdays of the time of this recording, where a cease fire has gone into effect, and in particular, three Israeli hostages were released. They were held in captivity
by Hamas for four hundred and seventy one days. Just imagine being held in a tunnel underground with the threat of death constantly hovering over your head, with hardly any food and no ability to move. And some of them were all so victims of abuse, even sexual abuse. It's very distressing. So three of the hostages were released yesterday as part of this agreement between Israel and Hamas. Their names are Doron Steinbacher, Emily Damari and I should have
come better prepared and Romy gone. Two of them were actually abducted from their own homes. So on October seventh, twenty twenty three Hamas terrorists broke into their home kidnapped them literally out of their beds. One of them was shot, she lost some fingers in her hand, and they were taken into Gaza and literally in their pajamas. The third one was kidnapped from the Nova Music festival. Again. She was also shot wounded and they never got medical attention
for that. And I'm really happy that they've been finally being released and reunited with their families. Hopefully they'll be able to make a full recovery from this ordeal. Obviously it's not simple, but and that still leaves ninety four hostages Israeli hostages in Hamasa's hands. I really hope that the ceasefire can persist and these hostages will be released eventually as well, hopefully as soon as possible, And that
would be my pick for today. It really brought joy to my heart yesterday when these hostages were finally released, and that's my pick for today. Do you have any picks for us? Aidan?
I have one thing I am much less, much less important, but yeah, I really, I mean I need this since Algol, but I really like the proxy API and JavaScript. So basically you can wrap any object in this like proxy keyword, and then you can spy on any property. So if you access like object dot name, you know when that you can like programmatically know when that property is accessed.
Oh yeah, proxy is really cool. Yeah. Basically, you take you do a new proxy, and you pass in the object you want to what to be the instrument or track and like you said, any access to either reader property from that object, write a property to that object can be tracked, can also be modified, by the way,
so you can kind of it. The one thing to be careful with, by the way, in this context is that it can be used, and it was in fact created for that purpose to kind of break JavaScript semantics in a sense, because you can override the standard JavaScript object behavior with proxy. I've actually done exactly what you described. I had a problem in an application, a legacy application that I was trying to refactor. Some code was modifying a global object and I was unable to locate where
that modification was happening. So I literally created a proxy around that global and put a debugger statement in the property set, and that way, I when the brake happened in the developer tools, I had the call stack and I could find where that operation actually happened. That was I felt like having a superpower when I was able to do that. Yeah, proxies are very powerful, by the way.
In other use of proxies. I don't know if you know this, but View I think uses proxies at least in the development mode to implement their reactivity.
Yeah, I think Vaultier and some other estate management too. Or you can use it to like for if you want to get fired. You can use it to prank or coworkers.
Okay, now you have to tell me what did you do?
I haven't done it, but I was thinking of replacing like like we have an internal library, like returning a proxy and having all the properties return undefined or something. Yeah, something super stupid.
Yeah, okay, you know, well, boys will be boys or depths will be depths, I guess. Yeah. Anyway, Aiden, it's been really fun having you on the show. I'm really excited about the stuff that you're doing. I'm really happy whenever something comes along which makes it possible to improve performance on the web. We definitely need more of that, and it's it's amazing to see somebody so young making such an impact. And I hope to be hearing more great things from you and having you on the show
again to talk about more stuff that you're doing. Yep. Now and now if people want to contact you about you know your existing projects, more ideas for what can be done and improved with these or maybe ideas for future projects. What's the best way to reach out to you.
I'm on Twitter, Blue Skuy YouTube. Just look at my name and then you can just DM me and I'll answer you.
So it's aid and buy on all those platforms.
Aiden, Why Bye?
Yeah? Aiden? Whyby? Okay? Great? So again, Aiden, thank you for coming on our show and to all our listeners, thank you for joining us. And that's it for today. Bye,