Traditionally, the browser receives HTML from the server and renders it. When the user navigates to another URL, a full-page refresh is required and the server sends fresh new HTML for the new page. This is called server-side rendering.
Fast forward to today. When websites have 1000s of lines of code to render and with much more complex structures. Today, websites are more than just static pages. The downfall of SSR came when the websites were not all about allowing the user to perform actions and receive a response for their action. That is why developers shifted the ever-growing method of rendering web pages on the client-side.
But, here are the questions-
- Is SSR still relevant? If yes, where to use it.
- the best approach for you?
In SSR, when the user makes a request to the webpage, the server prepares the HTML page by fetching the required data from the database and sends to the user's machine over the internet. Then the browser presents all the requested actions on the user UI. All these processes of fetching data from the database to creating an HTML page and sending it to the client are done in mere milliseconds.
This method is viable if all your website need is to display images/ texts, links to click, and is more on the static side.
In server-side rendered pages, it is common to use snippets of jQuery to add user interactivity to each page. However, when building large apps, just jQuery is insufficient. After all, jQuery is primarily a library for DOM manipulation and it's not a framework; it does not define a clear structure and organization for your app.
Developers are approaching CSR as modern-day development is mostly about JS libraries and frameworks. The popularity of modern-age JS shifted all the attention to CSR.
Also, a clear client-server separation scales better for larger engineering teams, as the client and server code can be developed and released independently. This is especially so at Grab when we have multiple client apps hitting the same API server.
For more clear view let's see some benefits and downside of both rendering methods-
Benefits of SSR -
- The initial page of the website load is faster as there are fewer codes to render.
- Good for minimal and static sites.
- Search engines can crawl the site for better SEO.
Downsides of SSR -
- the site interactions are less.
- Slow page rendering.
- Full UI reloads.
- Frequent server requests.
Benefits of CSR -
- The app feels more responsive and users do not see the flash between page navigations due to full-page refreshes.
- Fewer HTTP requests are made to the server, as the same assets do not have to be downloaded again for each page load.
- Clear separation of the concerns between the client and the server; you can easily build new clients for different platforms (e.g. mobile, chatbots, smartwatches) without having to modify the server code. You can also modify the technology stack on the client and server independently, as long as the API contract is not broken.
Downsides of CSR -
- Heavier initial page load due to loading of the framework, app code, and assets required for multiple pages.
- There's an additional step to be done on your server which is to configure it to route all requests to a single entry point and allow client-side routing to take over from there.
- In most cases, requires an external library.
- An application has a 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 sites and has few users
- An application has a 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 sites and a huge number of users
The rendering method totally depends on the requirements and the UX plan of the client. The final call is yours whether to use SSR or CSR.
I hope this article helped you to understand the basic concepts of rendering practice.
Thank You for reading till the end!