LogoJuan Manuel Allo Ron

What's all the hype about React Server Components?

By Juan Manuel Allo Ron on Jan 7, 2021
A typical loading sequence for a web page

A couple of weeks ago the React team announced React Server Components. In this article today I will explain what it is, why they came up with this strategy and how to get prepared for it.

What’re React Server Components?

TL;DR: React Server Components is a new experimental feature by the React team to support progressive hydration by allowing component to be rendered exclusively on the server, client or both.

By splitting the component tree between Server and client the amount of JS that needs to be loaded in the client can be reduced and also latency to fetch data could be improved (by running part of it on the server). This should improve the loading experience a tenfold (Or at least to numbers that are hardly achievable with React these days)

You should check the official demo from the React team and read the RFC to learn more about them. There are also 2 other articles I recommend to get different perspectives:

What is trying to solve?

TL;DR: Performance!

There are 2 main performance bottlenecks in today’s JS based websites/apps:

  • The resources footprint to be able to serve and make a page interactive is usually high. Any JS, CSS and images that the page needs to download will impact loading performance. A healthy budget should be 250 kb or less (and just React, reat-dom and apollo-client can get you close to the budget!)

  • The latency and roundtrips to fetch data and render it also depends on the conditions the user is in when browsing. Even with the optimal conditions you have a waterfall sequence to load a page:

    1. Page request, serve initial HTML (mostly empty unless who have traditional SSR in place)
    2. Load all the assets from server/CDN. This includes JS, CSS, Images, etc
    3. Parse and execute the JS.
    4. Make an API request to fetch the data
    5. Render the data

Let’s see this in more detail with an example:

I took Imgur as an as an example for illustrating this common problem, but most of the websites using react will have a similar loading pattern. For the example I am loading https://imgur.com/ and running a performance trace.

Loading page sequence

Loading sequence

In the loading sequence we can see that there are empty frames. These reflect the time the critical resources (JS, CSS, images, etc) took to download + the roundtrip for the main API call. We can see that in more detail below:

Loading page trace

Performance trace showing initial loading sequence

The Performance trace above shows the common loading pattern in React Applications:

  1. Get Initial Request from Server. If traditional SSR is used then this will result in longer time for the server to return the request
  2. Load critical Assets (JS). We need to load all the JS before starting to fetch content and render.
  3. Make the main API calls. Depending on the amount of JS downloaded this call(s) can be deferred quite a bit
  4. Render the results. Depending on how much content is needed this could be costly.

To solve this problem we need to 1) reduce the amount of resources we need to download upfront 2) Make the API calls ASAP and reduce the roundtrip as much as possible. There are multiple ways to tackle this problems but Server Components could simplify and empower lots of these strategies.

Why not just regular SSR?

Regular SSR is a good alternative to scale how to build SPA apps. It can help reduce the latency to fetch data from APIs (as both run on the server). It can also help scale rendering as it does not depend on the browser features and device conditions.

The downside of SSR is that it requires a balance and it is hard to get it right. If we automatically decide to fetch and render the whole app in the server, then the Time To First Byte (TTFB) will increase and loading performance would not change that much. Users will instead be seeing a blank screen longer until the whole app is loaded.

This can be balanced by hand picking which data to fetch and render in the server and which data in the client but it becomes more challenging to get it right. It could also affect your cumulative layout Shift (CLS) and we all know that users hate to see the content flickering while they are trying to read or click on something.

Finally, traditional SSR still requires the whole React tree to be hydrated in the client. In this process React re-builds the “virtual” tree and compares that to the rendered tree, makes sure everything looks correct and adds listeners to make it interactive. There are 2 main downsides of this process:

  • Hydration can be costly and differences on server & client trees can cause unexpected bugs.
  • The JS needed in the client does not change. Without doing any advanced optimization to enable some progressive hydration you still need the same JS resulting in poor Time To Interactive (TTI) numbers.

Here is an article from Addy Osmani that explains the cost of client-side rehydration in more detail.

Why not just [JAMStack]](https://jamstack.org/)?

Going into a more offline/deploy-time rendering strategy and serving static content is a perfectively valid strategy that can take you there but it won’t cover all the scenarios in the spectrum. Highly interactive sites won’t be able to execute this strategy as easy as other more static sites like blogs.

In the end Server Components could even help this strategy further, as it provides more flexibility to define how granular the interactive pieces of a page should be.

What can I do to get prepared?

Server components are not there yet and if we take past examples like suspense to estimate when it could become generally available then we should probably be prepared for not seeing this widely adopted in 2021.

In any case here are some steps you can take today to align with the Server components strategy:


Catch up with me on Twitter:@juan_allo

Development
Javascript
Js
Performance
React
React server components
Ssr

Share

X Facebook Y Combinator LinkedIn Reddit Email

---

Similar Articles

Image Slideshow example

Lazy loading images with Intersection Observer

May 26, 2020
Images play a huge role in loading performance. Websites loading tons of images upfront can be paying a high price in terms of user experience…

Weekly Digest #10: On Remix, Snowpack, Rome and Web-vitals

May 24, 2020
The never ending flow of innovation is what I love about the web. There are so many great ideas! In the past few months a lot of innovation happened and in this weekly digest I want to share the most important ones.
React Logo

Learning Path: Getting started with React

May 19, 2020
In this post I want to share some resources that helped me learn React and I hope they are useful for anyone starting out there.
A book cover with JS books as the title

Weekly Digest #7: On Javascript books

May 3, 2020
Whether you are learning JS from scratch or have been working with it for a while now, I believe you will find great value on the following list of books.

@2023 Juan Manuel Allo Ron. All Rights reserved