Table of Contents
Do you remember the simpler times when most web pages displayed only static content? When web pages were just plain web pages, with little or no way of interaction? Back then, the only motive of hosting such websites was to provide information about a company and its products, and to generate sales leads. Consequently, server-side rendering was the only way to get your HTML onto a screen. It was the only way that you could load your HTML onto a server and the server then turned them into useful documents for your users.
Fast forward to today. The scenario has changed drastically. Today, most websites are much more than static pages displaying content. In fact, they are nothing short of applications posing as websites. You can send messages, update online information, shop and do so much more. That is why, server-side rendering is slowly beginning to take a backseat and giving way to the ever-growing method of rendering webpages on the client side.
But how do you decide on the best approach for you?
Like most things in software development, it all depends on what you plan to do with your website. It is recommended to weigh the pros and cons, then decide the best route forward.
Let us give you a hand in making the right decision.
Starting with the basics -
What is Server-Side Rendering?
In server-side rendering when a user makes a request to a webpage, the server prepares an HTML page by fetching user-specific data and sends it to the user’s machine over the internet. The browser then construes the content and displays the page. This entire process of fetching data from the database, creating an HTML page and sending it to client happens in mere milliseconds.
Now Imagine that a user clicks a link on the page, the browser sends a request to the server and the entire process is carried out by the server again. This process not only increases the load on the server but also consumes unnecessary internet bandwidth.
What is Client-Side Rendering?
With client-side rendering, the initial page load is naturally a bit slow. However, after that, every subsequent page load is very fast. In this approach, communication with server happens only for getting the run-time data. Moreover, there is no need to reload the entire UI after every call to the server. The client-side framework manages to update UI with changed data by re-rendering only that particular DOM element.
Today, Angular and React.js are some of the best examples of libraries used in client-side rendering.
To help you understand the pros and cons of each approach, listed below are a few pointers that will guide you towards the right decision.
- Search engines can crawl the site for better SEO.
- The initial page load is faster.
- Great for static sites.
- Frequent server requests.
- An overall slow page rendering.
- Full page reloads.
- Non-rich site interactions.
- Rich site interactions
- Fast website rendering after the initial load.
- Great for web applications.
- Low SEO if not implemented correctly.
- Initial load might require more time.
- In most cases, requires an external library.
Now that you’re aware of the pros and cons of each approach, let’s take a look at ideal scenarios for their implementation.
When to use server-side rendering
- An application has very simple UI with fewer pages/features
- An application has less dynamic data
- Read preference of the site is more than write
- The focus is not on rich site and has few users
When to use client-side rendering
- An application has very complex UI with many pages/features
- An application has large and dynamic data
- Write preference of the site is more than reading
- The focus is on rich site and a huge number of users
In a nutshell, server-side rendering is like receiving a pre-assembled toy train set whereas client-side rendering is like receiving a dismantled one that you need to assemble yourself. You have to decide whether you’d like to play with a pre-assembled one or prefer assembling it just the way you want it.
Hope this blog helps you make the right decision. Do let me know your thoughts in comments.