Faster, Safer, Better

Choosing the Optimal Rendering Approach for Your Frontend

Introduction

In the modern frontend, we have several approaches for rendering web pages, including server-side rendering (SSR), static site generation (SSG), and incremental static regeneration (ISR). Each of these approaches has its own advantages and disadvantages, and choosing the right one depends on several factors, such as load time and user experience.

Server side rendering

Server-side rendering (SSR) is the process of rendering web pages on the server and sending them to the client as fully-formed HTML documents. This approach allows search engines to easily crawl and index the site, and can also improve the initial load time of the site for users with slower internet connections. It can also improve the performance of single-page applications (SPAs) by allowing the initial page to be loaded more quickly, which can improve the user experience.

Static site generation

Static site generation (SSG), also known as prerendering, is the process of generating a website's HTML, CSS, and JavaScript files ahead of time (build time), rather than in response to user requests. This can improve the performance of a website by reducing the server load, as well as improving the user experience by providing faster load times. It also increases safety a great deal, as it is very difficult, for instance, to DDOS a static fileserver.

Incremental static regeneration

Incremental static regeneration (ISR) is a hybrid approach to server-side rendering that combines the benefits of both server-side rendering and static site generation. It allows for dynamic content to be generated at build time and then revalidated and updated automatically as needed at run time. This can provide the benefits of static site generation while still allowing for frequently changing content, such as user comments or social media feeds.

What to choose

What these methods have in common is that they try to improve the user experience by minimizing the load time for the user. However, choosing, for instance, server-side rendering leads to the load time being before the user enters the site, which means here we are just moving the problem. This approach is one I would only recommend when no other option is possible. I know that much can be solved with caching; but, if you are relying heavily on browser caching with long cache times, you would still be better off generating ahead of time so that the first load time is decreased.

My belief is that today the real decision is between static site generation and incremental static regeneration, which is really a question of whether you want increased performance on build time or run time. This, of course, is no trivial question either. Build time allows for more safety, generally speaking. Looking at scalability and reliability, static site generation is the preferred option.

Both options give us a frontend that is built ahead of time, before the user visits. This means a fast page load for the user. The key difference between the two is how to handle content updates to the frontend. Many people against SSG will tell you that you need to build all your pages for the entire frontend to change a comma. This isn’t true, as a content change on a single page will only result in that page getting re-uploaded. ISR, on the other hand, will show the stale content one more time, then rebuild the site so that the fresh content is shown to the new user.

With SSG, we can ensure immutable deployment—we know that the deployed frontend will not change, which offers a great deal of confidence in your frontend. The build didn’t break, so the content is good. You can’t do that with run time since it is, as the name suggests, done at run time and errors can occur for your users.

The elephant in the room is, of course, build times. SSG isn’t perfect; unfortunately, nothing in software is. However, it is one of the best tools we have today. Build times grow with the content; however, it is possible to get them down. Currently, we have a site with 10.000 pages that builds in under 3 minutes. We also had a project with 60.000 pages, generated in 19 minutes. Both of these are, in my opinion, reasonable times. Of course, if there is only one page change, the build time is less.

Conclusion

When deciding which approach to use for rendering your web pages, it's important to consider factors such as search engine optimization, load time, and user experience. While server-side rendering (SSR) can improve the initial load time for users with slower internet connections, it may not be the best option if you're relying heavily on browser caching with long cache times. Similarly, while incremental static regeneration (ISR) can provide the benefits of static site generation while still allowing for frequently changing content, it may not be the best choice if you prioritize reliability and scalability. Ultimately, the decision between static site generation and incremental static regeneration is a question of whether you want build time or run time, and both approaches come with their own advantages and disadvantages.

At Vembyte, we do whatever fits the project best. We value reliability, scalability, and performance at the top. Therefore, we opt for SSG when we can.