Every website you visit uses Cascading Style Sheets (CSS) to add styling. There are a myriad of...
Server-side Rendering - SSR vs. CSR, and an Intro to Next.js
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.
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.
<link rel="icon" href="/favicon.ico">
<title>My React App</title>
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 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.
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: