React Server Components: Elevating Speed, Interactivity, and User Experience

Hello, everyone. My name is Aurora. I'm a web developer from Norway, and I work as a consultant at Enmeta in Oslo. And I'm excited to speak today remotely at React Summit US, because I'll be teaching you how to elevate speed, interactivity, and user experience with React components.

And I'm going to be coding something inspired by a feature I've built for my current consultancy project where I'm actively using React components. So this is a project task manager sort of thing. And the setup here is the Next.js app router. And then I'm using Prisma as my ORM and an Azure SQL database, and Tailwind for CSS.

And what you'll notice with this app is it has a very slow initial load here. And that's because I've slowed down the data fetches on purpose. But once the app is loaded, it's actually not that bad. I can navigate between these tabs very slowly, and I can search here using a simple form, using a get request to push params to the router. And this is all server components, which means that there is no JavaScript shipped to the client for these components. And it's just HTML and links and a form. And things work actually without JavaScript. This is a good base case because it will work even if we are on a device with a low processing power that can't run JS effectively.

I'm also going to review the Lighthouse scores for this application. So as you will see, corresponding to this low initial load, I have a first contentful paint, large contentful paint, and a speed index that are on 3.5 seconds, which is not very good. And you can see the impact of these here. And that's because, as you can see in the film strip here, I'm loading. I'm waiting for all the server components to render on the server before I'm showing anything. However, because of that, I also have a cumulative layout shift of zero. So that's really good because there's no visual instability here. And a total blocking time of zero because there's no JavaScript to block the loop here. So the overall metrics are pretty bad, but not the worst because we have a good TBT and cumulative layout shift. But of course the app doesn't feel very good.

So let me also just quickly review the code here. And the most important component is the layout here. And it's a server component. So it can be async and it can asynchronously fetch the project information and the task summary from my database here.

And I'm just bringing the database. And it's also been slowed down and using some cookies to make this dynamic. And this is now being used to render a project information, some status tabs. And then I also have a children property here, which is corresponding to my page TSX inside the dynamic. And this is using the tab and the search to directly inside the server component, query the database and get the filtered results here. So again, this is dynamic requests. If it had been static, it would be really easy. But since it's dynamic, we want to, or we have to await it at runtime on the server here.

So basically what I want to do is elevate the speed, interactivity and user experience of this app and improve the web vitals that are bad without worsening the good ones. And let's begin by improving the user experience of these tabs because they don't navigate right away. The reason for that is that we're waiting for the server component to finish rendering on the server before we can navigate. So to fix this, I will use a suspense and it will allow me to unblock the page and render a fallback. So I'm going to make an implicit suspense with a load TSX file here. And I'm just going to leave a simple skeleton. And now I'm rendering a suspense boundary here and I can freely navigate these tabs while waiting for the server component to stream in. So that's good now. However, I'm still blocked on the initial load here for those three and a half seconds. And that's because in my layout, I'm awaiting the project and the task summary. And I'm actually running these sequentially even though they don't depend on each other. So the first thought here might be to run them in parallel using promise all and that would help we would still be blocked on the initial load by the await here. So let's push the data down to the components that's using the data. So we're going to cut this and leave it inside the project info. Remove the props and just put it here. Like that. And then I'm going to do the same for the task summary. Get rid of this and leave it here and import that. And I'm still going to be blocked until I put a suspense boundary here around this dynamic data. So I'm going to do that by just getting a simple div that says loading, and I'm going to put this also around my status tabs here. And what you will see now is that I've been able to unblock the initial load with these suspense fallbacks and stream in the server components as they complete. And each component is now responsible for its own data, which means they are now composable.

And we're also utilizing the shared compute load between the server and the client by doing it this way. And we can show something on the screen while waiting for the server components to load. Now, how maybe you're noticing that I'm getting this visual instability here, and that is cumulative layout shift. So I can actually see that I have a cumulative layout shift of 0.06 now, whereas before it was zero. And that's a very uncomfortable user experience. So that means I have to size my loading fallbacks correctly to correspond to the content that's going to be streaming in. So I can just copy this component. I've actually made some skeletons already here. I'm going to import these skeletons. And they're sized correctly. So now I have this nice fallback that doesn't distort my view here. And we're back to a cumulative layout shift of 0 here.

And as you can see, by streaming in the server components as they complete, I actually have reduced my largest Contentful Paint and my first Contentful Paint to 0.1, which is the product information here.

Let's continue by improving the user experience, because we're still getting this uncomfortable full page refresh on the search, and we're not seeing the current active tab. So I'm going to go over to the status tabs. And I'm going to get the params from the use params hook from your JS and use the tab of the params as, and I have to make this a client component now, because I'm trying to use this hook.

So use client, but I'm getting a problem, and that is that I cannot have an async client component. So I'm going to remove the async. But now I can no longer await my task summary. So I guess I have to put that back into the layout. Just put it here. But this would, again, block me from getting this fast initial response time from the server. So instead of awaiting it, I'm just going to leave it unresolved and pass it down to the status tabs as a promise. I'm going to call it task summary promise. Here we go. And now I can add this promise to the props. And I will use the React 19 API use to resolve this promise inside the client component and allow it to be suspended in the same way as before. So that I can still now get this nice suspense boundary and stream in the component, and I can also see the active tab in this client component and navigate between them.

The next task here would be to fix the search. So in the search, I'm going to add a progressive enhancement to this Node JavaScript base case with an on-change handler. We're going to need an event, and we're also going to need a couple of other things here. The params again, and the search params this time. Search params from Next.js, use search params. And we're going to need the router. Use router from Next. Navigation. And I'm going to use the search params to create a state in the URL here. So I will create some new search params and push those to the router change. So we're using the state as our single source of truth. I'm sorry, using the URL as our single source of truth for this filtering here. And then I'm going to also import the params and use these to reset the form when tab changes by binding the key to the tab. And I also need a default value of just input field to be the search params with a query.

And again, I have to make it a client component because I'm trying to use client side stuff here like hooks. So notice what you will see here is that when I try to search something, I'm getting this on change, but I'm not getting any instant feedback because the router, the way it works, it's going to route after whatever is on the page is done resolving, which is this slow table server component. And to at least track the state of this navigation so that I can see as a user that something is happening, I'm going to use a transition from React 18. And it will let me mark something as a non-blocking transition with start transition. And it will also return to me a pending state of that transition. And I can wrap my route routing with this transition and use the pending state to enable a loading spinner here. So that when we are transitioning to this new page, we get this loading spinner showing us the state of that navigation. And because this is a progressive enhancement, that means that if this form is hydrated by JavaScript, we will have this unchanged run and otherwise it will just be a simple form.

I'm going to add in another component here, actually, because I also want to have a category filter here. And this component takes in a categories promise, reading it with use the same way that the status tabs is doing. And I'm going to get this here inside the layout. So the categories from getCategories here. Oops, should be const. And I'm going to pass this down. And I also need to suspend it again so that I don't block the layout here. So I'm going to add a suspense and just fall back to a simple disabled toggle button.

And then I'll hopefully be able to wrap this correctly. Input the toggle button. And let's see what it looks like. I have this loading and then I have this toggle button group here for the categories. But again, when I click these, I don't get any feedback, and that's because we're waiting for the server component to finish fetching data from the database with the correct filtering. So let's at least add a loading state to this category filter. We're going to use a transition, again, the same way we just did from React 18. Add a transition around the routing. And we need to use asPending somehow. But it's not that straightforward because I don't want to make this button spin or anything like that. That would be a bit excessive.

So instead, I'm just going to use it to add a data pending attribute to this div if it is true. And in my layout here, I actually have a class of group on this div wrapping everything. In the tab, I'm using a pseudo class has to do a pulsing animation if the group has a property or an attribute of data pending. I'm using just CSS instead of a global state provider here. So now when I'm toggling this, I will see a pulsing effect here, letting me know that something is, in fact, happening inside the application. So that's nice because I can show the sale content but also let the user know that there is a transition ongoing.

But I'm still not happy with the tabs because I would prefer them to be more interactive naturally. So to solve this, we will use the React 19 hook, use optimistic. And it will take in a state to show when no action is pending. And we're going to put this truth from the URL here, the search friends there. And it will return then optimistic categories and a function to set the optimistic categories. We can use this as our selected values. And we can set them before we push to the router.

So these are the optimistic categories here. And now let me just refresh here. What will happen is use optimistic creates this optimistic client state that is thrown away when it settles to the truth of the router here. Which means that our categories are instant and they don't depend on the network. And the credit goes to Sam Zelikoff with his post on build UI for this pattern. It's a really nice pattern.

Now there is another thing I have to fix because when I introduced the categories, I'm calling getCategoriesMap here. And I'm actually also calling it inside the task summary to be able to map it to the correct categories here. So I'm calling this function twice. And if you refresh, you can see here it's being called twice. And that's not optimal. So what I can do is I can head over to this function and wrap it with another React 19 API called cache. This is a higher order function that will allow me to reuse the return value of this. And it should be not there, but here. I'm going to import it. And it will now deduplicate this request since it's being called twice in the same render.

And I don't know if you saw that, but the load time actually went down from 2.7 to 2.2. And it's only being called once now inside the console here. And I'm deduplicating this request. And what this means as a developer is that we can keep using our common pattern of testing data inside components similar to how we would do, for example, with TensorQuery in a client-side app, which is nice. Let's do like a final demo here. I'm going to remove my filters here so you can see a few more things.

I'm going to remove my filters here so you can see a few more things. And just remove the search field here. So now when I load this app, I can see content right away and I can even interact with the tabs while waiting for the server components to finish rendering on the server and streaming in. And I can even interact with my filter here while doing that. And I can do a search. And I can reload the application and have the exact same state because of the URL being our single source of truth here, which means that the state of the app is reloadable, shareable, and bookmarkable. And this is actually quite robust because we've been progressively enhancing the no JavaScript-based case and just added a low amount of JavaScript where we need it. And there's no use effects or use states in this application because we're making interactive apps without it in this new world of React Server Components.

Finally, let me just review the Lighthouse scores. I just ran this because it takes a little bit of time. I just ran it before the talk. And I've been able to improve the first Contentful Paint and the last Contentful Paint by instantly showing this project information header. And the speed index is also a lot better because it's incrementally showing more and more content. So even though we have slow data fetches, we're getting really good scores there. And the total blockings time is still zero, which is good, corresponding to our responsive clicks and low amount of JavaScript and no long tasks. And we still have a cumulative layout shift of zero because we sized our suspense boundaries correctly. So we greatly improved the performance, getting a 96 Lighthouse score even with a 2.2 second load time application, which means we managed to complete the task of improving these bad metrics and maintaining the good ones while also making the app fast, interactive, and user-friendly.

So that's it for this talk. The code is pinned on my GitHub. And you can follow me on Twitter if you're interested in more RSC content. Thank you for listening.