Three Considerations in Using CSS Frameworks in 2021
Every website you visit uses Cascading Style Sheets (CSS) to add styling. There are a myriad of...
Back when websites were just static web pages, server-side rendering (SSR) was the way to get your static HTML pages to display in the browser. But with the rise of advanced single page applications as websites and popular Javascript frontend frameworks such as React, client-side rendering (CSR) took over and became the new norm.
So, why is it that the frontend developer community is yet again excited about SSR? And what exactly is the difference between the two? Let’s dive in a bit deeper.
CLIENT-SIDE RENDERING
Have you ever visited a website, maybe under some spotty internet connection, only to be welcomed with a white screen, loading all the content, and then the page being rendered a few seconds later? This is what can happen with client-side rendering.
CSR uses Javascript in the browser, rather than the server, to render the page’s content. This means that the server sends over the HTML document containing the bare minimum--just a script tag or two that link to the Javascript bundle and perhaps the client-side Javascript library. With React, that would usually look something like this:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<link rel="icon" href="/favicon.ico">
<title>My React App</title>
</head>
<body>
<div id="root"></div>
<script src="/app.js"></script>
</body>
</html>
After this minimal work done by the server, Javascript will render the actual content in the browser, which is why that initial load may take a while with the white page. On the flip side, however, CSR makes it so that every time the browser needs to load new content for a new page, only the new pieces of information are loaded, rather than the whole page. This makes loading new pages after that first initial page much faster, as it doesn’t take any additional requests to the server--the browser will instead use Javascript to load only the new content!
The most noticeable disadvantage with client-side rendering is its low SEO (search engine optimization) performance. Search engines cannot crawl and index Javascript-generated content to display in search engine results. Google has limited capabilities to do so, but even then, it will delay when crawling and indexing client-side rendered websites because rendering Javascript takes additional computing resources.
SERVER-SIDE RENDERING
Server-side rendering, as you can guess, has the server do most of the work. The server converts the HTML pages, and responds with the HTML document fully ready to be rendered and displayed, without the browser having to wait for Javascript to be downloaded and executed. As such, SSR’s initial load time is faster than CSR, reducing the possibility of the dreaded blank white page.
But just like CSR, there is a flip side. When the browser requests new information to display, no matter how small the change is, the server renders the entire page again, rather than just the new content. Therefore, the loading time after the initial page may take longer.
Unlike CSR, SSR is great when it comes to SEO, as search engines can crawl and index the already rendered pages with ease. Search engines also favor sites with faster load times for SEO, so SSR’s superior initial page load time helps with better SEO performance in these two different ways. For a concise recap of SSR, check out this Educative article that also includes illustrations to more easily compare what happens with CSR and SSR.
With all that said, incorporating SSR with React is a lot more difficult than it may seem. Although developers can implement their own server-side rendering with React’s renderToString method and a Node.js server, there is no defined, go-to way to achieve SSR with React. Additionally, many React libraries will not support SSR, and even new features from React (such as React.lazy for code splitting and Suspense for data fetching) will not support SSR, at least not right away. But have no fear, as this is where Next.js comes in.
NEXT.JS
Next.js illustration from unDraw
Next.js is a framework that takes care of a lot of the inherent complexities of server-side rendering a React application. It provides a backend that can render a response on the server-side, and has many features including the below three, which mitigate the aforementioned weakness of SSR where the load time after the initial page may take longer due to rendering every single new page.
In addition to the above three, Next.js provides hot code reloading, dynamic components, static exports, TypeScript support, dynamic content based on dynamic URL, and more! Next.js is a great tool if you want to build a non-static site with SSR to take advantage of the speed and SEO performance.
IN SUMMARY
CSR is the current de-facto way of rendering web applications, with its benefits of being easier to implement and faster new page loads. However, SSR is coming back into the main discussion, largely thanks to Next.js. Its benefits are powerful--not only the faster initial load time and better SEO that comes with the traditional SSR to begin with, but the numerous elegant features of Next.js makes SSR a very attractive option for deploying your next web application.
Continue your learning here: