Shulou(Shulou.com)06/02 Report--

This article mainly introduces "what are the advantages and disadvantages of SSR". In daily operation, I believe many people have doubts about the advantages and disadvantages of SSR. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful to answer the doubts about "what are the advantages and disadvantages of SSR?" Next, please follow the editor to study!

I. introduction to SSR

SSR (Server-Side Rendering) is not a novel concept. For a long time before the front and back end layering, it was mainly rendered on the server side (JSP, PHP), generating complete HTML pages on the server side.

Extracted from 6 front-end rendering modes such as graphic SSR

The reason for completing component rendering on the server side is that it has the advantages of performance and accessibility.

Two. 2 major advantages

Performance

Compared with the CSR (Client-side rendering) mode, the performance advantages of SSR are reflected in two aspects:

Network link

It saves the network transmission overhead of the client's second request for data.

The network environment of the server is better than that of the client, and the communication path between the internal servers is shorter.

Content presentation

The first screen load time (FCP) is faster

Browser content parsing optimization mechanism can play a role.

On the network link, the interface request is issued by the server, and the returned data is transmitted to the client at one time along with the HTML response content, which is faster than the CSR secondary request. And the server network transmission speed is faster (can have more bandwidth), the communication path is shorter (can be deployed in the same computer room), and the communication efficiency is also higher (can use RPC)

In terms of content presentation, CSR's HTML is mostly an empty shell:

My Awesome Web App

When the client gets this kind of HTML, it can only render a blank page immediately, and meaningful content can only be presented after the second request data is returned, while the HTML returned by SSR has content (data), and the client can immediately render meaningful first screen content (First Contentful Paint). At the same time, static HTML documents allow browser optimization mechanisms such as streaming document parsing (streaming document parsing) to play a role.

The key difference is that SSR does not rely on the client environment, including network environment and device performance. Even if the user's network condition is poor (weak network) and device performance is poor (cheap, old equipment), server-side rendering can also ensure a similar content loading experience with the optimal user environment (Wi-Fi network, high-end devices).

Accessibility

Accessibility (accessibility) is understood in two ways:

To people: old, special user devices, such as disabling JavaScript

For robots: crawlers, etc., typical, search engine crawlers

The former generally need not care too much, while the latter should pay attention to two major "customers":

Search engine: SEO

Social media: grab page content to display thumbnail information (such as Twitter cards, etc.)

For PC sites, it is of important commercial value to ensure that search engines can correctly index and accurately understand the content of the page (the search results are at the top and the exposure is greater). Although the mobile end does not need to consider search engine crawling, there are similar social sharing needs. Social media will grab the pictures in the target page as thumbnail information.

P.S. Admittedly, some search engines can crawl SPA with heavy CSR correctly, but not all of them, and a large number of social media only extract part of the content from the response HTML as thumbnail information, so there is a real need to dynamically render HTML (part) content.

Despite these advantages, SSR is not as widely used as CSR because SSR is faced with six difficult problems.

Three. 6 difficult problems

Problem 1: how to use stock CSR code to achieve isomorphism

In order to degrade, reuse, and reduce migration costs, a set of isomorphic JavaScript code running across the client and server is usually used to implement SSR. However, in order to make the existing CSR code run on the server, many problems need to be solved, such as:

Client dependencies: there are API dependencies and data dependencies, such as JS API such as window/document, device-related data information (screen width, height, font size, etc.)

Lifecycle differences: for example, in React, componentDidMount is not executed on the server side

Asynchronous operation is not performed: the rendering process of server components is synchronous, and setTimeout, Promise and so on cannot wait.

Adaptation of dependent libraries: React, Redux, Dva, etc., and even third-party libraries are not sure whether they can run in the universal environment and whether they need to share state across environments. Take state management as an example, SSR requires that its store must be serializable.

Shared status on both sides: each state that needs to be shared should be considered (server) how to deliver and (client) how to receive

Challenge 2: stability and performance requirements of services

Compared with client programs, server programs have much stricter requirements on stability and performance, such as:

Stability: abnormal collapse, endless cycle

Performance: memory / CPU resource usage, response speed (network transmission distance, etc.)

Therefore, in the face of back-end professional problems, Demo-level SSR may not be difficult, but highly available SSR services are by no means easy, how to deal with high traffic / high concurrency, how to identify faults, how to downgrade / quickly recover, which links need to be cached, and how to update the cache.

Problem 3: the construction of supporting facilities

The core part of SSR is the rendering service, but there are other things to consider:

Local development suite (check + build + preview / HMR + debug)

Release process (version management)

A complete set of engineering facilities need to be reconsidered in SSR mode.

Problem 4: the problem of money

The introduction of SSR rendering service actually adds a layer of nodes to the network structure, and where heavy traffic passes, each layer is money:

Most importantly, SSR React apps cost a lot more in terms of resources since you need to keep a Node server up and running.

When the component rendering logic is changed from the client to the server, the cost of computing resources must be taken into account.

Performance loss of 5:hydration

After the client receives the SSR response, in order to support (JavaScript-based) interaction, it still needs to create a component tree, associate it with the SSR rendered HTML, and bind the related DOM events to make the page interactive. This process is called hydration.

The JavaScript code that hydration needs to load and execute is not necessarily much less than the CSR mode, and this part of the work is performed on the client side, which is limited by the performance of the user's equipment, and may result in perceived non-interactive time under poor devices:

CSR: interactive but no data (data is still being requested asynchronously and may last for a long time)

SSR: there is data but not interactive (after pulling to JS, start the process of hydrate, you can see the content but not interact with each other, and it usually doesn't last very long)

In rich interactive scenarios, the latter may not necessarily have a better user experience than the former.

Problem 6: data request

Synchronous rendering on the server requires you to send a request first, and then start the rendering component after getting the data, so you are faced with three problems:

Data dependencies need to be separated from business components

Missing client common parameter (including header information that clients such as cookie bring by default)

Data protocols on both sides are different: servers may have more efficient ways to communicate, such as RPC

In the current mainstream CSR mode, data dependencies are tightly coupled with business components. Data requests initiated by the server are all mixed in the component life cycle functions. Stripping data dependencies means that CSR code needs to be modified at the same time. Differences in common parameters and data protocols also pose some new challenges to code reuse and maintainability.

four。 Application scenario

No matter the loading performance or accessibility of the first screen, it is meaningful for content-intensive pages, while for interaction-intensive pages, SSR can not render much content in advance and is of little significance to users, so the necessity of SEO is also open to question. Therefore, SSR is suitable for static content display scenarios, typical scenarios with mixed arrangement of pictures and texts such as commodity details, strategies, articles, etc.

On the other hand, it doesn't have to be 100% SSR, rendering specific pages, or even just rendering a page frame is a good application:

"Application Shell" is an excellent concept. But sometimes, we might need to render a part of the page in the server. It could be the header with user info. In such cases, you need server-side rendering.

At this point, the study of "what are the advantages and disadvantages of SSR" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.