Next.js: Reshaping Web App Architecture for Performance Excellence

Hello, my name is Myrna Sochnaeser and I'm a lead full-stack developer at L'Oreal Tech Accelerator. Tech Accelerator is an internal department dedicated to driving digital innovation at L'Oreal. We design apps to help L'Oreal staff be more productive.

Today we are going to see how we reshaped our web app architecture for performance excellence and why we decided to use Next.js. At L'Oreal, there are some factors that let us define if we have a good application, like performance, accessibility, security, etc. But today we're going to focus on performance which indirectly also lets us improve our user experience.

At Tech Accelerator, we have an architecture that all our applications rely on. Our browser will try to fetch the data or the information, the files it needs from the CDN. If you do not succeed, you will go get them from the two applications hosted on App Engine. Our backend containing all our endpoints is hosted on CloudRAM and the data is hosted on Cloud SQL. We will try to replace the two applications hosted on App Engine with Next.js and have only one application.

Let's refresh our memory while checking the different renderings we can do with Next.js. Next.js is a framework that lets us create a web application where parts of our code can be rendered either on the server or on the client. This is why we talk about client-side rendering or pre-rendered on the server. And even the pre-rendered on the server is divided into many types like server-side rendering or static-side generation or others. We at first had a single page application where we needed to download one HTML file and one big JS file for all the applications. The HTML file was almost empty and the bundled contained all the information needed. But with Next.js, we will have an index.html in the chunk or bundled.js file per page. And these files will only contain the necessary to render this specific page we are at.

How does the client-side rendering work? After building our front end, we will get two files, the index.html and the bundled.js that was stored into the CDN. Once we try to access our application, the browser will go get the index.html from the CDN and then we will download, the browser will download the JS file and execute it. And once the execution is done, the web page will be visible to the user. But we will still need to go fetch the data from the server to fit the components with the correct data and remove the loading state. So in resume, we will have a white page until we download and execute the bundled.js and the loading page until we fetch the data that we need.

With the client-side rendering, we reduce the server load as the server only needs to provide the initial HTML and JavaScript file and to also simplify the backend logic because the server will primarily act as a data API leading to a cleaner and simpler backend codebase. But on the other hand, we have a slower initial page load since the browser needs to download and execute the JavaScript before rendering the page or displaying anything.

As for the server-side rendering, the browser will get the HTML file from the server. The HTML file will be filled with the correct data. We can directly see the components filled with the correct data on the browser, but they will not be hydrated. The interaction with buttons with links won't work until we fetch and download the JS file from the CDN.

We can see that the white page block is reduced and we can directly see something on the web app. So with SSR, we have a faster initial page load and we have a better performance for users on low-end devices or a slow internet connection since most of the rendering process is handled by the server. But on the other hand, we increase the server load especially when dealing with a large number of simultaneous requests, impacting server response times. And we reduce interactivity as additional requests may be needed to update the page content. So SSR is perfect for content websites.

The static site generation is like server-side rendering, but with a small difference that both index.html and bundle.js are created on the build of the application and stored into the CDN. So we display an interactive page very fast. You should use static site generation with Next.js when you want to provide faster page loads and upload pages with heavy content or content that will never change, that are static. Like for example for blogs, for documentation, for portfolios, etc.

This being said, I'm going to give you some context on the application we want to improve in terms of performance. The application is a single page application and we have three types of pages. We have the homepage that is the same for all users and that is static, a page to visualize the data, and a page to create data based on a preset configuration and API algorithm. The application is used by 40 users in six different countries and we have a little bit more than six gigabytes of data. On this application the user has approximately a two-second white page. This is due to the fact that in order for the web app to be visible and actable, the browser needs to download the JS file and execute React. But since the JS file is big, the download and execution of the file took a little bit of time. Once the user started seeing something on the web app, it was the loading state for a certain period of time depending on the page he was looking at.

The solution for us was Next.js. Next.js streamlines the process of dividing the index.html and the bundle.js file into multiple ones per page, providing automatic code splitting. This approach helps improve the initial loading state of web pages, providing a faster and more efficient user experience. So here for example we can see some numbers we had we made in our book. For the home page we had a two second white screen and now with the static site generation that we added on, like where we modified our home page to use this type of rendering, we have an instant display on the web app. For the data visualization page we added server-side rendering and before with a single page application we had a five second loading state where we had seen the page but it was loading the data. Now since we are doing all the implementation and fetching the data on the server side, in less than a second we will display the data. Concerning the creation of a new data page, it's still in progress. We didn't work on it yet but we are going to use the client side rendering for it since there will be a lot of interactions between the users and the web app. In conclusion, with Next.js we can improve the performance of our applications since we have automatic code splitting and different types of rendering that we can put on the different pages. But if we do not use the rendering in the correct way we might decrease the performance of applications. So we need to think more of how to do the renderings.

That's it, thank you!