As internet history continues and development advances, the web, the internet's flagship medium, keeps growing larger as well. In its early days, the web only showed simple pages based on static data, but now it handles large-scale business logic without difficulty. Following this trend, the weight carried by pages, the web's basic unit, keeps growing as well.

We enjoy dozens of pages every day. Users simply engage in the activity of "viewing a page," but as with everything, there are many hidden operations behind the scenes.

Among them, much thought goes into the logic for rendering — that is, drawing — a page in order to show it to the user. Showing a page faster and more efficiently leads to a better page UX.

As a result of this deliberation, there are currently three page rendering techniques: CSR, SSR, and SSG.

This document covers each of these page rendering techniques.

Have you ever heard stories from the old days about literally standing in line at school to register for classes? Back before I was even born, computers apparently weren't as common as they are now.

Because of this, internet technology was also stuck at an early stage, and even the techniques we now take for granted without a second thought were probably treated as bold and difficult at the time. Naturally, the concept of a "page" was also very different from today, and even simply displaying "information" on a website was quite a feat back then.

Because of this, the rendering method for web pages back in those days was very simple. It just delivered the file at the requested URL.

Of course, even today, static rendering is still used depending on the purpose of a site. Web servers like Nginx, Apache, and IIS provide typical static rendering.

If you supply a folder to serve, it's a method of accessing the files under that folder based on the URL structure. However, this kind of simple routing has the drawback of making it very difficult to change a page's content.

Before AJAX (Asynchronous JavaScript And XML) technology emerged, every web page could not dynamically change content it had already displayed, and could only keep showing the same content over and over.

Since asynchronous technologies like AJAX appeared, various rendering methods have emerged to solve this problem.

Among these, the first is CSR, a method where page rendering is performed on the client, such as the browser.

CSR bundles all the JS and CSS used in a web service into single files, such as index.js and index.css. Every page uses this bundled file to render the page.

When you request a page from the server, the server provides an empty HTML file along with the bundled index.js and index.css. The moment the browser receives the response, nothing is displayed on the page at all. Afterward, the browser analyzes the JS and CSS to render the page the user requested.

Since every page requires the same files, the JS and CSS requests only need to happen once. Since all the information is already declared in the bundled file, it effectively already has all the information needed to render the page. This structure is very convenient for implementing an SPA (Single Page Application).

Only the desired part of the page can be immediately re-rendered with new information, and the flicker (FOUC) that occurs when navigating between pages can be effectively eliminated. Also, if you make good use of caching policies, the service can be used even in an offline environment after the page loads.

However, the bundled file is a single combined file containing all the code for the entire site, so its size is very large, a clear drawback. This size leads to a delay in the initial page load. Not only that, CSR is also very vulnerable to SEO. This is because, before the browser renders it, CSR displays an empty HTML page for any URL prior to rendering. In other words, SEO engines have a very hard time parsing CSR pages.

React can be used to provide CSR.

• 👍 Advantages

  • Very little server burden
  • Fast and smooth page rendering

• 👎 Disadvantages

  • Delayed initial rendering due to a relatively large bundle file
  • Weak SEO
  • Easily affected by the user's device performance

• 🔎 Use case

  • Small-scale projects

SSR is a method where page rendering is performed on the server.

With SSR, the server receives the request for each URL and responds by rendering the page according to defined logic. Unlike CSR, where the server had it easy, with SSR, the browser's role is very light. The browser's job is basically just to display the file provided by the server as-is and execute the scripts.

Since only the minimum resources necessary for each page can be used, the initial load is relatively faster compared to CSR. Since basic rendering is already complete by the time the browser receives the response, it's also favorable for SEO. Whereas in CSR, the SEO engine could only see an empty shell, in SSR it can access a fully rendered page.

However, SSR requires a meaningful burden on the server for each page request. Also, unlike CSR, which can be implemented with just a simple routing server, SSR requires a server you can directly control. In other words, whether it's AWS or your own computer, you need a server you can directly code, one way or another. This isn't merely a rhetorical cost like time spent — it's a real cost, depending on the person or the situation.

SSR can be provided through Tomcat's Servlet or Node.js's Express.

• 👍 Advantages

  • Fast initial rendering time due to a relatively small bundle file
  • SEO-friendly
  • Provides relatively consistent performance regardless of the user's device

• 👎 Disadvantages

  • Serverless services are not possible
  • Incurs economic cost
  • Continuous server burden on every page navigation

• 🔎 Use case

  • Large-scale business services

Both CSR and SSR have their own strengths and weaknesses. However, if content rarely changes or is predictable, there's no need for the server or client to render it in such a complex way.

SSG was conceived from this idea, generating a file for each URL by building the HTML, JS, and CSS for each page. Since the files are already predefined, it offers very fast static rendering, though its functionality is limited.

With SSG, the already-rendered page itself is built entirely at build time. Because of this characteristic, both CSR and SSR content can be built and operated as SSG.

No matter how complex a page is, since it's already converted into a properly built file, there's no problem at all using the simple technique of static rendering. Also, since it's a method of delivering an already generated file, there's no issue at all for SEO engines to analyze it.

In some cases, SSG also has a perfect superset of advantages, including both CSR's and SSR's strengths.

However, you have to keep performing the build process every time the content changes.

For React, Next.js and Gatsby.js provide SSG. In fact, this very blog you're reading right now is also a site built with SSG.

• 👍 Advantages

  • Can absorb the advantages of both CSR and SSR
  • SEO-friendly

• 👎 Disadvantages

  • High importance placed on the build process

• 🔎 Use case

  • Services with relatively static content (blogs, etc.)

From the user's perspective, it's all just the same site, but behind the scenes there are several rendering methods, each with its own strengths and weaknesses.

None of these three rendering methods is a perfect superset of the others. Understand the pros and cons of each rendering method, and choose the rendering technique that fits the service you're trying to build.