What the Heck Is Web Rendering, and Why Should You Care?

In the early days of web development, there were only static files, however, it has come a long way since then. Now we have databases, web sockets, real-time data, authentication, and much more powering our web apps.

Such advancements in web development have forced developers to explore different ways to render their web pages.

In layman’s terms, web rendering means turning code into websites that end users can interact with. Generating websites statically is not the only option these days, and depending on your project and data, it might not even be possible to pre-generate your sites.

Different sites require different rendering methods or a combination of these techniques. A site that needs to have static content (like a portfolio page or an about us page) can be pre-generated, whereas a site that needs dynamic content (like a real-time analytics app) cannot be pre-generated. So how should you render your sites?

In this blog, we’ll be taking a closer look at all the modern rendering methods developers have at their disposal, with examples of sites that can leverage them the most.

Various Rendering Techniques

There are 5 common rendering methods used in modern web development and they are as follows:

1. Client-Side Rendering (CSR)
2. Server-Side Rendering (SSR)
3. Static Site Generation (SSG)
4. Incremental Static Regeneration (ISR)
5. Deferred Site Generation (DSG)

These are offered by all the top frameworks such as Next.js, Gatsby, Svelte, and Preact, which makes it all the more important to learn the differences between them.

All these rendering methods basically play with three aspects: where the site is rendered, how many sites are generated, and how frequently we need to re-generate these sites.

Using these 3 pointers, we can easily break down these methods.

Client-Side Rendering (CSR)

CSR is a relatively new approach & React uses this approach out of the box. With CSR, the website is rendered on the client side, which is your user’s browser window. It renders the content in the browser using JavaScript, instead of getting a pre-generated HTML populated with data. This makes it an ideal choice for data-heavy pages where each user is served a different site. 

Pages using CSR are high in performance because they generate on-demand HTML on the same page & when you navigate between pages, it doesn’t refresh the page. Instead, it pretends to load a separate page & data, so server requests are drastically reduced. 

However, due to this, it struggles with search engine optimization (SEO), as the web crawlers of search engines like Google are accustomed to server-side rendered HTML.

Server-Side Rendering (SSR)

Many of the challenges of CSR can be resolved by the Server-Side Rendering (SSR) method.

As the name suggests, SSR pages are generated on the server and a populated HTML is served to your users, unlike CSR, which serves skeleton HTML and uses JavaScript on the client side to generate HTML.

There are some major advantages of using SSR such as better SEO, caching, and superior security. Since these pages are generated on the server, web crawlers can easily digest these sites for data and index them, hence better search rankings.  You can easily use environment variables and perform sensitive operations such as database queries to populate the HTML files with data on the server.

However, SSR is not perfect to a fault, as it demands more performance from your servers to generate HTML, and the number of server requests is way higher compared to CSR mode as every page is generated from scratch.

Now that we have a clear idea about CSR & SSR, we can quickly go over the remaining 3 methods.

Static Site Generation (SSG)

Some of the pain points of SSR such as higher server requests and slower page rendering can be easily managed with this method.

SSG refers to the old and trusted method of serving pre-generated pages to your users and has been around since the dawn of web development. These static sites are generated during the build time itself and are comparatively faster than other methods of rendering. Hence, these sites are incredible when used for pages such as landing, pricing, about, and portfolio pages, and work well with SEO.

The main difference between these sites and server-rendered sites is that there is no server code involved to serve SSG pages. You can even use bucket storage such as AWS’s S3 to serve these sites! 

However, having too many pages generated at the build time can increase the project size and also the build time.

Incremental Site Regeneration (ISR)

ISR is essentially an advanced version of SSG present in Next.js as it allows you to regenerate the static pages after a given time.

For example, if you have a page that uses a weather API to load the sunset and sunrise times of the previous day every day in California, you can use ISR to re-generate a static site with new data every morning and post generation, you can serve the same site to every user till the next morning when ISR will re-generate your site again.

ISR is incredibly useful for such use cases, however, it requires server code to regenerate the site.

Deferred Site Generation (DSG)

Like the method discussed above, DSG also builds on SSG. If you have a large site, say 1000 pages long, and you use SSG to generate these pages, it will significantly increase your bundle size and build time.

The team at Gatsby realized this problem and introduced DSG which allows developers to generate only the most important pages during build time and generate the rest on the server upon the first user request.

Therefore, using DSG in our above example, we can generate the 100 most crucial pages during build time and defer the generation of the remaining 900 or so.

It is worth noting that, unlike ISR, which uses a server-side API call, DSG uses a cached-at-build-time data layer to pull data. 

Which frameworks support all these methods?

Now that you are familiar with all the rendering techniques, the next step is to choose a framework that supports all of these methods.

It seems like the list of frameworks is ever-growing, but a handful stands out. Frameworks like Next.js, Django, Laravel, Rails, and Gatsby are some of the frameworks that have stood the test of time.

Two of the prominent frameworks in the JavaScript ecosystem are Next.js and Gatsby which are both based on React, making them compatible with the large collection of React components and libraries.

You can use all the rendering methods we discussed above in these two frameworks, however, it can be relatively complex to implement methods other than SSG in Gatsby because the framework is highly opinionated and configured to work best with SSG.

Next.js, on the other hand, allows you to work with each of the methods we discussed or even a combination of them on the same page without much configuration.

Recreating the same project on these two different frameworks can take time, especially when there is no major difference between the front end of the two but a day and night difference when it comes to the data fetching and rendering methods.

To quickly test your project with these frameworks, you can use the Locofy.ai plugin for Figma and Adobe XD to quickly convert your designs to high-quality, production-ready frontend code.