Rendering Web Apps

Client side, Server Side or Pre-rendering - What and Which to use

Rendering Web Apps

Building a web app is not just about implementing state-of-the-art styling for user interface (UI) and tech stack for providing the desired functionalities. Speed, Search engine optimization (SEO) and security should also be a concern from the beginning of the project to enhance the user experience (UX) and search engine rankings. This requires selecting the right technologies and methods to render the application in the suitable way according to the needs and goals.

By rendering it refers to the process used by your web browser that turns website code into the interactive pages users see when they visit a website. The browser combines the DOM (Document Object Model - JavaScript representation of the HTML) and CSSOM (CSS Object Model) which contains the style and content information to populate a webpage. It then calculates the layout and position for each visible element of a webpage and paint them on the screen for the end user's view.

Note : Some technical terms and process are given a brief explanation at the end of the blog.

There are basically three rendering techniques : -

  1. Client Side Rendering (CSR)
  2. Server Side Rendering (SSR) and
  3. Pre Rendering
TypeSEOSpeed
Client side
Server Side
Pre

1. Client Side Rendering

Process

  • User requests a website to the server which sends the HTML file with JavaScript links.
  • Browser then downloads the received HTML, CSS and JS files. During this stage user sees a blank screen or a loading page.
  • It then executes the framework or libraries and makes the required API calls to get the data to be displayed. There is no content on screen till this point. The hydration process also takes time according to how much JavaScript your application contains.
  • Now the whole content is loaded on the screen and is interactive as well.
  • The client-side framework manages to update UI with changed data by re-rendering only that particular DOM element. So the successive calls are faster.
ProsCons
Fast rendering after initial loadingSlow Time to Interactive (TTI) due to client side hydration of JS code
Low server load because all the content is processed and rendered on the client/in the user’s browser.Low SEO as it makes it hard for search engine robots to see the website content
Lower costs than a Server-side rendered appsInitial loading takes time
Supported by a lot of JS frameworks and librariesMay cause poor user experience
The amount of users have no affect on the speed as it is fully rendered by the users' browser, soJavaScript pages will not be visible if JavaScript is disabled in the users’ browser

Frameworks

  • Client-side rendering is the default for JavaScript applications. Popular Frontend Frameworks like React, Angular, Vue and Amber use this rendering type.

2. Server Side Rendering

Process

  • User requests a website to the server which generates the entire HTML for the specific request and sends the ready HTML file to the browser. The process of adding data, style and generating the HTML file which was done by the browser in CSR is now done completely in the server.
  • Browser renders the ready HTML file, the whole content is now visible in the screen but is not interactive at this stage.
  • With the viewable and crawlable content in the screen, now the browser downloads and executes the JS and the framework. It doesn't require to get data from API calls as the whole HTML has been created by the server itself with the data.
  • After executing the JS, now the website becomes fully interactive as well.
  • Unlike CSR, on each request SSR generates entirely new HTML files and the process continues, which makes it relatively slower but has faster first loading time.
ProsCons
Suitable for SEO-focused websites as the search engine bots can crawl easilyLarge number of server requests
Faster initial loading (helps to improve user metrics such as session duration and bounce rate) and much faster First Contentful Paint (FCP)Full page reloads
The blank page flicker that happens with CSR also doesn’t really happen with SSRSlow rendering when application has a lot of interactivity or used by a large number of users
JS is resource-heavy and code-intensive. Downloading it onto a browser using CSR contributes significantly to page weight. SSR reduces the page weight as wellIt’s expensive, difficult to implement and requires a lot of manpower to set up

Frameworks

  • Angular: Angular Universal
  • ReactJS: ReactJS with custom setup, Next.js (by opting to use getServerSideProps)
  • VueJS: Nuxt.js

3. Pre-Rendering

It acts like a CSR for a human user and as a SSR for a web crawler so combining the advantages of both the above rendering methods. Static-side applications use this technique.

Process

  • It preloads all elements on the page Ahead of Time (AOT) at build-time in preparation for a web crawler to see it.
  • A prerender service will intercept a page request to see if the user-agent viewing your site is a bot (like a scrawler) and if the user-agent is a bot, the prerender middleware will send a cached version of your site to show with all JS, Images, etc. are rendered statically. If the user-agent is anything but a bot, then everything is loaded as normal i.e. CSR.
  • Some prerendering services work in a different way where it pre-renders the expected next page of the user, so as to reduce the load time for the request and enhance the UX.

We need not to prerender all things. However, we should use prerendering if the site is a SPA and needs to be available for bots to crawl it. When the content lives behind a login screen, prerendering becomes unnecessary, since bots won't ever make it through the first login screen. It is also not necessary to prerender your site if all your content is already a static HTML page and not a JavaScript enabled SPA.

ProsCons
Perfect for SEO-focused websites.Need to wait for interactivity until JS is loaded
Reliable, excellent performance, secure, and scalableNeed to provide user-friendly design for the first loading if data is required
Less requests then with SSRIt won't work if we can't show any content or page without user authentication
Better user experience for the first loadingFlash of un-styled content (FOUC) is noticeable if you are using a CSS-in-JS library

Frameworks

  • There are different libraries available for pre-rendering like Nextjs (it shouldn't be confused, Next uses pre-rendering mainly but can be used for SSR by using suitable methods, view docs). There also exists other services and packages like react-snap which helps to enable pre-rendering in your web app.

There’s no one perfect rendering way, a lot depends on the application you are creating and the result you want to achieve. If you have a static app and care about SEO and loading time, you’ll select a different way, then if your application is dynamic and needs a lot of content from the server.

Terminology

  • Hydration is a technique where JS converts static HTML (returned from the Server) into dynamic and interactive elements in the browser. Also generally referred to as client-side hydration or re-hydration. When hydrating, JavaScript (such as event handlers, listeners, etc.) is linked to the static HTML to make it interactive.

  • First Paint (FP) is the time between navigation and when the browser renders the first pixels to the screen, rendering anything that is visually different from what was on the screen prior to navigation.

  • First Contentful Paint (FCP) is the first time the browser renders something to the DOM, such as text, images, or SVG’s. This is the first time users could start consuming page content.

  • Time to Interactive (TTI) The browser has rendered the entire website content, at this point, and the user can interact with the elements on the page. That could be pressing a button or clicking in text fields that give some feedback to the user.

Thank you for reading.