Over the years, rendering content on a page has developed to have a lot more possibility than just rendering from a server, which used to always be the case. Nowadays there is also client-side rendering, and both client and server sides have their pros and cons. Here are some questions I will be going through in this post:
- What is server-side rendering?
- What is server-side rendering good for and why?
- How does it differ from client-side rendering?
Let's get started!
So...what is server-side rendering?
It's one way to send data to a user's browser in order to display content. The content itself is converted to HTML in the server, rendered, and then sent to the browser. This is why with server-side rendering, you'll see that the content of the page loads a lot faster.
For every page the user wants to go to, a new HTML file is rendered and sent to the client. These files are often static because you're sending multiple files; for every change made, the server will send a new page with new information that is based on the change made by the user. To the user, they'll see that every page is being reloaded entirely no matter what changes they make, which won't flow as well in terms of user experience.
In a nutshell, server-side rendering takes converted static files, HTML and CSS, and sends it over to the browser, where it will load the content for the user to see. If the user requests a change, the server will send a new file to reflect that change.
What are the benefits of server-side rendering?
When you render files from the server, as mentioned above, the content on the browser will load a lot faster as the client-side doesn't need to do as much work to get the contents displayed. This makes for painting the page on the initial load a breeze, and will keep potential users on your app!
Because all the file rendering is done in the server, there will be a huge boost in performance for the client, since every page that's being sent simply needs to be loaded; the client doesn't have to do any conversions or rendering. That means that for the user, they'll likely have to wait less for any initial loads to load on their screen. This is definitely something to keep in mind if your app is serving lots of users.
Search engine optimization (SEO) will also work in your favor here. Because server-side rendering means rendering the files before they're sent, the page information will already be available to the browser before a user gets to see it, so the page information will be caught a lot quicker by the search engine's algorithm. That means your page could be one of the many apps that users see first!
Overall, server-side rendering is good for speed and performance, but this is generally helpful if you have a lot of static files as opposed to files that are more dynamic, which is what client-side rendering covers. We'll cover it briefly here, but a good rule of thumb is if your app has a lot of static files or runs statically, you'll benefit from server-side rendering.
What about client-side rendering?
The biggest difference between server-side rendering and client-side rendering is where the page content is rendered (you can tell from their names alone!). In this case, the content is rendered on the client-side, or the browser, which has its pros and cons.
For client-side rendering, your pages might look a lot more dynamic, especially if you're using JavaScript frameworks like React, Vue, Angular, etc. That means that the majority, if not all of the content, will be in JavaScript as opposed to HTML. The browser will render the HTML fairly quickly, but that's all the user would get until the JavaScript is rendered, and only then will the content be displayed. If your user's internet is slow, that's going to be a very slow initial load!
Unlike server-side rendering, where you'll have to send multiple pages and fully reload entire pages, client-side rendering allows for single-page applications (SPA). This can make the user's experience flow a lot more smoothly, as they won't have to load a brand new page every time they did something new. All changes made by a user will be reflected on the same page, which can look quite fast if implemented correctly.
Conclusion
Whichever one you choose, keep in mind that they work better depending on the app you're making, and there are quite a few factors to keep in mind when choosing how to render your app, especially when it comes to a user's interaction with it and the kind of data you're working with. Getting a chance to build with both will allow for some deeper internalization!
Latest comments (8)
Lots of good information thanks for sharing with us ❤️
Great write up! Lots of useful information, thanks.
You failed to mention one big advantage of server side rendering which is security. Clients cannot see and potentially manipulate data being sent to the backend. There are of course ways to prevent data manipulation, but this is something you don't even have to think about when all logic is handled on the server and processed before sending the output to the client.
And a major disadvantage of server side rendering that you didn't mention is that you require a full page reload to change any content on the page. If you need to scroll to page 2 of a record set, the entire page must be reloaded. Client side rendering is much faster at this as it can do a simple API call and just load the new data into the table without needing to reload all of the page assets. This makes your biggest advantage of "server side being faster" very conditional on the type of content and interactions the user has with the content.
Overall good article, but I think you needed to mention those points.
Client-side or SSR, security-sensitive items need to be handled on the backend; however, there needs to be input validation on both frontend (for good UX) and backend (for data integrity/security).
Also, SSR doesn't necessarily mean that renders are only handled by page load. It's very common for SSR to perform initial render and then hand off to the client for hydrating without additional page loads.
Imagine taking the time to write an article to educate people and being told by someone, "you failed to mention".
Please be more considerate when writing comments. This could have been worded a lot better.
It’s crazy how easily some people seem to get offended (or assume someone else would be offended) these days. If you are not ready to take constructive criticism online then better not to write anything at all.
You fail to mention where I said overall it was a great article, I just feel it could have included certain other points relevant to the topic. Sorry if I offended anyone, and sorry if my comment was not 100% accurate.
At the end of the day, server side rendering or client side, you cannot make a speed comparison without context of the use case. What if you are submitting some data to be processed, on server side your page would be "hung" until the server processed it and was able to generate content for the page reload after having done its logic. Client side could give you a progress bar and simply wait for an API call to complete and refresh on the page just the relevant components. There are too many variables to just say "server side is faster", that is all I was trying to mention in my comment.
This isn't quite true. With SSR apps you still have to support some form of a user modifying data (adding a like to a post or sending a comment) via POST or equivalent requests
It's in this act of giving the ability to the users that security is brought into question because then you have to start thinking about verifying the inputs and authentication and all that. SSR apps can't avoid ANY of this, they have to think about it as much as client rendered apps.
On the other hand, client rendered apps without any authentication or ability for users to modify anything gain the same benefit of "not having to think about security" anyway. So this benefit isn't tied to a rendering method, but to the content being rendered and potentially modified
Some comments may only be visible to logged-in visitors. Sign in to view all comments.