Scaling React Performance: From Basic to Advanced Code-Splitting Techniques

Hey everyone, I'm Gil. I'm a performance architect at Wix, and today I want to walk you through how we use various code splitting techniques to improve the performance of Wix websites. Code splitting allows us to break down JavaScript into smaller chunks or in React into multiple components, and load them only when necessary, ensuring users download only the code they need. By applying these techniques, we significantly reduce the JavaScript sent to the client side, leading to major improvement in user experience.

As I mentioned, I'm a performance architect at Wix, which means my focus is on improving the performance of millions of Wix websites. Since we use and rely heavily on React, a significant portion of my work involves debugging the performance of React applications, because essentially every Wix website is a React application. Given the vast range of features Wix websites offer, code splitting is absolutely essential for us. The techniques I'm about to share have made a huge impact. But before we dive into the specific code splitting methods, I'd like to explain how we measure performance at Wix. In production, we measure performance using Core Web Vitals, a set of metrics developed by Google to assess the performance of live websites. Specifically for JavaScript loading, we focus on INP, which means interaction to next paint, which evaluates the website's interactivity. In the graph, you can see the INP scores for Wix and our competitors reported by Google. Since interactivity is closely tied to JavaScript loading, reducing the amount of JavaScript significantly improves INP. When a website loads more JavaScript, the main thread becomes more occupied with parsing and executing code. This leads to delay in user triggered events, like, for example, clicks and hovers, which in turn negatively affect interactivity and INP. So as you can see in the graph, we significantly improved our INP scores, going from a very low score to achieving one of the best INP scores compared to our competitors. This improvement is largely due to the code splitting techniques I'm about to share with you today.

Now, let's dive into the various code splitting strategies we use to minimize JavaScript download in our React applications. The first one is dynamic import, and there are a few ways we use dynamic imports in our React application. So the most basic way we use dynamic imports is loading React components dynamically after interaction with React Lazy. Let's see a short and basic code example for this. So as you can see, we're using dynamic imports, and we're using React Lazy. And this is, of course, to not bundle, in this case, collapse component into the main bundle because we do want to load it only after the user opened some other component. So we're using React State to handle the state if we should show the component or not. And then based on the state, we render the component, the Lazy component with suspense, and only then, only when the component is rendered, React will load and hydrate the component because we're using React Lazy. So suspense have a fallback, and it's important because the component is not shown until it's loaded. So we do need a fallback for that. But then React will render the component. So a very basic example. I'm sure many of you already know this.

So let's go to a little bit more. Let's move on to a little bit more advanced examples. The second example, which is similar but a little bit more advanced, is conditionally loading components on page load, not on user interactions. So again, the example, this example will be of a comment section in a product page. We only want to show the comment section only if there are any comments. So we want to conditionally load the component. On page load, it's not on user interaction. So the product page will again use the states, now the comments data, and we can, using the use effect, we'll fetch the comments data and then put it in the state. And then if there are any comments in the comments data, if there's anything in the array, we want to render the comment section. So when the page loads, we want to load and hydrate the component only if there are any comments in the comments data. So a little bit different than the examples before, but still similar. It's worth mentioning that if you're using server-side rendering and we are using SSR in our application, this method was not supported in React 16. It's only supported in React 18. It wasn't supported before React 18. What wasn't supported is actually the fact that suspense didn't work in SSR. It only worked in client side. Now it works in SSR, and we can use this method only also for SSR. The example for SSR is a little bit different because here we use use effect, which only works in the client side. So we will see the full server example later.

And the last example I'm going to give for dynamic imports is actually load React components dynamically on scroll or hover interactions with suspense. Now the difference between this and the first example is that those components are already rendered with SSR. If they are not rendered with SSR, it's the same exact example. But since those components are already visible from server-side rendering, we just want to download and hydrate them with suspense. So this is why it's getting more complicated.

And just like the other last example, it's not possible before React 18. It's only possible with the new suspense in server-side rendering. So let's see this example. This is not a full example. I had to remove some code, so it will make sense to show it. But I will put the full example in the comments of this presentation.

So again, we're using react-lazy with dynamic imports. And we have a component under default. And we want to render it only when it enters the viewport. Again, like I said before, it's already visible and rendered. The HTML includes this because it was returned from server-side rendering. But we just want to download and hydrate it when it's in the viewport. We don't want to download it when the page loads. So we create a promise which actually resolves when the component, when a ref enters the viewport. We use interaction observer.

And now I created this download on viewport wrapper. It creates a ref, which we put on the main div. Because then we use it in the intersection observer. And now I create a promise with the resolver and a promise. And I pass this promise to a viewport and the wrapper. I'm going to show it in a second. But I resolve the promise with the intersection observer I just created.

So I have a promise which resolves when the intersection observer callback is called, basically when my component enters the viewport. So now the tricky part. I use the viewport and the wrapper, which calls a function called use, which you cannot see the implementation here. I did it. It's kind of complicated implementation, which uses the new suspense API from React. But React, it's not very well documented, if at all documented in React documentation. But they did say and posted the documentation in React 19. So in React 19, you will be able to use this function. So if you can, you probably want to wait for React 19 to use the new use implementation. But if you want to use it in React 18, you can. And we did use it in React 18. And I will put the full example, again, in the comments.

But for now, just trust me that this use function works also in React 18. But just you have to use the suspense API. So again, this use function is used to only manage the promise. Wait for the promise to resolve. And only after it's resolved, render to children, which is actually our components on the default. So again, the suspense component is rendered. And at the beginning, that promise is not resolved. It's actually waiting to be resolved only when the components enter the viewport. And only when it's resolved, it renders to children. The suspense actually manages this promise. So more strategies we use in code splitting besides dynamic import.

One big thing that we did to move JavaScript away from the client side, to not load JavaScript in the client side, is to move props calculation to the server side and fetch them in the React component. Instead of calculating props in the React component, we move them to just function in the server side. And if you want to know more, you can see my talk from last year's conference, which I talked exactly how we did it and the full architecture of the solution.

But actually, now we used to do it way before React 18. But now in React 18, you can do it actually way more simpler in a server component. So I want to show a simple example for this. It actually will work not only in Next.js, but the most basic code is actually in Next.js, because Next.js implemented the dynamic API, which is very easy to use. You can use in the new suspense API, but it's more complicated. But using dynamic API, it's very simple. You just basically use dynamic imports with the dynamic API. And this example also combined rendering conditionally components in SSR and also calculating the props in SSR.

So imagine I have a button, which can either render a link or a custom or an icon button. Depends on some type that it gets in the prop, so conditionally rendering React components. Then you can choose which React component you want to render. You calculate the props. Maybe it's a complicated function you don't want to download and run in the client side. Then basically you just render the component, and this is a server component. So React will only download and render the component you actually want to download. And again, it's a great way to do code splitting and actually only download the code you want in the client side and do the heavy calculations in the server side.

So to summary, the main code splitting strategies we use in performance are like I said, dynamic imports, which means dynamically load and render components with React lates in suspense and moving JavaScript to the server side, which means both conditionally rendering components and calculating components props in the server side. You can either do it in the old way, just fetching the props from the server the way we did it, or use the dynamic API from Next and use the server components and doing there. Either way, all those options will save you a lot of JavaScript code in the client side and will make your users much, much more happy.