Server Side Rendering vs Client Side Rendering: Which one is faster and why?

Start a personal dev blog on your domain for free and grow your readership.

3.4K+ developers have started their personal blogs on Hashnode in the last one month.

Write in Markdown 路 Publish articles on custom domain 路 Gain readership on day zero 路 Automatic GitHub backup and more

Cliff Rowley's photo

There are lots of things to consider here, not just rendering speed. In fact, I would go as far as to say that rendering speed is probably the least important because if a site is optimised and cached correctly (and easily!) you probably won't notice much difference between them, however there are some technical pros and cons to each method that will either be a bonus or a burden depending on each particular project.

For example

Server side rendering:

  • Anything that is not generated on the fly can be cached, so the server load can be minimised.
  • Content is usually refreshed entirely as the user clicks around. Not always a bad thing, and typically what a user is used to - but this can be jarring in some instances, depending on the project. This can be mitigated somewhat by sending new content to the client (like turbolinks for example).
  • If errors occur, you know about them and they are logged on your server.
  • Since the server does most of the rendering, the reliance on client side javascript is minimal and therefore there will be fewer client side issues to deal with (less code requiring fewer browser capabilities is easier to keep compatible with more browsers).

Client side rendering:

  • As far as I'm aware aside from using modern browser features such as local storage, there's not really a way to cache generated client side code.
  • Content can be easily updated without reloading the entire page, which is essential for some sites (keeping chats open while browsing Facebook, for example) and can make the user experience feel more fluid (like Hashnode).
  • If errors occur, you will have to catch them client side and send them back to the server so you can be aware of them. This can be tricky and not always reliable.
  • Since the client does the rendering, you'll always need to be vigilant in ensuring you either use the lowest common denominator of capabilities, or providing browser specific workarounds. You still get this to some extent in server side rendering, because sites usually use javascript regardless of where they are rendered, but definitely less so.


There's also a third option that hasn't been mentioned, which is "universal" or "isomorphic" apps, which are rendered on both the server and the client. There's pretty much only one framework that can do this efficiently at the moment, which is Facebook's React framework. It works because the server side runs on Node, which itself is a Javascript environment. The server renders the initial page, including all its data and then subsequent navigation by the user simply updates the parts of the page that need to change. Hashnode is isomorphic. If you browse directly to any page you'll notice it appears that everything is loaded immediately, and then if you click around you'll notice the page doesn't reload. Refresh a page you've navigated to and you'll see it reload and appear with all data already present.

In a nutshell..

If your site isn't particularly dynamic, don't bother rendering client side. It's just not worth the headache. If your site is entirely dynamic, and is more like an app than a site, then client side rendering may be worth considering - but I would err toward React in this instance anyway. If your site is "realtime", for example if it has realtime chat like Facebook but you still need your users to be able to navigate while chatting (just one example), then React is pretty much a necessity.

Mario Giambanco's photo

Depends on the server load / server size / bandwidth / how the app is designed - a number of factors.

If the server is appropriately sized and there aren't that many users on the site at any given time, the server may be faster.

If the server sees a lot of traffic and struggles to keep up - the client side might be faster.

Most JS apps - either raw JS or with a framework still need to do some rendering once sent to the device - so expect those time constraints as well.

Dong Nguyen's photo

I think there are two clear points here:

  • actual speed of rendering
  • the feeling of user about rendering speed

The second looks like more inportant than the first one. So, with the "load and view" pages, I will try to render from server side; with the contents show as long as user is interacting, I will try to render at client side.

Jan Vladimir Mostert's photo

If you're going to display a page with lots of content, server-side is faster under perfect conditions assuming you have a server that has no performance limitations.

ServerSide - build HTML, fill in content, return, done.

ClientSide - return HTML template, send second request(s) to server to load content, morph UI, done.

Under real world conditions under heavy load, server side rendering will put a lot of extra load on your server, but given enough resources, the time from opening the page till it's usable will be faster than client-side rendering.


For pages where the initial page load has to be very fast (e.g. for E-Commerce pages) server side rendering is the better solution. If you want to offer an app with a fancy page transitions, lazy loading of content and less traffic you can consider client side rendering. If you want to reduce the working costs of your server client side rendering is the right choice as well. For the development of a single page application a javascript framework is a must have. Without a framework your client side code ends up in spaghetti code and is hardly maintainable. For mobile single page applications BackboneJS is the better choice because it is faster than AngularJS. If you want to create an application with a few lines of code and performance is a nice to have feature AngularJS is the perfect framework for you.