Server-Side Rendering vs Client-Side Rendering
In the Beginning
How old are you? The answer will be a good indication if you remember a time when the internet was static, undynamic, and stale. You see, when I was a kid in the 90s, the internet was able to just show information rather than allow much interaction with it. Every time you clicked to request more information or submit data, the entire page would reload. Websites looked like this:
Since the birth of the internet all the way up until the recent future, all of the content on the web has relied on server-side rendering to display in the browser. The creation of technologies like JavaScript and its many frameworks and libraries began to allow more interaction with sites in the browser and changed the way we render sites. This leads us to today, where most websites feel like fully interactive applications. Let’s take a look at all of the ways content on the internet can be rendered.
Server-Side Rendering
As stated above, SSR is the original way information has been rendered and displayed in the browser. The server gets a request from a user, compiles the HTML and the styles, and then sends a ready to be rendered HTML page to the browser to be displayed. When the user interacts with the page like clicking on a link or submitting information, the entire process happens again. However, since the rise of JavaScript and its many frameworks and libraries, this process has become less arcane. JavaScript allows us to interact without always having to do full page reloads. So, back to rendering, when the fully populated HTML page reaches the user’s browser, the browser then downloads the accompanying JavaScript files. The site won’t be interactive until the JS files are downloaded, but the user can see the content almost immediately. This is beneficial if your website doesn’t have much interactivity and is mostly static as it will appear to load faster to the user than it would with client-side rendering. Another benefit of server-side rendering is better search engine optimization (SEO). Since the site’s content is present before it reaches you, search engine bots are able to crawl the entire site and provide the search engine with more info. This can have a huge impact if your site is data-heavy and has items that people are doing Google searches for i.e. Walmart (who recently switched from client-side to server-side rendering via Electrode). One of the drawbacks of SSR is bottlenecking, when the server has a lot of users or if the site is large it can cause major slowdowns when the page is being rendered. Server-side rendering has been a very complicated process for single-page applications until recently. Many new frameworks like Next.js have been developed to use popular libraries like React to build apps with server-side rendering without the previous headaches.
Client-Side Rendering
Since the dawn of popular front-end frameworks and libraries like React and Vue, developers have shifted toward client-side rendering (CSR). When a user makes a request to a server, the server sends the user a single file for the website. The HTML file has links to other files that are then downloaded, compiled, and rendered in the browser on the client-side. The user will not see anything until the JavaScript files have downloaded and compiled (except maybe a loading screen). Initially, this offered a new and more interactive way to engage with websites. The user could interact with the entire website without having full page reloads like in the early days of the internet. This was a big deal and allowed websites to start functioning more like dynamic applications. There are some downsides though. The first site request comes with a big initial download. Also, SEO is less than ideal for these sites. Since the content isn’t compiled until it gets to the client’s browsers, search engine bots are unable to crawl the sites properly. Just think about what the HTML looks like in a React app until it gets compiled to the browser. It’s basically a single div with an id of “root”. Since the entire app is being compiled in the browser, the user’s internet speed will also play a major role in how efficient the operation is. However, since the entire site is downloaded at once, many parts of the site can actually keep functioning even if the user is offline. Ultimately, the result is a highly interactive web page that can navigate its views with no page reloads.
Takeaways
Static sites will always be better off using SSR. Their content will be visible to the user faster (although not interactive until the JS downloads) and the content of the page will be properly indexed by search engine bots. SSR will also be of assistance during page loads if the user has a slow internet connection. Until recently, development for JavaScript-based dynamic web applications has been easiest by using client-side rendering. A popular example is the create-react-app package that gives developers an out-of-the-box React app ready to be rendered client-side with little to no configuration. This is starting to change as frameworks like Next.js (mentioned earlier) are making it easier to develop dynamic web apps that are server-side rendered. Many people believe this is the future since it combines superior search engine optimization and all the benefits that client-side rendering gave us.
As always, thanks for reading. Feel free to connect with me on LinkedIn!
