3 Ways of Rendering on The Web
Introduction
Rendering a website can be done in several ways. A common challenge is when to choose which of the types.
Exploring the options before starting a new project can prevent us from refactoring parts of our code or the entire tech stack. It depends on whether it is crucial to get a good ranking in Google. Or if the content should be more interactive, dynamic, and fade smoothly into the user’s view. Or if performance and excellent user experience are more essential for your business goals.
All websites have different needs and having some basic understanding of the rendering on the web will spare you money, time, and frustration.
Concepts and terminology
First, we will go through some basic technical concepts and terminology. Knowing a little about them will help us make even better decisions on our website’s rendering options.
These concepts we can divide into two categories: Performance and Rendering.
Performance
- Hydration is a technique where JavaScript 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.
- Pre-rendering is a technique where the HTML is rendered A Head of Time at build-time. Pre-rendering is essential for public pages that should get crawled and ranked by search engines. Server-side and Static-side applications use this technique.
Rendering
- First Paint (FP) is the first step during rendering after a user navigates to a page. It is the first pixel painted on the screen and in the browser window — everything in the browser window that is visually different from before navigation is processed in the First Paint.
- First Contentful Paint (FCP) is the first time the browser renders something to the DOM, such as text, images, or SVG’s. During this process, the browser will tell the user that “something is happening.”
- 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.
Client-Side Rendering (CSR)
Client-side rendered websites do everything “on their own.” Such as retrieve data from an API, manage logic, and routing between pages directly in the browser. Every page the visitor visits and its respective URL are being created dynamically.
We can think of rendering on the Client like package delivery, of three packages. Each package will come in a different order and at different times, but you don’t know precisely when. You will get the first package, then the second, and at last the third.
Client-side applications typically have a fast FP and FCP. They use hydration which can cause a slow Time to Interactive because the browser needs to “boot up” the JavaScript code, rehydrate, and then load the HTML back into the browser window. The hydration process may vary in time depending on how much JavaScript your application contains.
A slow TTI is not very good for Search Engine Optimization (SEO). Most Client-side applications that need their content crawled and optimized for SEO will have to implement pre-rendering to make it work properly.
Client-side rendering is the default for JavaScript applications. Popular Frontend Frameworks like React, Angular, and Vue use this rendering type.
Pros:
- Gives the user quick feedback and a smooth user experience, e.g., a fast First Contentful Paint.
- Low server load because all the content is processed and rendered on the client/in the user’s browser.
- Lower costs than a Server-side rendered application.
Cons:
- May cause poor user experience. Potentially, leave the user waiting for content until everything is fully loaded into the browser, resulting in the user leaving the site instead.
- Client-side applications make it hard for search engine robots to see the website content, which leads to no or poor indexing.
- JavaScript pages will not be visible if JavaScript is disabled in the users’ browser.
Server-Side Rendering (SSR)
Server-side rendering (SSR) happens On-demand, also called Just in Time (JIT). Every time the Client makes a request for a page, the Server generates HTML for that request. The HTML is then returned to the Client, wholly rendered, ready to be displayed.
We can think of rendering on the Server like package delivery, much like for Client-side rendering. Instead of getting the packages delivered at different times, you get all at the same time.
Server-side rendering is slower than Static-side rendering because the HTML is generated entirely on each request. But it’s faster than a client-side rendered application when returning the entire result to the user.
JavaScript frameworks like Vue and ReactJs use hydration to generate interactive code sent from the Server.
Pros:
- Suitable for SEO-focused websites.
- Gives the user a great user experience by delivering all content on request.
Cons:
- It may be expensive. Require setup and managing of servers or server code besides frontend code.
- If the Server is down, the website is also down.
- It may require a backend/full stack developer in addition to a frontend developer.
Static-Side Rendering
Static rendering happens at build-time. Every page is compiled and rendered as static HTML files Ahead Of Time (AOT). Files generated AOT means that we will produce an HTML file with a separate URL for each file. What is excellent about static websites is that they can be uploaded to a CDN and easily be moved to another source when needed without much work.
We can think of rendering an application statically, much like on the server, just that it is incredibly fast. The packages don’t need to be packed beforehand; they’re just shipped to you at once.
Statically rendered websites have some significant advantages. They are fast, have better reliability, and improved SEO. Websites generated statically have fast FP, FCP, and TTI.
A few months ago, I wrote an article about what benefits you can draw from having Static Generated Websites. You are welcome to read it: Benefits of Static Websites.
Pros:
- Perfect for SEO-focused websites.
- Reliable, excellent performance, secure, and scalable
- Low costs, can live on a Content Delivery Network (CDN)
- Easy to move between hosting providers
Cons:
- You are dependent on deploying the entire website in case of changes — like pushing news articles or products for an e-commerce shop.
Let’s wrap up
If you ask yourself, “When should one be critical to the choice of rendering type?” this is just relevant when a website contains JavaScript.
CSR may provide a faster response (FCP) to the user. It is more interactive and perfect when content needs to be updated without contacting the Server. On the other hand, suppose you build a website with full JavaScript. In that case, some JavaScript frameworks like React, Vue, or Angular will, in most cases, only render an empty HTML page. Search engine crawlers will see these sites as completely blank until fully rendered.
Many JavaScript frameworks that have become popular in the past years have built-in Static Site Generation (SSG) and Server-side rendering, such as GatsbyJS and NextJS, supporting both SSR and SSG.
SSR and SSG are better for SEO. Both can display page content faster. They give a better user experience, and search engine robots will have it easier to rank your pages. Suppose you have a static website that consists only of HTML. In that case, you do not need to pay attention or worry about SEO optimization or excessive server load at all.
On the latest project I’ve been working on, we’ve used a combination of client and static rendering for a couple of years. Doing so is essential because the customer I work for has a website that is both a news page and contains pages where users can see their customer relationship behind some secured pages.
So, going entirely for only server-side or only client-side, I would not recommend if you are in the same situation as I described above. Know when to use the different rendering types, and you will make fantastic websites that also give the user a great user experience.
Thank you for reading!
Code for shizzle
3 Ways of Rendering on The Web was originally published in Grensesnittet on Medium, where people are continuing the conversation by highlighting and responding to this story.