I Measured React Server Components’ Performance So You Don’t Have To

Hi, everyone. I'm Nadia, and today I want to talk about React server components and performance. A little bit about me. I've been a developer for a very long time now, and for the last few years, I've been focusing mostly on front-end performance and React. I love investigating how things work in this area so much that by now I ended up with a whole bunch of deep dives and investigations, and even two books on the topic of, you guessed it, React and performance.

And if you paid attention to the conversations about React in the last few years, you probably heard the words server components mentioned in the context of improving performance. Their main promise is simple. Push more work to the server, ship less JavaScript, fetch data earlier, and your initial load gets faster. But how exactly does this happen? And how much of a performance improvement can I expect? This is what I want to find out today.

Here's the kicker, though. I can't just simply turn on and off simple server components to measure what I want. To understand what exactly server components change, we need a clean mental model of how React normally renders and fetches data. Both on the client and on the server, by the way. Because here's the fun part. We already have the concept of server rendering. And have it for years. So what exactly is the difference?

I built a single page app, your normal SPA, with multiple client-side routes and client-side data fetching as the baseline. I'm going to move this up to basic server-side rendering and explain what changes in the performance profile and why. Then to a more complicated SSR with data fetching on the server and again look into what changes and why. And finally, convert the app into the server components and show you the result. This way we will see what you can gain and what you pay when you're adding a server-side rendering to a previously client-rendered app. What can I expect if I already have SSR and my framework suddenly adds server component support? And as a bonus, what can I expect if I have an SSR-based app already and I decide to move to Next.js App Router, which is the most popular framework at the moment.

So here's my guinea pig app. I have a few pages. It's very interactive already. And for the purpose of today's measurements, I'll be focusing exclusively on the inbox page. It's quite functional already. As you can see, it even has a rudimentary editor that appears when I click on a message and it actually kind of works. Items in the sidebar are fetched from a quite fast endpoint. It takes around 100 milliseconds to execute. A list of messages is fetched from a quite slow endpoint. It takes around like a second to execute. I'm going to use Chrome DevTools today to measure the initial load. If you've never done it, open the performance profile in the DevTools, click on reload, wait a little bit and then click finish. It will give you this recorded picture. I'm going to be looking at what is happening in the network panel mostly. And the metrics I am interested in today are when the page becomes visible, which happens to correspond to the metric in Chrome called LCP, Largest Contentful Page, Paint. When the sidebar items become visible, it's somewhere here. And then when the messages themselves become visible, somewhere here. And finally, I'm going to use those settings to imitate slower devices and slower internet and disable cache network to imitate the very first time the user opens the page when there is no cache on the browser side yet.

Okay, so that's enough of a setup. Let's finally investigate and measure stuff. First, let's start with the baseline, client-side rendering. What exactly is it? From an implementation point of view, it means that when your browser requests this inbox page, the server responds with HTML that looks like this. The horror. Completely empty screen.

Completely empty screen. To transform this empty div into a beautiful page, the browser has to do a bunch of work before you see anything. It downloads CSS and JavaScript. It parses and runs the JavaScript. Then React boots, and only then you see the UI pops on the screen. And even that is not the end. After that, React kicks off data fetching. You wait on the network. And then when data comes back, React re-renders and swaps the placeholders for real content.

If I record the performance of my app now, I see this profile, which is pretty much identical to what I just showed you. And the following numbers is our performance. It takes around four seconds before the user sees absolutely anything, then another 600 milliseconds to see the sidebar, and another 400 for the messages. Which looks kind of meh. I think you would agree. In real life, however, there are multiple ways, of course, to improve it. Like reducing JavaScript, for example, and prefetching data. But the core of this type of rendering stays exactly the same.

The time when the content appears on the screen depends entirely on JavaScript. Because of this, it's not that ideal for initial load numbers. Plus, search indexing and social media bots aren't usually that happy with empty HTML as the content. So this is what kicked off the boom of SSR frameworks and static site generators for React a long time ago. The idea with them is simple. Instead of sending an empty shell and asking the browser to build everything, like it's happening here, we rendered the page to HTML on the server first. This rendering is literally just one function call and then replace. Nothing more. We just need to extract that HTML from React and inject it into the empty div like this.

If I make this change for my app, it becomes server-side rendered. Now we have some meaningful HTML. So the site becomes visible when CSS, which is a critical resource, is downloaded. And there is no need to wait for JavaScript anymore for that. However, everything else stays exactly the same. The JavaScript bundle itself is unchanged, and the browser still needs to do everything it did before, including attaching event handlers and making sure that the site is still available.

While we're waiting for all the JavaScript, the page is already visible, but nothing there that is supposed to be working actually works. There is no interactivity. This toggle, for example, there will be a period on the page when I click on it and nothing happens. This gap is the priority of the page. There is another wrinkle. Data fetching. In this version, it helps to have a little bit more flexibility. But nothing there that is supposed to be working actually works.

This toggle, for example, there will be a period on the page when I click on it and nothing happens. This gap is the price you pay for the huge initial load wins with SSR. There is another wrinkle. Data fetching. In this version, it still runs on the client as a side effect, so those two data-related numbers remain exactly where they were. But do they have to? We're already on the server, so why not fetch that there so the HTML ships with real content instead of just placeholders? That surely would be faster. This is also possible. On the server, we will need to await for this data.

On the server, we will need to await for this data. Like this, simple promises. Then pass this data to React as normal props. Then a little bit of work on the upside, which I'm not going to show you, and it finally works. Performance profile moves to be like this. The initial number, the LCP, shifts slightly to the later, since now we have to wait for the promises to resolve on the server. But the client side wait is gone, and the entire page is visible right away without any annoying loading states. The numbers for this situation are like this for comparison, which is quite an interesting picture.

However, the data fetching case is when it starts getting complicated to implement manually. At the very least, you would need to implement routing on the server and some idea of different entry points, so you don't fetch messages on pages when they are not needed. So at this point, you will likely use some sort of LCSR framework. Regardless of the framework and its implementation, the performance profile will look exactly the same. The difference will be in how the framework handles JavaScript and CSS load, and that's it.

For example, if I migrate from my custom simple solution to Next.js pages router, the old version of Next.js, the profile will change from this to something like this. It will be more JavaScript files at the same time, so it will be slightly longer CSS load and slightly worse LCP. With AppRouter, the newest Next.js, in SSR mode without any server components, it will look something like this. JavaScript load will be delayed, so CSS load is slightly faster, and the LCP is the shortest amount there. The numbers for all three with and without data fetching are this.

As you can see, the AppRouter version has the best LCP because of the delayed JavaScript, but everything else is delayed for exactly the same reason. Also, comparing the numbers like this shows how much difference the way you're splitting code and fetching critical resources can have. That's SSR, and as we can see, SSR is pretty cool for initial load. There are still two issues with it that might bother you. First, the amount of JavaScript that we download and the gap of interactivity because of it.

Do we really need all this JavaScript here? If I look at the navigation component, for example, it's mostly markup, so it's divs, links, classes, exactly zero interactivity. All of this still ships in JavaScript bundles. The only reason, though, that this code is not used by a lot of people is because it's not a JavaScript component. All of this is still considered to be React.

The only reason, though, that this code is there is because React needs to understand the entire tree of all components to construct a virtual DOM, to map the virtual DOM to the real thing you see on the screen. In any of the SSR implementations, the process of extracting this tree from the React app happens twice, first on the server and then on the client. This is where server components come in. What if we rip this component out of JavaScript bundle and then keep it on the server and instead generate some data, like a tree, from which React can then recreate the virtual DOM and start working as usual without trying to construct the tree by itself on the client?

The idea is this. What if we rip this component out of JavaScript bundle and then keep it on the server and instead generate some data, like a tree, from which React can then recreate the virtual DOM and start working as usual without trying to construct the tree by itself on the client? We will send this generated payload together with HTML, thus reducing the amount of JavaScript sent to the browser. In theory, this could be huge for bundle sizes. Imagine if this component needs some heavy library to generate this layout, for example. If it's implemented as a server component, all this megabytes of data will stay on the server and the library never makes it to the client.

In practice, we can just test it. I already migrated to Next.js app router, which is fully compatible with server components. This is how my app performance looks like when everything is client components, which means everything has used client at the very top. Everything is included in the bundle, so pretty much SSR experience, normal one. All I need to do to convert this into server components is to remove UseClient from the root of the pages and then use it on the end components that actually need interactivity, so components with state, for example. I did all of that, a bit of refactoring in my app, and then this is the result.

The static login page dropped from 46 kilobytes to almost nothing, which is kind of cool because it shows that it works. Other pages changed just a little bit. The shared chunks didn't change at all, so all the common libraries are still shipped to the client. And then the messages page, the one that I care about, also didn't change at all, unfortunately. This is pretty underwhelming. As you can imagine, this had exactly zero impact on my measurements for this page. So this is the first takeaway about server components. In mixed apps where you have some client components and some server components, server components alone may barely touch your bundle. You see real wins mostly on fully static pages where everything can be server-only right from the start.

You see real wins mostly on fully static pages where everything can be server-only right from the start. However, this is not the end of the story. There is another aspect to investigate. So remember this classic SSR flow from earlier? We kick off a fetch at the very top, then we wait for it to finish. We pass this data into React. We render to HTML and send that HTML to the browser. But what if our server could be smarter?

Technically, we don't need to wait for all the promises to start doing something else. What if we instead could trigger those fetches like here? Render and send the parts of the app that don't need this data right away. We call it critical path. When the sidebar data arrives, render the sidebar items and send them. And then do exactly the same thing for messages. What I describe is exactly what you get when you combine the idea of server components with streaming. From the implementation point of view, it looks like this. We have server components, and those can be asynced now.

So this code turns into this. And also it becomes completely valid and actually recommended for data fetching because otherwise it will not work. Also, instead of this synchronous wait for everything, the server uses a render-to-pipeable stream. Which is compatible with Node streams to emit HTML and server components payload in chunks. As soon as each chunk is ready, there is no need to wait for promises anymore. They are emitted to the browser. As you can see, the data fetching disappears here completely. It now lives in the async component. This is exactly how it works in Next.js app router, for example. It's just hidden away from us.

All I need to take advantage of this fancy implementation is to do a bit of refactoring on my side. First, as you already saw, I need to get rid of all the state and all the loading. And make the component async and fetch data directly in the server component. Second, I must ensure that this component is truly a server component, and this part is the hardest. So React UI, as you probably know, nested trees. So my app, for example, it has a layout sidebar that composes inbox page, which has a bunch of components including content and so on and so forth.

If I put UseClient anywhere at the very top of this hierarchy, all those components become client components. And client components cannot be async and cannot fetch in the render body without causing infinite loops. So when rewriting data fetching, I need to be very careful not to accidentally turn any of the components in the hierarchy into the client components. And finally, I need to wrap parts of the app in a special component called suspense. Suspense boundaries are how React decides the streaming chunks. Without them, React treats the whole tree as one critical chunk, waits for everything, and you end up with the same blocking profile as we had in classic SSR.

So let's say during my migration, I forgot about suspense, which actually happens quite a lot because not everyone understands how all of this works. The end result will be exactly the same as I had with SSR mode when I fetched the data at the page level. If I add suspense correctly, it magically transforms into this. The recorded profile would look like this if I stretch it a little bit more with slower endpoints. Otherwise, as you saw, it's exactly the same numbers because probably Next.js or React batch those chunks together if they are pretty fast. So you see how HTML bar runs almost to the end of the trace. This is the server that I'm using. HTML bar runs almost to the end of the trace. This is the server that holds the connection open and piping chunks as each boundary guarded by suspense becomes ready. Those are all the numbers together within the same framework for comparison.

And let's now finally pull all of this together. So client-side rendering. The browser gets an empty shell, downloads a bunch of JavaScript, bootstraps React, then finally fetches data. Performance is underwhelming in this case. Simple server-side rendering improves initial load numbers by a lot, but nothing else. Plus, it introduces a gap when the UI is visible, but still not interactive. Fetching data on the server-side can drastically shift those numbers, but at the cost of degradation in the initial number. So it will be slightly important. The gap remains intact since no JavaScript changes.

Then adding server components to the mix. Bundle size reduction is underwhelming as well and likely will be like this for any mixed up with server and client-side rendering. The only time the bundle is significantly reduced is for the pages that are very static with very little interactivity. The actual wins with server-side components show up when you re-architect the entire app to fetch data server first. And this is the crucial part. Don't forget about suspense to enable streaming. This is where the performance profile radically changes. You start sending useful HTML early and you keep the connection open to stream in the rest of the chunks. Chunks are guarded by suspense, as I mentioned, and nothing more.

It's not enough to make components asynchronous to see any performance improvements. Whether it's worth the effort or not, of course, it's up to you. If you want to read this entire investigation in more detail and play with the code yourself, I actually have it in a form of article. So please check it out. Thank you for listening. Hope you enjoyed the talk. And if you have any questions, feel free to reach out. I'll try my best on any social media. Thank you.