This is the 11th day of my participation in the August Wenwen Challenge.More challenges in August

Noun explanation

SSR

  • SSR: Server-side rendering – Client or generic application rendering to HTML on the server.

CSR

  • CSR: Client-side rendering – Usually using the DOM to render the application in the browser.

Rehydration

  • Retells: “Launch” JavaScript views on the client so that they reuse the DOM trees and data of HTML rendered by the server.

Prerendering

  • Prerendering: Run the client application at build time to capture its initial state as static HTML.

TTFB

  • TTFB: Time to the first byte – regarded as the time between clicking the link to the first of the input.

FP

  • FP: First Paint- The First time any pixel is captured that is visible to the user.

FCP

  • FCP: The first content-rich paint – the time the requested content (article body, etc.) is visible.

TTI

  • TTI: Interaction time – the time of page interaction (event link, etc.).

Introduction to front-end rendering

CSR client rendering

Today I’m talking about server-side Rendering, SSR for short. Firstly, I will introduce common Web Rendering modes. The first is the main development mode of front and back end separation, which is also the development mode of most front-end students, namely client-side Rendering. Angular,React and Vue are all cSR-based frameworks. During development, we only need to agree the interface with the backend students in advance, and then the front-end page is developed and constructed by our front-end students. We can use Ajax technology to refresh the page locally.

CSR (client-side Rendering) -- Rendering an APPin a browser, generally using the DOM.
Copy the code

Net stands for network request. Request js file “bundle.js”. This is the FCP time point.

FCP: First Contentful Paint - The time when requested Content (article body, etc) becomes visible.Copy the code

The first content-rich render – the time when the requested content (body of the article, etc.) is visible. Next, our JAVASCRIPT engine and browser rendering engine render more page content. After rendering, we come to a point in time: TTI.

TTI: Time To Interactive - the time at which a page becomes interactive (events wired up, etc)
Copy the code

This translates to “interaction time – the time the page interacts (events are sorted, etc.) “, which is the point at which the user is first able to interact with the page. The time it takes to go from FCP to TTI is determined by the size of the JS file that our front end packages. This includes our business code, as well as part of the third-party library code. For machines with poor performance, it takes longer. It was mentioned at Google conference that loading data using HTTP/2 Server Push or can improve performance, and lazy loading can also be used in our front-end development. Webpack’s Treeshaking and others reduce JS file sizes to reduce rendering times. At the same time, as most of the current front-end frameworks develop single page Application (SPA), if the JS file is large, the first screen loading will be slow, affecting the user experience. Let me change my mind, change the render mode, and see what happens.

SSR server rendering

The server renders the complete HTML of the page on the server in response to the navigation generation. This avoids the client’s other round-trip process of data retrieval and templating because it is processed before the browser gets the response. Server rendering usually produces fast First Paint (FP) and First Contentful Paint (FCP). Running the page logic and rendering on the server avoids sending a lot of JavaScript to the client, which helps achieve fast interaction times (TTI). This makes sense, because with server rendering, you’re really just sending text and links to the user’s browser. This approach works well across a wide range of devices and network conditions, and can lead to interesting browser optimizations, such as streaming document parsing. The SSR rendering process is roughly as follows:

With server rendering, users are less likely to wait for CPU-bound JavaScript processing to use your site. Even if you can’t avoid using third-party JS, using server rendering to reduce your own first-party JS costs can give you more “budget.” However, this approach has one major drawback: generating pages on the server takes time, which typically results in a slow first byte time (TTFB).

The dynamic nature of server rendering can introduce considerable computational overhead. Many server rendering solutions do not refresh early and may delay TTFB or double the data sent (for example, inline state used by client-side JS). In React, renderToString() can be slow because it’s synchronous and single-threaded. Getting the server to the “right” state may involve finding or building a component caching solution, managing memory consumption, applying memo technology, and many other issues. Typically, you will process/rebuild the same application multiple times – once on the client and once on the server. Just because server rendering makes something happen faster doesn’t mean you have less work to do.

Server rendering generates HTML on demand for each URL, but is slower than just serving statically rendered content. If you can do other things, server rendering + HTML caching can greatly reduce server rendering time. The advantage of server rendering is that it can extract more “live” data and respond to a more complete set of requests than static rendering. A page that needs personalization is a concrete example of a request type that does not work well with static rendering.

Refer to the link

Introduction to front-end rendering at Google Developer conference