Rendering on the web (Client Side, Server Side, Static & Pre-rendering)
Welcome back my readers! Today, I have chosen a very hot topic or I would say very important topic for web developers and even marketers. Why I address it as important? You got it? No. Not an issue! Let’s understand it first.
As we all know, without an audience, your product is nothing! That’s why, web developers, marketers give their day and night to make their website visible to search engines. Everybody wants their website to come on top in search results like me, wishing this article to come on top whenever anybody searches about the different rendering on the web. How to do it? I would say, for me, it’s a hard question. A lot of factors play a role in it. I would address three of them, which I think is relevant to the topic. Page Speed, Metadatas and content. These three factors can affect a lot your website ranking. How these factors get affected by the different approaches of rendering that we will understand in this article. But, till now, I think the answer which I wanted to give you about the topic's importance is done. I hope you got its importance. Right?
Now, you may be eager to know what are actually these rendering approaches. No worry! I will take you in depth, but before that, I want to address one of my article that focuses on what happens when you hit any url. Why I addressed it? Because I think the current topic is somehow has connection with it. After hitting the url, different steps take place and finally you got your responsible web pages, but, how these web pages are processed and gets visible on your screen is another interesting thing. In this article, this interesting thing is covered. The answer of how web pages are processed lies in the rendering approaches. Server-side, Client-side, Static and Pre-rendering are the different approaches in the current market. Without any wait, let’s understand each one of it, one by one.
Server Side Rendering -
Server side rendering or commonly known as SSR. It is not a new way of rendering your webpage on the browser. It is a traditional way where a server is responsible for generating the full HTML content. What I mean by full HTML content is having all metadatas, responsible CSS, JS and content (static and dynamic). You know dynamic content, right? If No, here is an answer.
As you know, it’s quite common in a webpage to have dynamic content. Dynamic content means a content that is not static say, different content for different users or content change using JS. For example, Facebook provides dynamic content, as every user gets different content based on their interactions. This is dynamic content. I think we have distracted from our main sub-topic. Let’s get into it again.
So, you have seen, in this process, Server handles everything. Dynamic content generation, HTML conversion and sending it to browser are handled by the server. That’s why, it is called Server-side rendering.
To better understand, here is a graphical representation:
I hope, above diagram will make you better understand.
Well, you understood what is Server Side rendering, but what are its pros and cons. Why you should go with it and why not.
Pros —
Better FCP and TTI :
SSR helps you in improving First Contentful paint (FCP) and Time to interactive (TTI). You know these metrics. Right? If not, check out this (link).
How FCP improves? As the responsibility of generating the HTML relies on the server. A machine which has more computing power and high networking speed. More speed and power means faster generation of HTML content (faster dynamic content loading) which, in turn, faster response from the server for your request. This results better FCP.
How TTI improves? As dynamic content loading and all logic run on the server which makes possible to avoid sending a lot of JS files to client. This means the less JS file size (assuming the client side JS is limited) to download for a client which in turn makes better TTI.
Better SEO:
Initially, in my article, I mentioned that page speed impacts SEO. Not only SEO, page speed also provides better user experience. From above point, you got how SSR improves page speed, but there are other factors like metadatas, content that also improves SEO. SSR also proves better in this. SSR provides full HTML content that means right meta data as well as content. Crawlers better see the page’s title, keywords and other metadata, which in turn makes them able to apply algorithms to it to index your page. Irrespective of crawlers understand Javascript or not, SSR always does good in SEO.
Cons —
Lower TTFB (Time to First Byte) :
As the server is responsible for generating full HTML content that means server takes time to respond to user’s request which, in turn, makes the browser to render its first byte little late.
More Server workload -
As server burden is more, fewer requests can be executed per second. Although, it can be improved by enhancing server RAM and processing power.
Same loading time on navigation -
Unlike CSR (don’t have an idea about it, will talk later), on navigation, there is no improved speed. Full reload takes place on the route change. The Whole request cycle is followed like in first page reload happens. Hence, same page speed.
This is all about SSR. Let’s move to CSR.
Client Side rendering -
CSR. You must have heard this word when you started your journey in one of the frameworks and library like Angular, ReactJS, VueJS. Client Side rendering or CSR is a new approach where the client is responsible for generating full HTML content. In this process, Client handles everything. Data fetching, all page logic, routing and HTML preparation is handled by the client. That’s why, it is called Client-side rendering.
In CSR, user gets single HTML file without any content, but with CSS and JS linked to it. User sees the blank page until the browser fetches the linked JS & CSS and prepare a full HTML content. I would recommend you to build your react or angular project (I know you must have built it). After build, you can see one html (index) and one JS file (bundle.js) is there. In the HTML file, no content is there, but on hitting any url, you will see the actual content after some time. How? This is Client side rendering. Browser prepares the content and you see it. Isn’t cool? You like this approach? Before taking any decision, let’s also understand its pros and cons.
Pros —
Fast TTFB -
As you know, the server has to just send a single HTML file with linked Js and CSS. Hence, this process does not take time, which in turn makes the browser to render its first byte faster.
Less Server load -
As everything is handled by Client, server just has to provide single HTML file. Hence, server load is less meaning more requests can be executed per second.
Better Caching -
CSR provides a better caching option. As you know, the whole process happens in Client. You can cached that single HTML file with the bundle.js. This makes TTFB even more faster.
Although, you can apply caching for SSR as well. The pages whose content has not changed a lot with time like search results page. You can cache them and when any update in db happens, just purge the cache and cache them again.
Better Navigation Experience -
Once the initial load is done, user experience negligible time to switch between different routes. Better UX. As necessary scripts are already loaded during initial load, hence, no further request is made to server (not in case of lazy loading) which, in turn, means faster load time.
Cons -
Bad FCP and TTI -
I believe, this is the biggest cons that CSR has. Why? As you know, the user doesn’t wait more for your site to get loaded. If any site takes longer time to load, user left. I do and even everybody does the same. It’s quite common. Everybody wants to see the web page sooner. That’s why, developers try their best to decrease FCP and TTI time, but as in CSR, everything goes in one download. More JS size, more time to download it and hence, bad FCP and TTI. It’s quite common to have the larger JS file as the application grows.
Note: There are ways to solve it like code splitting and make sure to lazy load — when there is a need, then serve what you need.
Poor SEO -
Another big concern is SEO. I believe, nobody wants to compromise in SEO if your website is customer facing. Crawlers work well for server-side rendered pages where the HTML in the response contains metadatas, content, but, in CSR, where the initial HTML does not contain the actual content and metadatas and hence, considers it useless page as it contains nothing and ranked it poorer.
Although, in recent times, Google announced that Googlebot is now able to execute JS but other crawlers like yahoo’s, bing one don’t execute.
Note: It is said that Googlebot executes JS but, you can’t tell how successful it is. That’s why, don’t take risk and render your page in such a way that crawlers understand like HTML with full content.
This is all about CSR. Now, it’s time for static rendering.
Static rendering -
This is also one of Server-side rendering. This is Static SSR. Unlike dynamic SSR (you can think above mentioned SSR as dynamic because HTML is generated on demand for each request), HTML is generated at build time. Confused? Let me elaborate it. In Static rendering, HTML is generated for each URL ahead of time. As HTML response is already prepared for every request, we can store them all over the world on CDNs meaning faster responses to every request of user.
Seems Cool? Yes! No! Yes! No! Not able to take a decision. Let’s dive into its pros and cons.
Pros -
Fast TTFB -
Unlike dynamic SSR (where HTML is generated on demand), in static rendering, HTML response is already prepared, hence, the process does not take time to respond which in turn, making Fast TTFB.
Fast FCP and TTI -
As HTML responses are already prepared for each possible request, which means fast FCP and TTI (assuming the client side JS is limited).
Better Caching -
As I have already stated about distributing already prepared HTML response all over the world on CDNs, which in turn, makes your site to get ridiculously faster responses. This makes TTFB even more faster.
Better SEO -
I will not elaborate it as you definitely got it, why static rendering gives better SEO. Better page speed and all content are the reason.
Cons -
I will not make a points for cons. As the biggest cons lie in the statement — HTML is generated for each URL at build time. It is quite challenging and even infeasible for some sites that contains a large number of unique pages. For example, search page where thousands, lakhs of unique pages are there. Wait, you are thinking when to choose static rendering? Here is your answer. If the answer is ‘Yes’ for below questions, go with Static rendering -
1. You can predict all possible requests, a user can make.
2. If HTML response is not different for different users like home page, service page etc.
3. If response does not change quickly.
Keep these questions in mind and get your answer whether to go with static rendering or not.
Lastly, get into pre-rendering.
Pre-rendering -
As its name itself explains, pre-rendering means a page is rendering in the background i.e. loading the content of other pages in the background, in a hope that user can go there. If the user goes there, that page loads very quickly as some of its content is already loaded ahead of time. Pre-rendering provides better user experience.
I have read somewhere, that Google pre-renders the first webpage of top search results (if browser supports it) as Google assumes top results is likely to be clicked and hence, providing a better user experience.
Well! Pre-rendering not only provides a better experience for us (humans) but also to bots. You might think why bots came into the picture. Let’s understand it.
As you know, when crawlers crawl your web page, they look into your content, metadatas and also navigation (links within the page). Bots make sure that the link should work properly and have decent initial load time. That’s why, pre-rendering is quite important, even more important if your website is SPA.
I will not get into its depth. Whatever I know, I have written it. I hope, now, you can answer what is pre-rendering and why it is important? For deep knowledge, you have to check other articles.
This is all about the topic. I have tried my best to explain each and every thing in very simple manner. If you liked it, then it would seem that hard work got justice.
You can also explore other articles of mine on medium or freeCodeCamp.
