Andrew S.

Posted on Jul 13

Ways to Generate Pages: CSR, SSR, SSG, ISR

#webdev #frontend #programming #javascript

Along with SPA, several interesting concepts have emerged that may seem complicated and, at the very least, incomprehensible. What is the difference between client-side, server-side, static and incremental website generation? What is it anyway and how does it relate to Search Engine Optimisation (SEO)?

I suggest that you familiarise yourself with the following concepts and consider their advantages and disadvantages:

Client-Side Rendering (CSR);
Server-Side Rendering (SSR);
Static Site Generation (SSG);
Incremental Static Regeneration (ISR).

This material will be useful for Front-end developers of any level, because we will consider the concept, pros and cons of each approach, as well as the tools that can be used to implement them. I will use the React stack as a basis.

History

Before there was React or Angular, all websites were "multi-page" applications. We would open a website address in a browser, send a request to the server, where some conditional PHP would generate a whole page for us (all HTML, CSS, and a bit of JS) and return it to the client. When we clicked on a link to another page, sent the same request again, the server generated a new page and returned it. The browser deleted the old one and rendered the new one, with a kind of ‘blip’ when switching between pages. This approach is called Multi Page Application (MPA).

From an SEO perspective, this is the perfect approach. We have a full page with all the necessary information, and any search bot can read it immediately, our sites are at the top of search results, and our clients (the owners of these sites) are happy.

From the point of view of website users, it's not so perfect. Every time we open a new page, we wait for all the resources to load again and for the page to render. Of course, most of the resources are already cached, but we still wait for the page to be fully rendered. Well, no one has cancelled the transition blinks.

This approach was revolutionised by the emergence of frameworks that allowed to implement the so-called Single Page Application (SPA). The idea is that we load CSS, JS, and an almost empty HTML page once, and then JS builds everything in the client browser. When switching between pages, JS rebuilds only the part that has changed, and, if necessary, makes an AJAX request to the server to get the necessary data. We got rid of the blinks!

Customers are satisfied - we download the resources once and all pages are displayed smoothly in the browser. The user experience is similar to that of native mobile applications.

If all the resources have already been downloaded, why not store them on your phone and use them even when you don't have internet access? Progressive Web Apps will help you with this. Not all applications need to constantly download up-to-date information from the server, there are various games or static applications. And even if you do need to download information, such as articles, you can download them in advance and save them along with your files.

A Service Worker will help you implement this mechanism. And, as a bonus, by manually saving the application to your phone (and you can do it), it works without displaying browser navigation, just like a regular application installed from the App Store or Google Play.

SEO suffers. Search bots load the page, but there's nothing there, it's empty. They didn't know how to execute JS, so they couldn't get the same page as users. In addition, the URL did not change.

// An example of a page seen by a search bot.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">

    <title>SPA Aplication</title>

    <link rel="icon" href="/assets/favicon.ico">
    <link rel="stylesheet" href="styles.css">
  </head>
  <body>
    <div id="app"></div>

    <script src="main.js"></script>
  </body>
</html>

Over time, the URL began to change when navigating between pages. At first, it was hash navigation (using the # symbol, JS allowed you to change the hash in the address), then a full-fledged address change using the History API. Some search bots started to execute JS, but it was not a solution. Rendering a full page is a long and expensive process. Each bot has a so-called ‘budget’ - a limit on time, resources, and the number of pages it can crawl. Just imagine how many pages Google indexes every day - a huge amount of work.

The solution to the SEO problem is server-side rendering. It's time to take a closer look at it, but first, let's close the issue with client-side page generation.

Client-Side Rendering (CSR)

The approach is quite simple. The created application consists of several files: a stylesheet, scripts, and a conditionally empty HTML page where the styles and scripts are connected. In the index.html file, there is only one div with id="root", where the entire page is built. When you navigate between pages, the URL in the browser changes and data is pulled from the server, if necessary. The implementation is simple, the server load is minimal, because you do not need to render the page for each request, but only return static files. If you need data, you can create a separate RESTful server that will return data in JSON format.

As a bonus, it is easy to scale, and the data can be used by different clients (web pages, mobile applications, other servers). In addition, you can save money on hosting. You don't need a lot of resources to return a few files.

Of course, this approach suffers from SEO. Additionally, you may face problems when trying to share such pages on social media, because they also need to download the page, render it, and find the necessary data. And let's not forget about users: if they have old, weak phones, the page will take forever to render.

✅ Advantages:

Ease of implementation;
Less server load;
Relevance of information;
Do without a server;
Ease of scaling;
Cheaper hosting.

❌ Disadvantages:

SEO suffers;
social media crawlers and share issues;
more load on customers' devices;
JS file size at first download.

⚙️ Instruments:

Create React App;
React and manual configuration.

Server-Side Rendering (SSR)

The main feature of this approach is that the entire page is rendered on the server at the first request, and then, for example, React is initialised in the browser, and then the application works like a regular SPA, making AJAX requests to the server if necessary. The data loaded is always up-to-date, because every time the page reloads, a request to the server is made. From the SEO point of view, everything is also perfect: a full-fledged page is returned. Users are also satisfied - they work with a regular SPA and do not see any difference.

Although there is a need to maintain a powerful server that will handle all requests, there is an advantage. You can set up caching for the most popular requests, which will speed up page loading and display.

There are some difficulties with this approach. If you implement server-side rendering yourself using NodeJS, you need to:

Run, for example, React on the server to return the generated component. React comes with a function called ReactDOMServer.renderToString() that does this;
Pass the correct URL of the page, the server is not a browser. Let's use a static router - <StaticRouter location={req.originalUrl }>;
Get the data in advance and render the application using it;
After the page loads, run React so that we can navigate between pages, just like with client-side rendering. To do this, we use the ReactDOM.hydrate() function (ReactDOM.hydrateRoot() for the newer version of React). Unlike ReactDOM.render(), it doesn't hydrate the entire contents of the container, but only tries to add React event listeners to the pre-generated HTML.

✅ Advantages:

Perfect implementation of SEO;
Relevance of information;
Speed of loading and displaying content (Time to Interactive);
Server cache settings.

❌ Disadvantages:

Complexity of implementation;
Server load;
Increase in the size of files downloaded from the server;
Longer response from the server (TTFB - Time to first byte).

⚙️ Instruments:

Static Site Generation (SSG)

Do we need to generate a whole page on the server every time if the data is not updated that often? For various landing pages, business card sites, blogs, simple online stores where information is updated very rarely, server-side rendering support can be costly and redundant.

This is where SSG comes in. Why do you need to generate for each request if you can generate all the pages once when building the application? We simply put all HTML (CSS and JS) files in a folder, place them on a simple file server or even in a CDN and return them with each request. There is no server to process requests or generate pages. We get the maximum download speed and security. A safe server is a server that doesn't exist.

From the SEO point of view, this is an ideal option. For the user, the page is displayed even faster than with SSR, we don't wait for data on the server, so TTFB is smaller. For users, everything remains the same, because after the page loads, React is initialised again and the application works like a regular SPA.

From the SEO point of view, this is an ideal option. For the user, the page is displayed even faster than with SSR, we don't wait for data on the server, so TTFB is smaller. For users, everything remains the same, because after the page loads, React is initialised again and the application works like a regular SPA.

You may also wonder: what about user interaction with the site? What if you need to send a form or collect information? No one forbids you to launch a separate RESTful server that will be responsible for processing various requests from customers. You can also pay attention to Serverless or "cloud functions", I recommend taking a look at AWS Lambda or GCP Cloud functions.

✅ Advantages:

Perfect SEO implementation;
Loading and display speed;
Reliability and security (no server);
Cheap hosting.

❌ Disadvantages:

When updating content, you need to reassemble the project;
Time to generate a large number of pages, for example, for 100,000 products.

⚙️ Instruments:

GatsbyJS;
NextJS.

Incremental Static Regeneration (ISR)

This method combines the advantages of the previous two. You don't always need to generate a page for every request, and pre-generated pages are not a solution if the content is updated from time to time.

The solution is to split pages. Those that are updated more frequently will be rendered with SSR, while those that are rarely updated will be generated with SSG.

✅ Advantages:

Perfect SEO implementation;
Loading and display speed;
Can be used for some pages;
Relative relevance of information.

❌ Disadvantages:

The complexity of implementation;
Requires a server.

⚙️ Instruments:

NextJS.

Support ❤️

It took a lot of time and effort to create this material. If you found this article useful or interesting, please support my work with a small donation. It will help me to continue sharing my knowledge and ideas.

Make a contribution or Subscription to the author's content: Buy me a Coffee, Patreon, PayPal.