Read not for eloquence and refutation, nor for credulity and blind obedience, but for reflection and weighing. -- -- baconCopy the code

Two rendering methods

Why back-end rendering (server rendering SSR) vs. front-end rendering (client rendering CSR)

Start by understanding what is passing between the server and the browser client: HTML, CSS, JavaScript files, data carriers such as JSON (XML) files.

At the beginning, Web apps are directly composed of several HTML, CSS and JS, and each page needs special logic. Therefore, as the App scale expands, there are more and more code files in the directory of back-end websites, and they are not synchronized with each other. For example, if you change the layout of your site, you may need to change hundreds of HTML files, which is a lot of work. Since so much HTML has a logical connection, why not use code to generate code? The back-end template language was born, and it became widely used instead of hand-written HTML.

Pug (Jade) and Go Template are the template languages I have come into contact with

• The following is an example puG template:

  

• The following is an example of a go template template:

  

By rendering HTML on the back end, the front end does not need to configure the steps of routing, just place space where the content needs to be filled. You need to be familiar with the fields, and you need to tune the front and back ends together.

The back-end rendering

The early Internet, users use the browser are not complex logic, simple page, the server process to get the data from a database, the backend application before you spit HTML page to the front, make a particular area of the HTML page, specific symbols, first with data populated, generate HTML to load data came in, It is then transmitted over the network to the user’s browser to be parsed into a visible page.

Rendering, as you can see, is a modification, and the word rendering comes from games, which in turn comes from real life painting, rendering, taking paint and putting it on paper. Most servers used to be in this mode

The front-end rendering

As the complexity of the front-end page increases, the front-end is not just a common page display, but may add more functional components, more complexity. In addition, the rise of Ajax at that time, the industry began to advocate the development mode of front and back end separation, that is, the back end does not provide complete HTML pages. Instead, it provides apis that allow the front end to retrieve JSON data, and then the front end takes the DATA and splices the HTML pages in the front end and displays them in the browser. This is called front-end rendering.

This allows the front end to focus on the UI and the back end to focus on the logic. It is the popular SPA single-page application, such as Vue and React framework, which only needs the back end to provide us with interface API, front-end UI and interaction are all carried out in the front end, and the front and back end only need the convention interface.

The most important difference between back-end rendering and front-end rendering lies in the difference in data filling, that is, who will complete the complete stitching of HTML files. If it is completed at the back-end, it will be directly filled into THE HTML and passed to the front-end, and then returned to the client, that is, back-end rendering; And if the front end has done more work to complete THE HTML splicing, and takes data from the background through Ajax or FETCH to fill it or perform other data operations, it is the front end rendering

Here are a few online users to the front and back end rendering comparison image of the metaphor:

In simple terms: the back-end rendering HTML is called spit or spray, the robot can see the complete rendering source code front-end template rendering HTML is called fill, the robot can not see the complete rendering source code

For example, draw a picture with a house: back end rendering: the back end is drawn, and the front end is directly used to show you. Front end rendering: The back end sends a series of data such as canvas, house and house location to the front end, and the front end draws a picture for you to see

Front-end rendering and back-end rendering routes

Front-end rendering route

1. Request an HTML 2. Server returns an HTML 3. Browser downloads JS/CSS files in HTML 4. Waiting for JS file download to complete 5. Waiting for JS loading and initialization to complete 6. JS code can finally run, and the JS code requests data from the back end (Ajax/FETCH) 7. Wait for the back-end data to return 8. The client renders the data as a response page from scratch to completeCopy the code

Back end rendering route

1. Request an HTML 2. Server request data (Intranet request fast) 3. Server initial rendering (server performance, faster) 4. Server returns HTML with the correct content 5. The client requests the JS/CSS file. 6. Wait for the JS file to be downloaded. 8. The client finishes rendering the rest of the rendering (small content, fast rendering).Copy the code

The change from back-end rendering to front-end rendering

• Computing task transfer The rendering task that was performed by the server is transferred to the client, which greatly relieves the pressure on the back end when a large number of users are accessing it. Having the back end focus on what the back end is supposed to do will greatly improve performance, because the server really does less work, and now with the development of the client software and hardware, it can handle most of the rendering.

• By relinquishing front-end authority and handing over the entire UI logic to the client, experienced and capable users can hijack the UI so that they can see something they shouldn’t. This seems to violate the principle of safety. But “everything in the front end about security is playing rogue”, the back end can not trust all the data from the front end, remember to do a good job filtering and verification. As long as SSL is used, XSS is shielded and there are no vulnerabilities in the back end, it is still difficult to fake identity and hijack App.

The pros and cons of back-end versus front-end rendering

Pros and cons of back-end rendering

• Advantages:

  • The front end takes less time because the back end concatenates the HTML and doesn’t need to download a bunch of JS and CSS to see the page; the browser just renders it
  • Search engine optimization, because there is a complete HTML page at the back end, so crawlers are easier to crawl and get information, which is more conducive to SEO
  • No client resources are required. That is, the work of template parsing is completely handed over to the back end, and the client only needs to parse the standard HTML page, which takes less resources for the client, especially for the mobile terminal, and saves more power
  • The back end generates static files. Generate cache fragments, which reduces the time wasted on database queries and is very efficient for pages where the data doesn’t change much

• Disadvantages:

  • It is not conducive to the separation of front and rear ends, and the development efficiency is low. Server-side rendering is not conducive to the efficient development of projects with high front-end complexity
  • Server-side rendering, where the front end usually writes a static HTML file and the back end modifies it into a template, is inefficient and often requires both the front and back ends to complete the modification
  • If the back-end template is changed, the front-end needs to adjust the CSS based on the changed template, which increases the time for the front-end and back-end synchronization
  • Occupies server resources, that is, the server parses THE HTML template. If a large number of requests are received, the server may be under access pressure. If you use front-end rendering, you split the parsing load on the front end, which is really all on one server

Advantages and disadvantages of front-end rendering

• Advantages:

  • The front and back ends are separated, with the front end focused on the front-end UI and the back end focused on API development, and with more options on the front end rather than following back-end specific templates
  • It’s a better experience, for example, if we make the website a single Page Web application (SPA) or part of it a SPA, so that, especially on mobile, Can make the experience more like a native APP
  • A partial refresh without requiring a full page request each time
  • Lazy loading, such as loading only the data in the visual area at the beginning of the page and then loading other data after scrolling, can be implemented with react-lazyLoad
  • Rich interaction, using JS to achieve a variety of cool effects
  • Save server cost, save electricity and money, JS supports CDN deployment, and the deployment is extremely simple, only requires the server to support static files

• Disadvantages:

  • The front-end response is slow. If it is client rendering, the front-end has to perform the process of concatenating strings, which takes extra time and is not as fast as the server-side rendering
  • It is not good for SEO. At present, crawlers of Baidu and Google do not recognize SPA and only record a page, so SEO is poor

Usage scenarios

Blindly choosing which rendering method to use without talking about the business scene is rogue. For example, enterprise sites, the main function is to display without complex interaction, and need good SEO, then we need to use back-end rendering; And similar to the background management page, interactive, do not need to consider SEO, so you can use front-end rendering.

In addition, the specific use of what kind of rendering method is not absolute, for example, some websites now use the first screen back-end rendering, that is, for the user at the beginning of the page is the back-end rendering, so as to ensure the rendering speed, while other pages use front-end rendering, so as to complete the separation of the front and back ends.

• Back-end rendering: relatively modular, ideal for show-oriented pages, good for SEO. And because it is already rendered in the back end, so the loading experience is relatively good, in the network speed difference performance.
• Front-end rendering: flexible and suitable for business scenarios where DOM operations are frequent or interactions are complex. A model can be well maintained without repeated requests. Theoretically, it is more consistent with front and rear end separation.

Why is front-end rendering bad for SEO

If the front and back ends are separated, then the front end is either using JS to modify the DOM so that the HTML is fully concatenated and then displayed, or using SPA, where SEO is virtually non-functional. So how to do SEO optimization in this case?

SEO(Search Engine Optimization) SEO is a process of adjusting a website to improve its ranking for certain keywords in search engines by understanding how search engines work (how to crawl pages, index and display search results sorted by specific keywords, etc.)

The SPA mentioned above is not good for SEO, because currently, some search engines such as Google and Bing have crawlers that support JS execution and even AJAX data acquisition, but they still lack support for asynchronous data. Because a lot of content in a single page is dynamically generated and displayed according to the matched route, and a lot of page content is obtained asynchronously through Ajax, the network fetching tool will not wait for the completion of the asynchronous request before grabbing the page content. It is difficult for network crawlers to accurately simulate related behaviors to obtain complex data. They are better at static resource crawls and analysis.

The route implemented by VUE and React is not a new page, but a dynamic switch of the page content. There is no page reloading, so there is no crawler to fetch data

• The page that the back end render crawler sees looks like this:

• The front rendering crawler sees a page that looks like this:

References:

1. In – depth analysis of front-end and back-end separation – browser rendering versus server rendering
2. To realize SSR application based on Nuxt.js
3. Server rendering vs client rendering