The web application is a door to visualize features we provide to customers, the good web application is not only user-friendly but also having high performance. The user experience will determine the success of the application, when a user visit a website what they want see first is the content, it should be displayed as soon as possible and without interruption. Another requirement is the website visibility from search engine such as Google Crawler, by visible under these search engines can increase number of visit time to our website or we can called it as SEO. To implement such as these web application requirements we must know about Render Patterns. The Render Patterns are ways in which the HTML, JS, CSS is processed and rendered on browser. There are some Render Patterns have been applied in well-known front-end libraries like ReactJS, Next.js, Vue.js, AngularJS. Each of them have some advantages and disadvantages depend on what our exceptions. Before listing out common Render Patterns, let’s study some concepts of rendering.
How a website is rendered and delivered to end user?
Before user is able to interact with website, there are series of steps are processed involved different technologies to create web components and finally send to the browsers. Here are some simplified steps of how it works:
1. User type a URL in browser such as Google, Firefox, Edge, Safari to request the contents.
2. Next the browser will use DNS (Domain Name System) like an address book to look up the corressponding IP address of the entered URL.
3. Then, the browser will send a HTTP (a protocol used to communicate betweens 2 machines through network) request to the server (we can call it as remote machine) to ask for the web page.
4. After that, the server will send back a HTTP response which contains the web page to browser. Normally, the web page will contains HTML, CSS, JS code files which is are used by browser to construct the UI and also handle logic. Additionally, it can includes multimedia files such audio, videos, images, documents to enhance the web page.
5. Finally, the browser receives the HTTP response from the server and renders the web page on the user’s device.
Rendering means processing and displaying the code and assets of the web page to end user. The browser may also execute some JavaScript code on the user device to make the web page more interactive and dynamic.
From that, we can understand that there are 2 sites involve in the rendering process, one is from server or another is client site, in FE we called as Server-side rendering (SSR), Client-Side Rendering (CSR).
COMMON RENDER PATTERNS
Server-side rendering (SSR)
The server will render the HTML content of web page based on requests and send them to client. This approach can improve the initial loading time, by rendering the HTML content from server at the request time, the web page can improve SEO because it’s content be found by search engines. The idea of search engines are trying to make a request to a endpoint and analyze the response content, the rich of content will improve the index of the web page from search results. But this approach can be slow on web pages with dynamic content, and it takes more processing power and memory on the server, as it has to generate the HTML content for each request. The another disadvantage is increasing the bandwidth usage of the server and the client, as it has to send more data over the network. So that, we may choose SSR when we want to build a web site with fast loading, increase SEO and accessibility.
SSR frameworks are Ruby on Rails, PHP Laravel, or Python Django.
Client-Side Rendering (CSR)
The browser will render the HTML content of web page at client-side by using JavaScript. This can provide a web page with dynamic content and required more interactive. The entire web application will be loaded on the first request, each page on client will responsible for requesting it’s data from remote. The navigation between pages does not require page refreshing, it make the application look more responsive. As HTML content of a web page is rendered at client-side while search engines are not optimized to work with JavaScript files, it will be bad for SEO. There is a workaround way is making client render SEO friendly. The application may be also lagging if the size of the JavaScript bundle is too big. Generally, the CSR is suitable for web pages required fast interactivity, better user experience and more flexibility.
Some CSR frameworks are React, Vue, Angular, or Svelte.
Static rendering or static generation (SSG)
In the above sections about SSR and CSR, we have seen the pros and cons of 2 render patterns. If SSR takes a long time to process at the server, CSR takes a long time to load and process JavaScript bundles, resulting in the content of the web page not being displayed quickly. But we don’t always have to deal with the logic to generate HTML content, especially for static content, instead we can pre-render these HTML content during the application build time, which provides a better user experience. Because the content will be delivered to the user as soon as they enter our website. In addition, these static content can be delivered through CDN to increase availability. Thanks to these advantages, SSG is often used to create large and static HTML content, such as blogs or news pages. As the name of SSG, this render pattern will be suitable for static pages. For dynamic pages, it has some disadvantage with web pages frequently changing contents, these contents have to be built and redeployed when there are changing such as the Product detail page may not changed frequencily, however the product price or description may be updated, these changes need to be rebuilt and redeployed to avoid wrong content delivered to customer.
SSG tools are Next.js, Nuxt.js, Gatsby, Hugo, Jekyll, or Astro.
Incremental Static Generation (ISG)
The Incremental Static Generation (iSSG) render pattern was born to solve SSG’s problems for web page has content frequently changing, the idea is pre-rendering content in the background for frequently changing parts of a website. One of the common ways is re-rendering a page after a timeout period. If a browser makes a request during the rendering process, the content from the previous render will be responded to the browser, subsequent requests will be responded with the latest content which has been re-rendered. With this approach, the server does not need to be rebuilt and redeployed when having changes, the website content is guaranteed to be continuously refreshed through the background rendering process, increasing availability, initial loading time. And an important point is that it is easy to distribute via CDN.
In addition, iSSG also has limitations, such as increased complexity and processing time for the build process, if there are many part of a web page that need to be updated dynamically. Besides, choosing the re-render frequency is also a factor to consider, this will affect whether the data is consistent or not.
Progressive hydration (PH) and Selective hydration (SH)
SSR and SSG have helped us solve problems related to creating HTML content for a web page, such as improving loading time and SEO. However, a web page must continue to perform other tasks to be able interaction by users, including downloading the JavaScript bundle and executing the logic behind. This process is called hydration. There are two techniques for the hydration process called progressive and selective hydration.
If progressive hydration is a technique for hydrating components in a web page sequentially, the important and visible parts will be hydrated first. For example, when we open a web page, the header and the upper part of a scrollable body will be hydrated first. When we scroll down the page, the next body part will be hydrated. This helps the website only need to load important JavaScript first, so users can quickly interact with the web page.
Selective hydration is similar to progressive hydration, this technique also allows some parts of a web page to be hydrated while other parts will be static HTML components. This means that important parts of the website that need to be interactive will be selected in hydration process, it helps to improve web page performance as well as the memory needed to render a whole web page.
Like other rendering patterns, progressive hydration and selective hydration also have limitations such as increased complexity for development, debugging and maintenance. Additionally, this technique will not work very well on some existing FE libraries, some of them require the whole web page to be hydrated instead of a portion of it. Hydrating a portion of a web page will also result in some animation issues, components of web page could be shifted when other components change.
Progressive hydration and selective hydration can be implemented with various frameworks and tools, such as Next.js, Nuxt.js, Astro, React.
Streaming Server-Side Rendering (SSSR)
Like the hydration technique above, SSSR is another pattern/technique that helps improve web page performance when implementing with SSR. Instead of responding a large file of bundle to browser, with this technique the bundle is divided into smaller components called chunks. Chunks will be continuously delivered to browser in bytes format, browser will receive these chunks and render final components. This helps the content of the web page to be displayed as soon as possible and users can interact immediately with the web page. The special thing of this technique is that the server will stop streaming chunks to the browser if there are issues coming from the network, the server will save resources for other requests. Like SSR, the streaming chucks can be read by search engines and enable SEO on the web page. Beside, this implementation will encounter additional challenges for debugging, testing, and maintaining the code. For example, SSSR may require special handling of errors, redirects, or authentication. Some FE libraries do not yet support streaming parts of a web page. There could be the delay of chunks being transmitted over the network, which will also be encountered in other techniques.
SSSR libraries such as React 18, Astro.
EXAMPLE
In real-life project, we often take advantage of each type of render patterns to create applications that increase performance, initial loading time, interactivity, flexibility and good SEO. For example, when building an commercial application, we will build pages such as landing page, production page or checkout page. On each page we will use one or multiple render patterns.
For landing pages, we can use SSG or ISR for static content. These content can be delivered via CDN to increase performance and availability.
For product page, we can apply CSR, SSR and hydration. Parts of the page that not change frequency, we will use SSR. For parts that require a lot of interaction such as color selection, updating prices when users select size and color, we will use CSR. Also hydration patterns because the product page will often be quite long.
For the checkout page, security concern is important, so rendering on the server will be more secure than the client side.
Above are some suggestions for using appropriate render patterns. The choice of render types also depends on the support of frameworks/libraries/tools as well as the needs of the project.
SUMARRY
Till here, we have some basic concepts of current rendering techniques that popular libraries/frameworks support. Server Side Rendering is a technique that has been used for a long time and is implemented on most libraries/frameworks such as Ruby on Rails, Laravel, Django, ASP.NET, Express, Spring, Angular, React, Vue.js, Ember.js, Next.js. Client Side Rendering will be found more often in JS libraries/frameworks such as Angular, React, Vue.js, Ember.js, Next.js, Astro. Among them, React, Next.js or Astro are 3 web frameworks that invest more on these rendering techniques. In the next blogs we will learn about how to implement these types of Render in React, Next.js and Astro.