Server Side Rendering vs Client Side Rendering: Which one is faster and why?
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
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.
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.
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.
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.
I think you would find this interesting http://www.onebigfluke.com/2015/01/experimentally-verified-why-client-side.html
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.
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.
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.