Performance of React Bricks websites

Developers often ask us about the performance of React Bricks websites.

This article explains what are the moving parts that can impact the performance of a React Bricks website created with Next.js, Gatsby or Remix.

1. Performance of the React Bricks library

The React Bricks library, especially since v3, is created with performance in mind.
This is why we try to have the lowest possible overhead in terms of rendering performance and size on the frontend bundle.

This is quite a tough task, because the content bricks usually have our visual editing components, like Text, RichText and Image, in their JSX. These are "heavy" components that, on the Admin interface, enable the visual "magic": editable rich text fields, images that can be uploaded with a click, etc.

With some low level tweaking, we managed to have two completely separate bundles for the admin and the frontend, enhancing the components when they run inside the Admin interface.

On the frontend bundle we have just lightweight serializers for the text and images. In this way the impact on the rendering performance is negligible and the frontend bundle size is very small (__).

A React Bricks website is as fast as a Next.js, Gatsby or Remix website can be.

// IMAGE OF BUNDLE SIZE

2. Framework performance and code splitting

As you have almost no impact caused by the library code, you can leverage the performance of your framework of choice (Next.js, Gatsby or Remix). They are different, each with its pro and cons, but all of them provide code splitting at page level by default, so you have small bundles for each page and progressively load only the needed code.

As for the build and serving strategy, Gatsby supports Static Site Generation (SSG) and, since v4, also Server-side Rendering (SSR); Remix supports only Server Side Rendering (SSR); Next.js is very flexible and allows you to use SSG, SSR, or ISR (Incremental Static Regeneration).

For a small website we usually suggest SSG, so that you have predictable and stable performance, a minimal attack surface and high availability. On the other hand Remix APIs are really clean, with beautiful nested routing and you can always leverage a caching layer at the edge to avoid the server-rendering overhead at each page hit. For an e-commerce website we think ISR is very interesting, because you combine the advantages of statically generated pages with the possibility to have dynamic data with server-side rendering.

// IMAGE OF PAGE SPEED INSIGHTS FOR A RB-BASED SITE

3. A potential performance problem

The only performance problem we can foresee is when you have a very big number of bricks. Usually all the bricks are imported in the bricks property of the ReactBricks component, which is one at app level.

In this case the code for all the bricks ends up in a shared bundle that is needed for all the pages, even if one page would not use some bricks for its content. This bundle gets cached, so it is downloaded just once, but the impact on the first load could be proportional to the code of all of your bricks. Each brick is very optimized, because it has only the code needed for the frontend rendering, but if you have hundreds of bricks, you could have a bundle size which is not very small.

A first solution could be to separate the ReactBricks components based on the type of bricks used in different page types, but a better solution for this problem is coming very soon: see the next section.

4. Server components

React Server components are a way to render React only server side, without the hydration on the client. In this way you don't have JavaScript code at all on the client for these components.
As most bricks don't need client-side code (they don't have client-side interactions, as a carousel, for example), we can leverage server components to avoid shipping the bricks code at all!

Server components are now in beta, but they will be available soon and we intend to support them very early on: stay tuned!

5. Images

React Bricks optimizes images in different ways:

• It creates a small "blur-up" image to be shown while the image is outside of the viewport
• It creates responsive versions of the images to serve the best one based on the screen size
• It creates "next gen" WebP images with fallback to JPEG, GIF or PNG (based on the image properties like transparency or animation)
• It serves images from a fast global CDN

See also my article on Image optimization...

6. CMS performance

On our servers we manage just the APIs and your images. As we already saw, image are optimized and served from a global CDN.

The APIs are very fast, with response times below the 100ms for almost all the endpoints.

What's more, since most React Bricks websites use Static Generation or Incremental Static Regeneration (or a caching layer for SSR) the impact of the APIs response time doesn't impact the perceived speed of the page for the users (or for SEO purposes). In fact the APIs response time impacts just the static build process for SSG or ISR and the cache misses for SSR.

// IMAGE OF API SPEED GRAPH

Conclusion

React Bricks allows you to create a really fast and modern website using Next.js, Gatsby or Remix. Performance is a top priority for React Bricks and this is why we are already exploring server components to make them available to you as soon as possible, and further improve the load times.