Rendering Web Apps
Client side, Server Side or Pre-rendering - What and Which to use
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 : -
- Client Side Rendering (CSR)
- Server Side Rendering (SSR) and
- Pre Rendering
| Type | SEO | Speed |
| 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.
| Pros | Cons |
| Fast rendering after initial loading | Slow 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 apps | Initial loading takes time |
| Supported by a lot of JS frameworks and libraries | May cause poor user experience |
| The amount of users have no affect on the speed as it is fully rendered by the users' browser, so | JavaScript 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.
| Pros | Cons |
| Suitable for SEO-focused websites as the search engine bots can crawl easily | Large 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 SSR | Slow 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 well | It’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.
| Pros | Cons |
| Perfect for SEO-focused websites. | Need to wait for interactivity until JS is loaded |
| Reliable, excellent performance, secure, and scalable | Need to provide user-friendly design for the first loading if data is required |
| Less requests then with SSR | It won't work if we can't show any content or page without user authentication |
| Better user experience for the first loading | Flash 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.