How React Compiler Performs on Real Code

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

The most talked-about news in the React community this year is probably the React Compiler. Everyone is looking forward to being saved from the re-render plague and never having to write useCallback/useMemo again.


But are we truly there yet? Can the React Compiler actually achieve those things? Do we need to do anything other than turning it on and enjoying a re-render-free life? I ran it on a few real-world apps to find the answer. Want to see the results?


In this talk, we’ll take a look at what the React Compiler is, what problems it solves, and how it performs on simple code examples and real-world applications.

This talk has been presented at React Advanced 2024, check out the latest edition of this React Conference.

FAQ

Nadia is a developer who has worked for a small startup and Atlassian on the product JIRA. She loves to travel and moved from Australia to Austria. Her hobbies include investigating how things work and writing about them.

Nadia has spent the last few years investigating performance, re-renders, and React. She has written articles, made YouTube videos, and published a book on these topics.

React Compiler is a tool from the React team that aims to optimize re-renders by memoizing components, props, and dependencies of hooks by default. It plugs into the build system to improve performance by reducing unnecessary re-renders.

Memoization in React involves using React.memo to wrap components. It checks if props have changed; if not, re-renders are stopped. For non-primitive values, useMemo and useCallback hooks are used to preserve references and prevent re-renders.

React Compiler has a minimal impact on initial load performance and can significantly improve interaction performance by reducing unnecessary re-renders.

Nadia found that React Compiler might not catch every re-render, especially with external libraries or complex legacy code. It may not handle cases where code isn't fine-tuned for memoization.

For most developers, enabling React Compiler may be sufficient, allowing them to forget about manual memoization. However, those needing to optimize every millisecond may still need to use manual memoization techniques.

In large or old projects, it is advisable to enable the compiler gradually, file by file, and conduct thorough testing to ensure compatibility and performance improvements.

React Compiler does not transpile external libraries, so its effectiveness may vary depending on the library's compatibility with memoization.

Nadia starts with an idea, writes examples and articles, iteratively refines them, and discovers new insights during the process. She shares her findings through writing and presentations.

Nadia Makarevich
Nadia Makarevich
31 min
25 Oct, 2024

Comments

Sign in or register to post your comment.
Video Summary and Transcription
I'm Nadia, a developer experienced in performance, re-renders, and React. The React team released the React compiler, which eliminates the need for memoization. The compiler optimizes code by automatically memoizing components, props, and hook dependencies. It shows promise in managing changing references and improving performance. Real app testing and synthetic examples have been used to evaluate its effectiveness. The impact on initial load performance is minimal, but further investigation is needed for interactions performance. The React query library simplifies data fetching and caching. The compiler has limitations and may not catch every re-render, especially with external libraries. Enabling the compiler can improve performance but manual memorization is still necessary for optimal results. There are risks of overreliance and messy code, but the compiler can be used file by file or folder by folder with thorough testing. Practice makes incredible cats. Thank you, Nadia!

1. Introduction and Background

Short description:

I'm Nadia, a developer with experience in performance, re-renders, and React. I've investigated these topics and shared my findings through articles, videos, and a book. Recently, the React team released the React compiler, which eliminates the need for memoization. I've tested the compiler on synthetic examples and real apps to evaluate its performance. Now, I'm excited to share my insights.

Thank you for the intro. As mentioned, my name is Nadia. Let me start by quickly introducing myself and talking a little bit about myself. I've been a developer for a very long time now. I worked for a small startup at some point. I worked for Atlassian for a few years on a product that some of you probably know and probably love called JIRM. I'm a bit lazy and also I love to travel. So a few years ago, I moved from Australia to Austria just because it's easier to spell. I'm a little bit of a nerd and one of my nerdy hobbies is to investigate how things work and then write the results down. I spent the last few years investigating everything that I could about performance, about re-renders, and React. I wrote a bunch of articles on this topic, I did YouTube videos, I even published a book, half of which is dedicated to the topic of re-renders, memoization, and how to control them. And during those years I kept seeing visitors from the future probably who would kindly inform everyone around them that memoization is not needed anymore because of React forget, currently known as React compiler. This April, our timeline finally caught up with theirs. React team released the compiler to the public and of course I had to try it and see the future for myself. So I tried the compiler on a few synthetic examples, I ran it on a few real apps, measured how it performs and what it does. Of course, I wrote it down and now I am happy to share with you how the future really looks like. So this is what the talk is all about.

2. Problem and Solution

Short description:

The problem the compiler solves is the performance impact of cascading re-renders in React. One way to address this is through memoization, which can be achieved using the React memo and hooks like useMemo and useCallback. By preserving references to non-primitive values between re-renders, we can prevent unnecessary re-renders and improve performance.

What is the problem the compiler solves? Are there any downsides to it? How it performs on synthetic examples and how it performs on real life code?

Let's start with the problem. So what exactly are we trying to solve here? Here is our beautiful user interface, it's really nice. When some new information comes in there, we want to update it. To do this in React, we trigger what is known as a re-render. Re-renders in React are cascading, as you probably know. Every time a re-render of a component is triggered, it triggers a re-render of every component inside and then every component inside this component until the end of the tree is reached. If those downstream re-renders affect some really heavy component, our app becomes slow. So that might cause performance problems.

To fix this, we need to stop this chain of re-renders from happening. One way to do it in React is to tell this component that it doesn't change and it can skip re-renders and re-render of every component inside. And of course, as always in React, there are multiple ways to do it, but one of them is memoization. Memoization starts with the React memo, a file or the component given to us by the React team. It wraps our original component and then renders itself on its place. Now, when the React reaches this component in the tree, it will stop and check whether its props have changed. If none of the props changed, then re-renders will be stopped. If even one of the props changes, React will continue with the re-renders as if no memoization happened. That means that for the memo to work properly, we need to make sure that every single prop on this component is exactly the same between the re-renders, otherwise, it just will not work.

For primitive values, it's easy. We don't need to do anything other than not changing them. For objects, arrays, and functions, however, they need some help. React uses referential equality to check for anything between re-renders. And if we declare those non-primitive values inside the component like I did here, they will be recreated on every re-render. Reference to them will change and memoization won't work. To fix this, we have two hooks, useMemo and useCallback. We will drop arrays and objects into useMemo, functions into useCallback, and then those hooks will preserve a reference to the values between the re-renders. And next time a re-render here in the parent happens, the very slow component will not re-render. And the chain of re-renders will be stopped. That is enough of the theory for today, I promise. This is a very simplified explanation, but as you can see, it's actually already quite complicated.

3. React Compiler and Practical Applications

Short description:

Solving the complex situation of managing changing references in React apps is the main promise of the React Compiler. The compiler converts component code to automatically memoize components, props, and hook dependencies. It intelligently optimizes the code, caching certain values while rearranging others based on references. However, practical applications and expectations of the compiler raise important questions about initial load performance, the impact of re-renders, and the ability of the compiler to catch all cases. Synthetic examples are used to evaluate the compiler's effectiveness in addressing these concerns.

This is a very simplified explanation, but as you can see, it's actually already quite complicated. So anyone who used those hooks in real life knows how hard it is to trace those changing references and how quickly our beautiful apps turn into an incomprehensible and unusable mess of useMemo and useCallbacks. So solving this situation is React Compiler's main promise.

The compiler is a tool given to us by the React team. It plugs into our build system, grabs the original component code, and then tries to convert it into code where components, the props, and dependencies of hooks are memoized by default. The end result is as if our normal React code behaves as if everything is wrapped in memoUse, memoUseCallback, which is already very cool. But it doesn't actually do this. It doesn't wrap things blindly. It's much smarter than that.

For example, something as simple as this will be transformed into this. Notice how onClick is cached at the very bottom, but the data object is not really cached. It just moved inside the if statement. However, if I reference this data inside onClick, the compiler understands this and rearranges the code to sound like this. Mechanics of all of this are absolutely fascinating. However, in this case, I'm more interested in practical applications of this engineering miracle.

So more specifically, I want to know whether our expectations from the compiler match the reality. And three main questions immediately pop into mind for almost everyone. First one is, what about the initial load performance? One of the big arguments against memoizing everything by default has always been that it can negatively affect initial load, because React needs to do much more stuff in advance where everything is memoized. Second one is, will it actually have a positive impact at all? How much of a problem re-renders really are? And the third one is, JavaScript is notorious for being fluid and ambiguous. Is the compiler smart enough to really catch absolutely everything? Is it true that we will never have to think about memorization and re-renders ever again? Before answering those questions, let's quickly check out the compiler on a few synthetic examples. Maybe, who knows, maybe it doesn't work at all.

So our first example, we have a component with a dialogue, a state for this dialogue, and a button that can open it. And a very slow component somewhere underneath. So let's say it takes five milliseconds to re-render. Normal React behavior here would be to re-render everything, including the very slow component when the state changes. And as a result, the dialogue pops up with a delay because of the slow component. If I wanted to fix it with memoization, I would have to do this. Just wrap it in the React memo. Let's get rid of it and enable the compiler for this code and see what will happen. In the dev tools, I see the magical memo appearing everywhere, the blue stuff.

4. Optimization and Handling Children

Short description:

Components optimized by the compiler show instant rendering and no re-renders for slow components. Adding props to the slow component and applying the compiler results in the same behavior. Memoizing the component correctly involves handling children as a prop using memo.

That means that components are optimized by the compiler. And now all I need to do is just put the logger inside the very slow component and try to trigger the dialogue. As you can see, only the button that it renders, the dialogue, well, the dialogue shows up instantly. If a slow component doesn't re-render. So that's the first win for the compiler.

Let's now make it a little bit more complicated and add some props to the very slow component. A standard stuff, an object, and a function. So if I wanted to memorize it manually, this would be the classic trio. Use memo, use callback, and memo itself. Let's again get rid of it and apply the compiler to the code. The end result, exactly the same. Only the button re-renders. Slow component doesn't re-render. The dialogue pops instantly. I'm adding another win to the compiler. Good job. I love it.

Third one, and that is the fun one. Let's try on something even more complicated before going for a real app. And what if the very slow component accepts children? Off the top of your head, think how would you memoize it? I will give you a second while I think. Who thinks it should be this? Raise your hands. Anyone? Cool. Very, very smart people here. Because yes, this is incorrect. Children here are nothing more than syntax sugar for a prop named children. Child memo is exactly the same as syntax sugar for an object that looks like this, that references child memo component. So what we have here is a non-memoized prop on a memoized component. Very slow component, memoization will not work, and it will re-render with every state change. To memoize it correctly, we need to do this. We need to use memo as if we would use it on every object.

5. React Compiler and Real App Testing

Short description:

The React compiler handles the counterintuitive pattern well. Testing it on a real app with 15,000 lines of code showed no issues. The app is fully prepared for the React compiler, and initial load performance is being measured using Lighthouse.

This pattern is the most counterintuitive pattern in React, and even the most senior developers often get it wrong. However, what will happen with the compiler? Can it handle it? And the same story as before. The compiler does a really good job. The dialogue pops up instantly. No slow re-renders are happening. Another win for the compiler.

Now to the good stuff. Small examples like that are easy, but I want to test it on a real app. The real app looks like this. It's an app I've been working for a few months. It's completely new. I've fully typed scriptified, no legacy code, only hooks, and everything is best practice, more or less, because I'm a bit lazy. The app has a few pages. In total, it has around 15,000 lines of code. Not the largest app, but I think it's good enough for a proper test. Before turning on the compiler, I run a health check and ESLint rules provided by the React team. Those are the health check results. No incompatible libraries, and zero ESLint violations. And finally, I haven't done any performance optimizations there yet, exactly so I can try out the compiler for this talk. The app is as prepared for React compiler as it can possibly be.

Testing conditions. I used Lighthouse to measure the initial load and interactions performance. All measurements are five times, so I'm actually showing you the average of those. All measurements are run on production build in the mobile mode of the Lighthouse, where CPU is slowed down four times. Okay, so first question to answer, how the compiler affects initial load. First page to measure is the initial landing page. It's beautiful and actually quite long. Before the compiler, the results were like this. Almost everything is green, except for one red thing. I will fix it later.

6. Compiler Impact on Performance

Short description:

The React compiler has a minimal impact on initial load performance. However, the impact on interactions performance is impressive but requires further investigation. The compiler was able to optimize a page with a large component, but real-life scenarios with smaller components may be more challenging. Let's explore a page closer to real-life.

Now with the compiler, I have lots of memos, that means compiler is working, and here are the stats. That's not so bad. I ran it on a few more pages just to make sure, and the results were more or less the same. So some of the numbers go a little bit up, some of them are a little bit down. Nothing drastic. So I think I can add another point to the compiler and answer the very first question, is the compiler seems to have a very minimal impact on initial load performance. So that's good.

Second question, how much of an impact will it have on interactions performance? For this one, I use this page. The app is actually a showcase of a UI components library. Here we see a preview of a very large component, actually the whole settings page, and over there I have a dark mode switcher. As you can see, everything re-renders when I switch between light and dark mode. Before the compiler, the numbers looked like this, which is a bit ouch, it's a bit red. I enabled the compiler and wow, that is very impressive, and actually it's too good to be true for me because I'm a very suspicious person. How exactly did that happen? I'm not the worst developer in the world, trust me. So yeah, I need to investigate this. The answer is here. This is the code for this entire page.

The thing that renders the preview of the big components is this. The preview is sent as a string, the entire page here is just really tiny components. I literally have here the synthetic example from before, where we have a very slow component with some minor props. So I will add another point to the compiler. It's very cool that it was able to pick it up, but also, I feel a little bit like it's cheating because clear situations like this are quite rare in real life. So in real life, we will have a bunch of smallish components and the job for the compiler will be much harder. The next page is closer to real life. Let's take a look. I have a header here with some stuff, footer and a long list of cards in between. The quick filter at the top controls which cards are shown, and as you have seen, when I click on checkbox, for example, everything re-renders. So without memorization, the entire page re-renders, all the cards re-render. The stats for this one looks like this.

7. Investigating Re-rendering and Data Fetching

Short description:

The list is still re-rendering even with the compiler enabled. The code itself has an issue with memorization, and there may be a problem with the props. Let's investigate the code and the data fetching process.

The stats for this one looks like this. It's okay-ish, it's green, but there is some room for improvement. Enabling the compiler and checking the numbers is good, but it's actually more believable to me. But also, it's very interesting because I actually expected it to be better because this list is very long, and if all the re-renders in this list were eliminated, adding just a few new cards for the checkbox should have been actually instantaneous. So let's investigate what is happening here. And what is happening is the list is actually still re-rendering, even with the compiler enabled. That's not so good.

Okay, what's going on with the code? That's not so good. Okay, what's going on with the code? The first ones, nothing criminal. I just have an array of items, a map over the array, and a render card component. I even have the correct key here, so no arbitrary props, everything is coming from the data array. So let's investigate. The very first thing that I do when debugging compiler issues is to re-implement memorization manually with the classic tools. In this case, all I need to do is just wrap the card in the react.memo. And if the code is good, the existing card should stop re-rendering, and that would mean that the compiler bailed on its components for some reason. I did that, and this didn't happen. That means that's not the compiler's fault, actually. Something is deeply wrong with the code itself.

I wonder if anyone can guess, because the code is the most standard code that you can see in React. Okay, so let's solve it. As we know already, if even a single prop on the memoized component changes, the memoization will not work, and re-renders will happen. So something is probably wrong with the props here. All of them are primitives except for this one. It's an object with two strings inside. So it has to be its fault. But it's also a little bit weird because it's not like I'm recreating it inside the component every time. It's just the data that is coming from an array that is coming from a React query. So should I blame Dominic and React query then? Let's take a look at this code. This is the code that fetches the data. We all know React query now.

8. Understanding React Query and Fixing Memoization

Short description:

The React query library simplifies data fetching and caching. However, when using dynamic keys and different filters, it may result in rendering different arrays with the same data. This can be fixed by refactoring and spreading the object into primitive props, ensuring no unnecessary renders.

It's a beautiful library. I love it. It simplifies data fetching and caching. So we have a key to identify the cache entry, and we have an async function that returns some data for this key. Usually, it's just a fetch or some fetch variation. If it's called with the same key, it returns the data that it already has without doing a fetch again. So what is happening here in my case? I have a dynamic key. It depends on selected filters. And I have a fetch function that returns some data.

When only the button in the quick filters is selected, the key is this. The library that returns an array that is associated with this key. When I turn on the checkbox, the key is this. The library returns a completely different set of data that is associated with this key. It doesn't merge them together to preserve the reference to the internal objects because how would it know to do it? And I never told it to do it. So I cannot blame the React query for this one, unfortunately. All of this is my fault. React query does exactly what it should do. No one to blame, but as a result, I have a different array with different references rendered on the screen that happen to have the same data for the most part.

And one piece of this data is an object that is passed to a probe to a memoized component. The easiest way to fix it, to fix memoization here, is to just spread this object and turn it into primitive props. Sounds like this. So the memoized component receives only primitive values and those don't actually change. So a bit of refactoring and no more unnecessary renders. Okay, so I'm not the worst developer in the world. Let's make sure that it was actually worth it and let's measure it. So this was before and after the compiler. Now, the last measurement after the manual fixed. I feel it's a mic drop situation. Humans are still better than robots. They will never take over the world.

9. Compiler Impact and Limitations

Short description:

The impact of the compiler on performance is noticeable but varied. While it can solve some re-renders, there will always be cases where it cannot catch every single one, especially with external libraries. The compiler's limitations highlight the need for fine-tuning code and managing external dependencies. Initial performance and load performance showed no negative impact. Interactions performance saw improvements, although not all re-renders were solved.

I will give a win for myself this time. Okay, so that was the interactions. I think it's safe to say that the impact of the compiler is noticeable but varied from page to page and humans are still better if they really try.

Final question. Is the compiler smart enough to really catch absolutely everything? We already see that the answer is probably no. But to test it a little bit more, I collected a list of noticeable re-renders in my app and checked how many re-renders are still present after I enabled the compiler. I had something like nine of them. Stuff like the entire draw re-renders when tabs change. The end result was this. I had two cases where absolutely every single re-render was solved, two cases where none of them were solved and five cases where it was like in the situation before. Almost all of them but sometimes not.

The cases where nothing was fixed was the most interesting one because the compiler bailed on the entire component because of this line and this line only. I never even used the filtered data, I just added this line and it's just oops I cannot do it. And the problem here is that Fuse is an external library that does search for you. So the most likely reason here is this library is just doing something deeply incompatible with the compiler, unfortunately. And speaking of the external libraries, just a few days ago React team confirmed that external libraries will not be transpiled by the compiler. So don't expect miracles if you consume in some external library.

So I'm going to be cruel, sorry. I'm going to take one award from the compiler for this one. Because the answer to whether the compiler can catch absolutely every singular re-render is sorry to know. Because there will always be some external libraries that do some really weird stuff or they're just incompatible with memorization or there will be some legacy code that again does some really weird stuff that the compiler doesn't know how to process. Or the code that I had, which is not exactly wrong but it's just not fine-tuned for memorization. So let's recap quickly what we were investigating and how the compiler dealt with it. Initial performance, check. No impact, no bad impact. Initial load performance, I would say also check. Interactions, interactions performance, check. I saw good improvements there. Some of them were really good, some of them just a little bit but still really good. Can it catch all re-renders? No and probably never will.

QnA

Compiler Impact and Developer Behavior

Short description:

Enabling the compiler can make your app good enough at a low cost, but if you need optimal performance, manual memorization is still necessary. Few developers will require the level of optimization that manual memorization provides. Overall, the compiler offers positive results, improving job safety. Questions were asked about manual optimizations in large React projects and finding bottlenecks.

So the biggest question then of this year, can we forget about memorization soon? Does the previous slide mean that the answer to this question is no? Not necessarily because it really depends. If performance of your app is not the most important thing in the world for you or maybe it's okayish but could be improved but I don't have time to bother, then enabling the compiler will most likely make it good enough at a very low cost. The definition of good enough and low cost is of course going to be up to you but I suspect that for most people turning on the compiler and forgetting about memorization and all those hooks will be just enough. However, if good enough is not so good for you or you need to for some reason squeeze every millisecond out of your app, you will be welcome back to manual memorization. For you the answer will be no. You cannot forget about it. You would have to know everything that we know about memorization now. Plus on top of that you would need to know what the compiler is and what it does and how. So your job will become slightly harder but I think there will be very very few of you who would actually need it so that will improve your job safety I would say in the long run.

So it's also a good positive result for you. I hope this was good enough for this presentation. If you want to read more about memorization and re-renders and everything, here are the links. If you want to check out the very very early version of the components I'm working on, you can do it here. It's very much work in progress so please don't judge too much. And if you want really cool cat themed stickers, catch me after the talk. I have quite a few of them. Thank you. And that is the end.

Well let me pull out my little questions here. Remember you can ask questions on slide.do and let's dive right into the compiler. There's a couple questions here. So this one says what manual optimizations work best with a compiler in a large React project and any tips for finding bottlenecks? So manual optimizations work best moving state down and just isolating it as much as possible so you never have components that handle a lot of state. Also extracting state instead of passing through props into external library like something like Sustan for example and then memoizing the selectors. Yeah we have the Toka thing. Yeah. It was about finding bottlenecks. The state thing is good. Do you think people or developers are going to start changing their behavior based on what compiler is good at? We will see I guess. Because that list example you did, that was just the little component. Yeah.

Risks of Overreliance and Alternative Approaches

Short description:

People may rely too much on the compiler, leading to messy code. However, there are ways to force memoization if the compiler doesn't handle it. The re-render system currently re-renders everything that uses context, even if the props don't change. Using the React compiler might be risky for large and old apps, but enabling it file by file or folder by folder with thorough testing can mitigate the risks. Take it easy and try different approaches. The audience loved the slides.

I could see people trying. So what I'm slightly afraid of is that people will relock and say oh the compiler will just handle everything. So it might lead to messy code in the long run. But I'm confident in the group here because actually no one raised their hand on the memoization problem. I'm very impressed. Good job. Yeah.

Is there a way to if the compiler doesn't do it for some reason to force the memoization? Yeah we use the hooks and React memo. Just manual memoization like good old times. Like the good old days. Vintage. So adorable. Very nice.

How does the re-render system work when the props don't change but a context provider does? Context if we're talking about React context. Until very recently it would just force re-render on absolutely everything. Even if you don't use the data. But I think there was some talk from React team to introduce selector stub functionality but I'm not as sure. But currently it will just re-render everything that uses context. Interesting.

Can you think of any reasons to not use the React compiler? To not use the React compiler. It might be slightly scary in the very large and very old apps because who knows what the effects will be of this manual memoization. So for those apps I would just say enable it file by file or folder by folder and then do a lot of testing. Take it easy. Yeah, take it easy and try stuff. I like that advice actually. It's very sensible. This is a great one. We're going to step outside of the React compiler for a second. They loved your slides. They're very cool.

Creating Cats and Compiler Behavior

Short description:

Practice makes incredible cats. Keynote and Magic Move are used for software presentations. The compiler rarely introduces negative behaviors or bugs. Enabling the compiler doesn't require removing previous optimizations. Research process involves exploring ideas, writing articles, and rewriting them iteratively. Find me online on Twitter or LinkedIn as Advanced Dev. Thank you, Nadia!

A lot of good cats. How do you make them? Lots of practice. They're incredible. Good job. With software do you use Keynote? Keynote. Keynote and Magic Move for most of them. Yeah, Magic Move. Who doesn't love Magic Move? Steve Jobs himself.

Let's see. What else do the people have? Has the compiler in your explorations ever tried to fix something and actually introduced a negative behavior or a bug? Not for me. There probably is a possibility. I saw people saying that something happened but it's very, very rare from my understanding. And it works for like Instagram and Facebook and a few larger apps so I'm sure they found almost everything that can be. Yeah, well I would hope.

And then when you enable the compiler on your app where you've already sort of previously used Callback or Memo is it bad practice to still have those optimizations? Do we have to strip them out to use the compiler? As far as I remember you don't have to. It will just either use them or just convert them into code. So you don't have to remember them. But probably we have a React members team who remember here. So let's make sure to go ask them the really yeah really really deep questions. Sorry I'm just dropping things on you. We don't have a lot of time so I'm actually going to ask you just one more question which is what is your process for doing all these like deep dive explorations you did for your book and now for this talk. Do you have like a system of research? Do you look at the source code a lot? Do you more run it or more read it? That's like half an hour answer.

TLDR. TLDR. So I usually just have an idea that comes from doing regular stuff. Then I start exploring this idea. I start writing examples for it. Then I start writing the article and then I'm throwing away all the examples because they don't actually match the article and rewrite them completely from scratch. But then how I rewrite them I usually discover some new things so I have to then rewrite the article again. So it's like iterative. It's basically agile. Yeah basically agile.

Will you remind everyone where they can find you online on Twitter or LinkedIn? Advanced Dev. A-Dev Nadia. Thank you so much Nadia for that talk.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

A Guide to React Rendering Behavior
React Advanced 2022React Advanced 2022
25 min
A Guide to React Rendering Behavior
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Speeding Up Your React App With Less JavaScript
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Top Content
Watch video: Speeding Up Your React App With Less JavaScript
Mishko, the creator of Angular and AngularJS, discusses the challenges of website performance and JavaScript hydration. He explains the differences between client-side and server-side rendering and introduces Quik as a solution for efficient component hydration. Mishko demonstrates examples of state management and intercommunication using Quik. He highlights the performance benefits of using Quik with React and emphasizes the importance of reducing JavaScript size for better performance. Finally, he mentions the use of QUIC in both MPA and SPA applications for improved startup performance.
React Concurrency, Explained
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
Top Content
Watch video: React Concurrency, Explained
React 18's concurrent rendering, specifically the useTransition hook, optimizes app performance by allowing non-urgent updates to be processed without freezing the UI. However, there are drawbacks such as longer processing time for non-urgent updates and increased CPU usage. The useTransition hook works similarly to throttling or bouncing, making it useful for addressing performance issues caused by multiple small components. Libraries like React Query may require the use of alternative APIs to handle urgent and non-urgent updates effectively.
Optimizing HTML5 Games: 10 Years of Learnings
JS GameDev Summit 2022JS GameDev Summit 2022
33 min
Optimizing HTML5 Games: 10 Years of Learnings
Top Content
Watch video: Optimizing HTML5 Games: 10 Years of Learnings
PlayCanvas is an open-source game engine used by game developers worldwide. Optimization is crucial for HTML5 games, focusing on load times and frame rate. Texture and mesh optimization can significantly reduce download sizes. GLTF and GLB formats offer smaller file sizes and faster parsing times. Compressing game resources and using efficient file formats can improve load times. Framerate optimization and resolution scaling are important for better performance. Managing draw calls and using batching techniques can optimize performance. Browser DevTools, such as Chrome and Firefox, are useful for debugging and profiling. Detecting device performance and optimizing based on specific devices can improve game performance. Apple is making progress with WebGPU implementation. HTML5 games can be shipped to the App Store using Cordova.
The Future of Performance Tooling
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Top Content
Today's Talk discusses the future of performance tooling, focusing on user-centric, actionable, and contextual approaches. The introduction highlights Adi Osmani's expertise in performance tools and his passion for DevTools features. The Talk explores the integration of user flows into DevTools and Lighthouse, enabling performance measurement and optimization. It also showcases the import/export feature for user flows and the collaboration potential with Lighthouse. The Talk further delves into the use of flows with other tools like web page test and Cypress, offering cross-browser testing capabilities. The actionable aspect emphasizes the importance of metrics like Interaction to Next Paint and Total Blocking Time, as well as the improvements in Lighthouse and performance debugging tools. Lastly, the Talk emphasizes the iterative nature of performance improvement and the user-centric, actionable, and contextual future of performance tooling.
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
React Summit US 2024React Summit US 2024
30 min
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
Top Content
Watch video: Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
Hi folks, in this Talk we learn about React and Chrome DevTools. We explore the new AI Assistant panel in DevTools that helps with UI tweaking. React DevTools now supports Gemini AI model for error fixing. Extensibility is important and React DevTools has features like highlight updates and server components. We also learn about server logging in the browser console and toggling suspense fallbacks. Browser DevTools allow experimenting with local overrides and improving color contrast. Advanced features include overriding headers, network panel customization, and performance tooling. We also discuss Core Web Vitals, optimizing pages, and debugging UI with DevTools. There are fun tips for enhancing animations and logging workflow. The Talk ends with Q&A and sharing/removing features based on user feedback.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
Next.js 13: Data Fetching Strategies
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
Workshop
Alice De Mauro
Alice De Mauro
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
React Performance Debugging
React Advanced 2023React Advanced 2023
148 min
React Performance Debugging
Workshop
Ivan Akulov
Ivan Akulov
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
Building WebApps That Light Up the Internet with QwikCity
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
WorkshopFree
Miško Hevery
Miško Hevery
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
High-performance Next.js
React Summit 2022React Summit 2022
50 min
High-performance Next.js
Workshop
Michele Riva
Michele Riva
Next.js is a compelling framework that makes many tasks effortless by providing many out-of-the-box solutions. But as soon as our app needs to scale, it is essential to maintain high performance without compromising maintenance and server costs. In this workshop, we will see how to analyze Next.js performances, resources usage, how to scale it, and how to make the right decisions while writing the application architecture.
Maximize App Performance by Optimizing Web Fonts
Vue.js London 2023Vue.js London 2023
49 min
Maximize App Performance by Optimizing Web Fonts
WorkshopFree
Lazar Nikolov
Lazar Nikolov
You've just landed on a web page and you try to click a certain element, but just before you do, an ad loads on top of it and you end up clicking that thing instead.
That…that’s a layout shift. Everyone, developers and users alike, know that layout shifts are bad. And the later they happen, the more disruptive they are to users. In this workshop we're going to look into how web fonts cause layout shifts and explore a few strategies of loading web fonts without causing big layout shifts.
Table of Contents:What’s CLS and how it’s calculated?How fonts can cause CLS?Font loading strategies for minimizing CLSRecap and conclusion