Earlier in May, Facebook just released a new and extremely terrible version, called “The New Facebook”, this new facebook uses front-end completely rewritten by React and Relay.

The goal of this new facebook is to be faster, have a better interactive experience than the old version. And as Facebook said in one of their articles, they mostly work on the following two technical guidelines:

As little as possible and as soon as possible : We only process the resources we need, and we try to get them as soon as we need them.

Technical experience for the user experience : Our ultimate goal is all about the users who use our website. So we think about UX issues, and we can apply our experience to guide our engineers in doing the right thing.

Refactoring CSS

A lot of efforts have been made to make CSS more lightweight and maintainable.

The previous version of Facebook loaded more than 400 KB of compressed CSS file only when it loaded the homepage, and only 10% of it was used to initialize during rendering.

So why does Facebook have this situation? In general, this is the general status of every project: With every new feature you add, it means you need more CSS. And old CSS is rarely deleted because you’re not sure it has an impact. And finally, you have a bunch of CSS that no one wants to touch to clean up anymore.

Their solution is to run Atomic CSS when building.

Atomic CSS is a way of declaring classes so that each class only describes a single feature. To build a larger component, we will combine these atom classes.

The result is really interesting because it has reduced up to 80% of the CSS on the homepage, while the new facebook also supports adding dark mode and dynamic font size.

Using SVG in JavaScript

In previous versions of Facebook, SVG was used in the <img> , which could cause icon flickering when icons were rendered after other content.

In the new version, SVG is used in the <svg> tag, which means they are packaged and distributed with the components surrounding it. This technique can increase the load time of some components, but it ensures that there is no error flashing the previous icon and thereby increasing the user experience.

Divide the JavaScript code

The size of the code can directly link to the load performance of the website. And here we talk about Facebook, frankly, it’s not a small project and so the size of the code is very important. That’s why they developed several new APIs to follow their “mantra”:

Less is better, and the sooner the better

Following this “mantra”, Facebook designed the loading layers of JavaScript code to be divided, the JavaScript needed to initialize the render is divided into 3 levels:

1st floor

The goal here is to provide immediate feedback by rendering the overall UI part of the page being loaded. The source code for rendering the background is very small.

Floor 1 often uses the type import syntax:

2nd Floor

Level 2 includes everything that fully represents the content. After rendering, it will not change without user interaction.

If the user interacts with the page, for example opening the menu in the upper right, a frame will appear to immediately give the same response as the last time.

Level 2 uses importForDisplay . It returns a wrapper based on promise to access the module while it is loaded. As soon as an importForDisplay appears in the code, the module will be automatically moved to tier 2.

Floor 3

Level 3 includes everything that is rendered behind and does not affect the main screen. In this case, it renders the menu content in the upper right.

Level 3 uses importForAfterDisplay . It also returns a wrapper based on promises to access the module while it is loaded. As soon as an importForAfterDisplay appears in the code, the module will be automatically moved to tier 3.

Thanks to this system of Layers, the JavaScript size of a page is divided into 3 layers, the loading screen is rendered faster without compromising the user experience.

A / B Testing with UI

A common way to compare two different versions of the UI is to perform A / B Testing (try and see which version of the UI is better based on user comments – The way Facebook is currently doing). The usual way is that we download both versions for everyone, and some will use version A, and some will use version B.

But this also means that we will download the same code that is not being used, which is against Facebook’s “mantra”. That is why they build a declare for the API that when the page loads, the server will be able to check which version needs to be sent to the client.

Only provide components when needed

Usually in projects, there are complex components where the rendering process varies depending on the data. Currently, a Facebook post can have photos, videos, checkin locations, gif, bla bla …

It will be very heavy to load all components to handle all the different possible categories of a post, even if the post contains only text.

That’s why dependencies are decided at runtime, depending on the data returned from the server:

If the post has an image, it will include the image processing component. The strength of this function is that it can be used at any node needed. If the PhotoComponent is still heavy, it will be loaded by fragment, depending on its data.

Tracking JavaScript size

The cascading system and render conditions made the project “much lighter”, but then Facebook wondered how to keep the code size under control after a while? This is when Facebook introduces the JavaScript budget.

Based on technical tools, each page of Facebook has a size limit that cannot be exceeded. They create several tools to track the size of the code, and trigger alerts if it exceeds a certain threshold.

Preload data while downloading JavaScript

Many current web applications download and execute JavaScript code to render the initialization page, then fetch data from the server. By using Relay, Facebook knows that the data the page needs and directly fetches them from the moment the server receives the request. So it can render pages with complete content faster.

Data delays

Some queries will take longer to run than others. Therefore, when you view a Facebook profile, the basic information (name, avatar, …) will be fetched faster, but it will take longer to fetch posts on the timeline.

Nowadays we can fetch both types of data in a single query with GraphQL defer when data is put into a stream and will be returned as soon as it is ready, there will be no waiting time for the sentence part. The query is slower. It allows Facebook to render faster than a part of a profile page with names, avatars, blanks, and render a loading page for other content that takes more time to render.

Quick navigation

A very important point for a good UX of a web app is that it has quick navigation. Users will be very annoyed when they have to wait a few seconds after clicking for the screen to change. Facebook creates a navigation map and links the directions to the landing page to render as quickly as possible. In order to render as quickly as possible, Facebook has a mechanism that makes the client fetch content even before clicking on the link.

There will be a preloading mechanism when users hover the link. It will then start fetching the code and data as soon as the user is clicking (mouse down). Finally, there will be changes as soon as the user clicks.

To radically improve the user experience and avoid white screens, the React Suspense transition is used to always have a page rendering, either the previous page, or a new page frame.

Parallel code

There are tons of lazy loading code written in this new version, but if Facebook has decided to apply lazy load to a route, with code fetching data for that route like we discussed above, it will lead to something like this:

We need two render times to render the entire page, to solve this problem, Facebook has created files that divide the code into two parts, and the process of fetching code and fetching data is now run in parallel. Since then the rendering process runs faster.

End

Facebook has really done a great job in increasing the user experience as thoroughly as possible. As explained above, not only for Facebook, we can apply them to any client-side application. Through the article, hopefully you can learn a little more about what a big company like Facebook does on its project