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.
What Is 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 web 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 client's browser, which is why that initial load may take a while with the white page.
Advantages of Client-Side Rendering
CSR makes it so that every time the browser downloads new JavaScript content for a new page, only the new pieces of information are loaded, rather than the whole web page.
This makes loading new pages after that first initial page much faster, as it doesn’t take any additional server requests to the server--the browser will instead use Javascript to load only the new content!
Setbacks of Client-Side Rendering
The most noticeable disadvantage of 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. Here, the server converts the HTML files and responds with a fully rendered HTML page, ready to be displayed in the client's browser without waiting for Javascript to load. 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.
Advantages of Server-Side Rendering
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.
Setbacks of Server-Side Rendering
While SSR improves initial load speed and SEO, it has its challenges. Every time the browser requests new data to display, SSR requires fetching data and rendering the entire page again on the server. This process means longer wait times for each new interaction compared to CSR, where the browser fetches only specific pieces of data, allowing for quicker updates within the same page.
Additionally, 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.
Something else to be aware of is that, 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.
Introdution to 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.
By enabling the delivery of user-specific data along with fully rendered HTML, Next.js ensures a faster initial load time and an SEO advantage while handling complex, individualized content seamlessly.
In Next.js, each page is typically a React component, and it’s exported using export default, as in export default Homepage;, to signify the main component to be rendered. This setup allows Next.js to optimize each page individually, leveraging features like hot code reloading, static exports, and dynamic content based on URL parameters.
In addition to the above three, Next.js provides hot code reloading, dynamic server 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.
Server-Side Rendering: Next Steps
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.
Next.js simplifies integrating a server component to manage the initial HTML load, making SSR a viable option for speed-focused applications. 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:
More on Server-Side Rendering
Why is CSR better than SSR?
Client-Side Rendering (CSR) is often better than Server-Side Rendering for dynamic web applications that require high interactivity and frequent client-side updates. CSR can reduce server load and provide a faster, more responsive user experience, as content updates without needing to reload entire pages. Keep in mind, though, that CSR may lead to longer initial load times, especially for larger applications.
Does Next.js do server-side rendering?
Yes, Next.js supports server-side rendering (SSR) out of the box, along with static site generation and client-side rendering. With Next.js, you can choose SSR for specific pages or components where dynamic, server-rendered content is essential, so you've got that flexibility based on the needs of each part of an application.
When to use SSR vs CSR?
SSR is a great option for pages that need quick initial loads, search engine optimization, or content that changes frequently server-side. CSR is better suited to interactive applications where speed after the initial load matters, as it shifts rendering to the client. Generally, SSR is the better choice for static or content-heavy pages, while CSR works well for single-page applications.