Rendering Techniques: SSG, ISR, SSR & Beyond
Static Site Generators such as Jekyll, Hugo, 11ty, Astro, and Next.js have become the go-to choice for setting up a blog or personal site nowadays, partly due to their performance and client-side transition speed.
If you’re unsure about what SSGs are and their place among other rendering techniques in web development, stay with me for a few minutes, and we’ll gain a deeper understanding of their significance together.
Well, before diving into SSGs, let’s take a look at what rendering even means!
What is Rendering
Rendering is a process of generating or creating the user interface from the code we write. React 18 & Next.js 13 introduced different strategies to render an application.
Surprisingly we can use multiple rendering strategies within the same application to render it differently for example in Next.js 18.
Client Vs Server Side Rendering
There are basicaly two environments where we render our application code; client & cerver. The client stands for the user’s browser & the server for the computer where the app is deployed.
Based on these environments we have two types of rendering; Client Side Rendering (CSR) & Server Side Rendering (SSR). Both of these strategies come with their advantages & downsides.
Client Side Rendering
In Client Side Rendering the rendering process occurs on the user’s browser therefore provides a dynamic & interactive user experience. The transition between pages is smoother & the fetching occurs in real-time.
There is reduced server load & potentially lowering hosting costs as the client’s browser is responsible for handling the rendering. However, the compatibility & performance depend on the user’s device configuration.
Client Side Rendering is not ideal for SEO ranking & social media sharing previews so it is suitable for B2B websites. As an example React.js uses this type of rendering.
Server Side Rendering
In Server Side Rendering the rendering process occurs on the server before sending the page to the client’s browser. It provides a fully rendered HTML page to the client resulting in fast initial page load time because of which it is ideal for search engine rankings & social media sharing previews.
Server Side Rendering performs well on any slower device as rendering is done on the server which also reduces the risk of compatibility issues. It also reduces the amount of client-side JavaScript code sent to user’s browser thus enhancing security.
Static Site Generation
In Static Site Generation the content is generated and converted into HTML, CSS, and JavaScript files during the build process i.e while compiling the code. It doesn’t require server interaction during runtime i.e when the user is interacting with the website.
The generated static files can be hosted on content delivery network (CDN) and then served to the client as-is. The result, the rendered content, is cached and reused on subsequent requests leading to fast content delivery and less server load. This minimal processing results in higher performance.
The example of this is my own blog - the one you are reading right now which is based on Hugo - a Go based, open source, blazing fast static site generator.
Although SSG handles dynamic data during the build process, it requires a rebuild if you update anything, as it happens during the build time. To address this there is Incremental Static Generation (ISG).
Incremental Static Generation
Incremental Static Generation allows us to update these static pages after we build them without needing to rebuild the entire site. The on-demand generation of ISR allows us to generate a specific page on-demand or in response to a user’s request.
Meaning, a certain part of the websites or pages will be rendered at build time while other is generated only when needed, i.e., at run time.
This reduces the build time and improves the overall performance of the website by updating only requested pages for regeneration. With this hybrid strategy, we now have the flexibility to manage content updates. We can cache the static content as well as revalidate them if needed.
Why SSR is still needed?
Given the availability of Static Site Generation (SSG) and Incremental Static Generation (ISG), one might wonder why Server Side Rendering (SSR) is still needed. Both approaches offer valuable benefits, but their suitability depends on specific use cases.
SSR excels in situations where a website heavily relies on client-side interactivity and requires real-time updates. It is particularly well-suited for authentication, real-time collaborative applications such as chat platforms, editing tools, and video streaming services.
SSR involves heavy server-side processing, where the server executes code for every individual request, generates the necessary HTML, and delivers the response along with the required JavaScript code for client-side interactivity.
Due to this dynamic nature, caching content responses becomes challenging, resulting in increased server load when compared to SSG or ISG. However, the benefits of real-time interactivity and up-to-date content make SSR a valuable choice for specific application requirements.
This is Day 3 of #100DaysToOffload
That is all for today. If you found this post useful consider sharing it with friends.
