Server-Side Rendering (SSR)

Even though server-side rendering (SSR) sounds like a new term in the developer’s vocabulary, it’s actually the most common way of serving web pages. If we think of languages such as PHP, Ruby, or Python, they all render the HTML on the server before sending it to the browser, which will make the markup dynamic once all the JavaScript content has been loaded.

Well, Next.js does the same thing by dynamically rendering an HTML page on the server for each request, then sending it to the web browser. The framework will also inject its scripts to make the server-side rendered pages dynamic in a process called hydrationHydration is a process in which client-side JavaScript converts a static HTML web page into a dynamic web page..

Imagine we’re building a blog and want to display all the articles written by a specific author on a single page. This can be a great use case for SSR: a user wants to access this page, so the server renders it and sends the resulting HTML to the client. At this point, the browser will download all the scripts requested by the page and hydrate the DOM, making it interactive without any kind of page refresh or glitch. From this point, thanks to React hydration, the web app can also become a single-page application (SPA), taking all the advantages of both client-side rendering (CSR) and SSR.

Advantages of SSR

Talking about the advantages of adopting a specific rendering strategy, SSR provides multiple benefits over the standard React CSR:

• More secure web apps: Rendering a page on the server side means that activities such as managing cookies, calling private APIs, and data validation happen on the server, so we’ll never expose private data to the client.

• More compatible websites: The website will be available even if the user has disabled JavaScript or uses an older browser.

• Enhanced search engine optimization: Since the client will receive the HTML content as soon as the server renders and sends it, the search engine spiders (bots that crawl the web pages) will not need to wait for the page to be rendered on the client side. This will improve our web app’s SEO score.

Limitations of SSR

Despite those great advantages, there are times when SSR might not be the best solution for our website. In fact, with SSR, we will need to deploy our web application to a server that will rerender a page as soon as it’s required. As we’ll see later, with both CSR and static site generation (SSG), we can deploy static HTML files to any cloud provider, such as Vercel or Netlify, for free (or at a meager cost); if we’re already deploying our web app using a custom server, we have to remember that an SSR app will always lead to a more significant server workload and maintenance costs.