Server side vs  Client side rendering

Server side vs Client side rendering

If you've been around web development for some time now, you've probably heard about server side rendering (or SSR) and client side rendering (CSR). These are two possible ways your website can be rendered or presented to you final user, each with its characteristics, pros and cons.

Basically, in server side rendering html, css and js files are all rendered or "built" in the server and then sent to the client. On the other hand, with client side rendering, files are rendered on the client's computer. Let's see more in depth how each of way works and what are their pros an cons.

SSR

image.png

SSR is the most traditional method for displaying information onto the screen. It works by converting HTML files in the server into usable information for the browser.

Whenever you visit a website, your browser makes a request to the server that contains the contents of the website. The request may take longer or shorter depending on:

  • Your internet speed
  • The location of the server
  • How many users are trying to access the site
  • How optimized the website is, to name a few

Once the request is done processing, your browser gets back the fully rendered HTML and displays it on the screen. If you then decide to visit a different page on the website, your browser will once again make another request for the new information. This will occur each and every time you visit a page that your browser does not have a cached version of.

It doesn’t matter if the new page only has a few items that are different than the current page, the browser will ask for the entire new page and will re-render everything from the ground up.

This is the main weakness of this kind of rendering, on every change of content, no matter how little, the server will always re-render the whole page. This of course can lead to a slow user experience, depending on the conditions mentioned before.

On the bright side, server-side rendering is great for SEO. SEO works thanks to "crawlers" that scan the whole web analyzing the content of each website and ranking them according to certain parameters. Since with SSR the content is present on the server even before the user requests it, search engines are able to index it and crawl it just fine. Something that is not so with client-side rendering, as we will see.

CSR

image.png

When developers talk about client-side rendering, they’re talking about rendering content in the browser using JavaScript. So instead of getting all of the content from the HTML document itself, you are getting a bare-bones HTML document with a JavaScript file that will render the rest of the site using the browser.

This is a relatively new approach to rendering websites, and it didn't really become popular until JavaScript libraries started incorporating it into their style of development. Some notable examples are Vue.js and React.js.

This is an example of an html file that could be returned by a server with CSR.

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>Example Website</title>
</head>
<body>
  <div id="root">
    <app></app>
  </div>
  <script src="https://vuejs.org"type="text/javascript"></script>
  <script src="location/of/app.js"type="text/javascript"></script>
</body>
</html>

As you can see, It's "empty". There's no actual content but a div and two js scripts. This is because with CSR, it's javascript who is responsible for rendering the content. Content doesn't come previously rendered by the server, It's the client's job to render it now.

This is radically different than using server-side rendering because the server is now only responsible for loading just the "bones" of the website, the main boilerplate. Everything else is handled by a client-side JavaScript library, in this case, Vue.js, and custom JavaScript code.

With a client-side rendering solution, you redirect the request to a single HTML file and the server will deliver it without any content (or with a loading screen) until you fetch all the JavaScript and let the browser compile everything before rendering the content.

The key difference is that if you were to ask to load more content, the browser will not make another request to the server. Here you are rendering items with the browser, so it will instead use JavaScript to load the new content and Vue.js will make sure that only the new content is rendered. Everything else will be left alone. This is much faster since you are only loading a very small section of the page to fetch the new content, instead of loading the entire page.

There are some trade offs with using client-side rendering, though. Since the content is not rendered until the page is loaded on the browser, SEO for the website will take a hit. There are ways to get around this, but it’s not as easy as it is with server-side rendering.

Another thing to keep in mind is that your website/application won’t be able to load until all of the JavaScript is downloaded to the browser. Which makes sense, since it contains all the content that will be needed. If your users are using slow internet connection, it could make their initial loading time a bit long.

Closure

Server-side rendering allows developers to pre-populate a web page with custom user data directly on the server.

Client-side rendering allows developers to make their websites entirely rendered in the browser with JavaScript. Instead of having a different HTML page per route, a client-side rendered website creates each route dynamically directly in the browser. This approach spread once JS frameworks made it easy to take.

Client-side rendering manages the routing dynamically without refreshing the page every time a user requests a different route. But server-side rendering is able to display a fully populated page on the first load for any route of the website, whereas client-side rendering displays a blank page first.

There's no one way better than the other. Like a lot of things in web development, it depends on the kind of project you're building.

Server-side pros:

  • Search engines can crawl the site for better SEO.
  • The initial page load is faster.
  • Great for static sites, with not much interaction.

Server-side cons:

  • Frequent server requests.
  • An overall slow page rendering.
  • Full page reloads.
  • Not good for web applications with lots of interactions.

Client-side pros:

  • Fast website rendering after the initial load.
  • Great for web applications with lots of interactions.
  • Robust selection of JavaScript libraries.

Client-side cons:

  • Low SEO if not implemented correctly.
  • Initial load might require more time.
  • In most cases, requires an external library.

If my article was helpful, consider inviting me a coffee = )

Invitame un café en cafecito.app

Buy me a coffee

You can also follow me on Twitter and Linkedin