A brief discussion on SSR/MPA CSR/ SPA SSG ISR

Foreword

> This article would like to introduce what the terms in front-end SSR/MPA CSR/SPA SSG ISR mean. After all, it is a very common word.

SSR (Server Side Render) and MPA (Multi-Page Application)

The full name of SSR: Server Side Render. The Chinese translation is server rendering. What does server rendering mean? For example, you are about to open a browser (Google Chrome, Firefox, Edge…), and when you open the browser and enter an address Or when entering a website through My Favorites, during this process our browser will send a request (Request) to the server through the network to tell the server which page you want to enter. For example, you want to enter the homepage of the website now, and then the server receives After meeting this requirement, it will reply or respond (Response) to the browser with the interface you want, and then the browser will present the page to you based on what the server provides.

If the above paragraph describes the entire process in a more life-like way:

  • User–me
  • Browser – a blank piece of paper
  • Network – Postman
  • Server – Painter

The scenario concept is similar: Today I (the user) wants to see Van Gogh’s description, but the painter here is very poor. Every time I want to see something, I have to provide a blank piece of paper. And attach a description of the content of the letter (Request), for example:

> Hello painter, I would like your help to draw a portrait of Van Gogh.

Next, we will ask the postman to help us deliver the content of the letter to the painter (server), and then the painter will start painting according to the content of our letter and paint on the white paper we sent him together. After finishing the painting, the artist asked the postman to send the finished painting back to me for viewing.

And this is also a general traditional development model, which is related to what we will talk about later. In traditional development, this is called MPA (Multi-Page Application), which is a multi-page application model. Usually one page will be paired with an HTML page, so You can see the scene described above. If our interface is blank, this section will also cause the user to wait for the artist to finish painting. In today’s rapid development of society, if your picture exceeds a certain number of seconds, it will not appear. If the page is drawn, the user will run away. All pages here need to be processed by the server. Each page also needs to have its own Css and Javascript files that need to be downloaded.

If you know the backend code, let me give you an example

extends layout
block content
    .container
    h1=title

After back-end processing, it will be rendered into a common HTML

<!DOCTYPE html>
<html>
  <head>
    <title>Homepage</title>
  </head>
  <body>
    <div class="container">
      <h1>Homepage</h1>
    </div>
  </body>
</html>

> Browsers can only understand Javascript, Html and Css, so this section must be processed by the backend and then the Html and corresponding Css and Javascript are displayed to the user’s browser to render the interface. Therefore, SSR is the rendering content. Output screen.

Advantages and Disadvantages:

  • Fast first screen speed: Each page is independent of each other and multiple HTML pages need to be maintained separately. Each request returns HTML directly.
  • Switching pages is slow: Based on the document jump of the native browser, every page update is a page reload. This Will bring huge restart performance consumption

CSR (Client Side Render) and SPA (Single-page Application)

The full name of CSR is Client Side Render. The Chinese translation is client side rendering. If you are interested in Vue, React, or Angular, the default is CSR. The SSR above will render the interface through the server for the user to view, while the CSR will do the opposite and render the image through the user’s browser. This section does not need to go through the server.

So what should the server do at this time? Because of CSR, the server can be simpler, just do some logic and data processing for the user, and then process the interface through the user’s browser. Generally speaking, it is short enough. Just throw JSON to the user’s browser for processing. For example:

{
  "keyID": 0,
  "blogList": [ // Article list
    {
      "title": "PixiJS V5 Tutorial (0)", // Article title
      "url": "https://israynotarray.com/javascript/20200203/3949702627/" // Article URL
    },
    ...
  ],
  "updateTime": "2020/2/18 7:49:36 pm", // Form update time
  "blogUrl": "https://israynotarray.com/", // Blog URL
  "name": "Ray" // If you check the box and want to make your nickname public, the nickname will be displayed.
}

> Compared with the SSR mode, the server side reduces the process of processing painting, but simply processes the data to the user.

If the above paragraph describes the entire process in a more life-like way:

  • User–me
  • Browser – a blank piece of paper
  • Network – Postman
  • Server – Painter

The scenario concept is similar: Today I (the user) wants to see Van Gogh’s description, but this time because of the progress of the times! So we no longer use white paper, but an electronic version prepared by a painter. At this time, of course, we still need to tell the messenger what kind of picture we need.

Hello painter, I would like your help to draw a portrait of Van Gogh.

At this time, after the postman gave the new creation to the painter, the painter did not need to start painting at this time, but wrote a letter with the content: Please help me click somewhere on the electronic version to see it. Next, after I received the letter, I followed the same information once, and the confirmation screen appeared. In this process, we lack the painting part. Instead, we use the electronic version that the artist has prepared. As long as we click according to the operations he provides, we can see the picture we need. The user experience is not only good but also fast.

So CSR usually talks about SPA (Single-Page Application), and SPA is also called a single page application mode. Usually we have an interface command in the operation, just like the electronic version mentioned earlier, we have On the same board, instead of having to provide new white paper to the painter because we want to see other pictures, in the case of CSR, the performance will be much better than SSR, because the performance of CSR mainly comes from On the user side, the burden on the server will also be reduced a lot. You can try to think about it. Under the original SSR development, when you are the only one requesting the interface, there is no difference and it may be very fast. But when there are thousands of people requesting the interface from the server at the same time, is the performance bad at this time? It will get worse. Because all resources are on the server. The server is under a lot of pressure. Then using CSR means that we hand over the processing of the interface to the user, that is, the user’s browser, so everyone’s effect can be determined according to their own computer. Therefore, the burden on the service is greatly reduced, and the speed of switching interfaces is very fast. In this process, a technology called AJAX (Asynchronous JavaScript and XML) is used to request data from the backend.

Therefore, after all the presentation of the interface is handed over to the user, the server can concentrate on processing data, and the performance will be very powerful, but there may be a problem that it will be slightly slower when entering the network interface for the first time. In CSR mode, JavaScript is usually used to handle the rendering of the interface. The JavaScript data may be very large, and you need to download the JavaScript data first. After the download is completed, each switch will be very process-like. Just now It is also mentioned that most CSRs are talking about SPA. Therefore, in the SPA development mode, we usually stay fixed on one page, maybe index.html, and then simulate the back-end routing switching mode to achieve the feeling of switching interfaces. It is more common in There is a [#] behind the URL, for example, the homepage switches to other interfaces.

https://israynotarray.com/w3cHexSchool-Search/#/ -> https://israynotarray.com/w3cHexSchool-Search/#/user

Disadvantages: As a content website, the search engine is very poor. After all, all interfaces are rendered through the user’s browser. This is different from the back-end rendering mode. When the back-end gives you the screen, it will be a static image that has been rendered. Page data, while CSR is rendered later through JavaScript, also called dynamic page data, so SEO is relatively poor.

Advantages and Disadvantages:

  • Fast page switching: Routing jumps are based on feature implementations (such as vue-router, rect-router and other front-end routing) rather than native browser documents Jump to avoid unnecessary reloading of the entire page
  • Separation of front-end and back-end: Based on front-end routing, SPA is decoupled from the application back-end, so that the front-end no longer depends on the back-end routing distribution.
  • Slow first screen time: In addition to HTML, the first screen also requires and executes additional js files, and renders the first screen on an empty page through js
  • SEO unfriendly: The content is generated by js rendering, but search engines do not recognize this part of the content, resulting in poor SEO effect

Distinguish whether a website is SSR or CSR

Basically, CSR is relatively easy to identify. The easiest way is to use the browser source code mode (right-click on the browser – view web page source code)

In addition, usually CSR talks about SPA, so the following two labels will appear

<noscript><strong>We're sorry but w3hexschool-search-ts doesn't work properly without JavaScript enabled. Please enable it to continue.</strong></noscript>

There is only one element in the middle

<div id="app"></div>
//If you use web developer tools, there will be a lot of element content in the above elements

The above page is a CSR web page. On the contrary, if you check the original code, you can see that the content of the web page and the code are the same [basically] it is SSR, but there is no guarantee, because some websites are purely static websites and do not cooperate with the backend, so SSR identification may not be very accurate.

In conclusion, both CSR and SSR have their own advantages and disadvantages. Although it seems that CSR is better, and the performance problem mainly lies with the users, there is a saying [If you want to help the company make money, choose CSR], but still You need to look at where the development focus is. After all, some websites focus not on user experience, but on SEO rankings.

SSG(Static site Generation)

There are two interpretations of SSG ((the nouns seem to be different, but the two generate the same thing, that is, generating a static page is also called isomorphic rendering))

  • Static Site Generation static page generation
  • Server Side Generation server generation

Why mention SSG? The main reason is that the CSR mode will have SEO problems. Although Google has already developed an interface to support SPA for their search engine, SSR mode web pages will still have certain SEO trends. After all, all data is rendered directly from the server. Instead of Javascript dynamic rendering.

In these circumstances, will we abandon SPA for SEO? No! It’s difficult. After all, the emergence of SPA is to solve the problem of user experience. If you abandon it, you will put the cart before the horse. Therefore, some frameworks were born to solve SEO problems, such as Nuxt.js (Vue), Next.js (React)

The concept of SSG changes the situation where your original CSR only has one line of labels.

<!DOCTYPE html>
<html lang="zh-Hant-TW">
<head>
  <meta charset="UTF-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Document</title>
</head>
<body>
  <div id="app"></div>
</body>
</html>

It becomes a situation similar to SSR, you can see a lot of text and HTML that are actually inside the original #app tag

<!DOCTYPE html>
<html lang="zh-Hant-TW">
<head>
  <meta charset="UTF-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Document</title>
</head>
<body>
  <div id="app">
    <header>Ray</header>
    <ul>
      <li>This is a passage</li>
      <li>This is a passage</li>
      <li>This is a passage</li>
      <li>This is a passage</li>
    </ul>
    <footer>This is footer</footer>
  </div>
</body>
</html>

Implementation process:

  • Executed once on the server side to achieve server-side rendering (directly out of the first screen)
  • Execute it again on the client to take over the interface interaction

flow chart

The concept of this entire operation is simply that when writing these frameworks (Nuxt.js, Next.js, etc.), your Ajax content will first request the first initial data from the remote server, and then these will be The data is actually written to the screen, and then the HTML interface is generated, so the interface you see at this time also has HTML files, so the specific identification is not very accurate.

ISR (Incremental Static Regeneration) incremental static regeneration

The data is fetched once at build time, again after a certain cooldown, and made available on the second visit.

Incremental static regeneration is a combination of SSG and SSR. It is served statically, but under certain events and conditions, the page will be rebuilt and get data from the API again.