Comparing Page Generation Methods: CSR, SSR, SSG, ISR. A Guide Based on the React Stack
Hello everyone! My name is Maksym Rudnyi, and I have been working in commercial software development for over 10 years as a front-end developer. Over this time, web development has gone through several stages of evolution, and today, from a front-end perspective, we mainly use various JavaScript frameworks to create what are known as Single Page Applications (SPA).
Together with these SPAs, several interesting concepts have emerged in our lives that may seem complex and, at a minimum, unclear to beginners. What is the difference between client-side, server-side, static, and incremental site generation? And what is it in general, and how does it relate to search engine optimization (SEO)?
I propose to familiarize ourselves with the following concepts and examine 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, as we will consider the concept itself, the 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 the basis.
A bit of history
In ancient times, which most junior and middle developers can hardly remember — about 10 years ago — there were no Reacts or Angulars, and all websites were “multi-page” applications. We opened the website address in the browser, sent a request to the server, where some conditional PHP generated a whole page (all HTML, CSS, and a little JS) and returned it to the client. When we clicked on a link to another page, we sent the same request again, and the server generated a new page and returned it. The browser deleted the old page and rendered the new one, with a “flash” effect during transitions between pages. This approach is called a Multi-Page Application (MPA).
From an SEO point of view, this is the perfect approach. We have a complete page with all the necessary information, and any search engine bot reads it immediately, so our websites are at the top of the search results, and our clients (the owners of these websites) are happy.
From the users’ point of view, things are not so perfect. When opening each subsequent page, we wait for all the resources to load again and the page to be rendered. Of course, most of the resources are already cached, but we still expect the page to be fully rendered. Well, and the flashes during transitions were not canceled.
The revolution in this approach was the emergence of frameworks that allowed the implementation of so-called single-page applications — Single Page Applications (SPA). The essence is that we load CSS, JS, and practically empty HTML page once, and then JS builds everything in the client’s browser. When switching between pages, JS only rebuilds 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 flashes!
Users are satisfied — we load the resources once and all pages are smoothly displayed in the browser. The user experience is similar to using mobile native apps.
In fact, if all the resources are already loaded, why not save them on the phone and use them even when there is no internet connection? I present to you Progressive Web Apps. Not all apps need to constantly download up-to-date information from the server, there are various games or static apps. And even if information needs to be downloaded, such as articles, they can be downloaded in advance and saved along with the files.
To implement this mechanism, the service worker will help. And as a bonus, by manually saving the app on the phone (which is possible), it works without displaying the browser navigation, like a regular program installed from the App Store or Google Play.
However, SEO suffers. Search bots load the page, but there is nothing there, empty. They couldn’t execute JS, so they couldn’t get the same page as users. Moreover, the URL did not change.
Over time, URL addresses began to change when navigating between pages. Initially, it was hash navigation (using the # symbol, JS allowed changing the hash in the address), then a full change of the address using the HistoryAPI. Some search engines started to execute JS, but it was not a solution. Rendering a full page is a long and resource-intensive process. Each bot has a so-called “budget” — limitations 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 became 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)
CSR is an approach to generating web pages that is fairly simple, especially in our day and age. The created application consists of several files: a styles file, scripts, and a conditionally empty HTML page that imports styles and scripts. The index.html file contains only one div tag with id=”root”, where the entire page is built. When navigating between pages, the URL in the browser changes and data is pulled from the server as needed. The implementation is simple, with minimal load on the server because the page does not need to be rendered on every request, only static files need to be returned. If data is needed, a separate RESTful server can be created to return data in JSON format.
As a bonus, there is ease of scalability and the data can be used by different clients (web pages, mobile apps, and other servers). Additionally, hosting costs can be saved since only a few files need to be returned and not many resources are required.
However, this approach suffers in terms of SEO. There may also be issues when trying to share such pages on social media platforms since they also need to load and render the page and find the necessary data. Also, if users have old or weak phones, rendering the page may take a long time.
✅ Advantages:
- Easy implementation;
- Less load on the server;
- Timeliness of information;
- Can be done without a server;
- Easy scalability;
- Cheaper hosting.
❌ Disadvantages:
- Suffers in terms of SEO;
- Issues with social media crawlers and sharing;
- More load on client devices;
- Size of the JS file during initial loading.
⚙️ Tools:
- react-create-app;
- React and manual configuration.
Server-Side Rendering (SSR)
SSR is a method of generating web pages where the entire page is rendered on the server upon the first request, and then React is initialized in the browser, after which the application works like a normal SPA, making AJAX requests to the server as needed. The data is always up-to-date because the server is queried every time the page is refreshed. From an SEO standpoint, this approach is ideal because a fully-formed page is returned. Users are also satisfied because they work with a normal SPA and don’t notice any difference.
Although there is a need for a powerful server to handle all requests, there is also an advantage. You can set up caching for the most popular requests, which speeds up page loading and rendering.
This approach poses some challenges. If you want to implement server-side rendering on your own using NodeJS, you need to:
- Start React on the server to return the generated component. React has the ReactDOMServer.renderToString() function built-in for this purpose.
- Pass the correct URL of the page since the server is not a browser. We’ll use a static router — <StaticRouter location={req.originalUrl } >.
- Get the data in advance and render the application with it.
- After the page loads, start React so we can switch between pages, as in client-side rendering. The ReactDOM.hydrate() function is used for this purpose (ReactDOM.hydrateRoot() for the latest version of React). Unlike ReactDOM.render(), it doesn’t overwrite the entire content of the container, but tries to add React event listeners to the pre-generated HTML.
✅ Advantages:
- Ideal SEO implementation;
- Up-to-date information;
- Fast loading and rendering of content (Time to Interactive);
- Server caching configuration.
❌ Disadvantages:
- Complexity of implementation;
- Server load;
- Increased size of files downloaded from the server;
- Longer server response time (TTFB — Time to First Byte).
⚙️ Tools:
Static Site Generation (SSG)
Do we need to generate the entire page on the server every time if the data is not updated frequently? For various landing pages, business websites, blogs, simple online stores where information is updated very rarely, server-side rendering can be costly and redundant.
That’s where SSG comes in. Why generate on every request when you can generate all pages once during application build? Simply compile all HTML (CSS and JS) files into a folder, host them on a simple file server or even a CDN, and serve them with every request. No server required for processing requests or generating pages. This results in maximum speed and security. A safe server is one that doesn’t exist.
From an SEO perspective, this is the ideal approach. The page loads even faster than with SSR for the user, as we don’t wait for data on the server, resulting in a smaller TTFB. For users, everything remains the same because after the page loads, React and the application work like a regular SPA.
The downside of this approach is that when data is updated, the entire project must be rebuilt and all pages re-rendered. I wouldn’t call this a downside, more like a peculiarity. If the site contains around 100,000 pages, it may take several hours to generate. This needs to be taken into account.
There may also be questions about user interaction with the site. What to do if you need to submit a form or collect information? Nothing prevents you from running a separate RESTful server that will handle various requests from clients. You can also consider Serverless or “cloud functions,” I recommend taking a look at AWS Lambda or GCP Cloud Functions.
✅ Advantages:
- Ideal for SEO implementation;
- Fast loading and display speed;
- Reliability and security (no server required);
- Cheap hosting
❌ Disadvantages:
- Project needs to be rebuilt when content is updated;
- Generation time may be longer for a large number of pages, e.g., 100,000 products.
⚙️ Tools:
Incremental Static Regeneration (ISR)
ISR is a method that combines the benefits of the previous two approaches. It is not always necessary to generate a page with each request, and pre-generated pages are not a solution if the content is updated from time to time.
The solution is to separate the pages. Those that are updated more frequently will be rendered using SSR, while those that are rarely updated will be generated using SSG.
✅ Advantages:
- Ideal implementation for SEO;
- Fast loading and display;
- Can be applied to certain pages;
- Relatively up-to-date information.
❌ Disadvantages:
- Complex implementation;
- Server required.
⚙️ Tools:
** I recently created “Medium Stats” — FREE Chrome extension Medium Writers to explore their earnings easily.
If you enjoyed ❤️ it and want me to add more functionality, there is a small option to ☕ ☕☕buy coffee for me.