Modern web frameworks offer many options on how to deliver a site or app from server to client. You can generate HTML on either side, or pre-render it for high-speed distribution through a content delivery network.

Deciding how to structure a site or app relies on a few different factors. You need to be aware of how visitors will access your site or app. You should understand whether load speed matters more on initial load or subsequent navigation. Also consider how often you’ll update the site.

Bear all these factors in mind to weigh up the pros and cons of each rendering paradigm.

Rendering Websites in More Ways Than One

Rendering a website refers to the process by which a website is displayed in a web browser. There are lots of different ways to approach the process of converting raw data to formatted HTML on a user’s screen.

Each method has its pros and cons, and knowing the advantages and disadvantages of each can help you choose the right one for your site.

CSR: The Browser Takes Charge

CSR stands for Client Side Rendering. When you render an app or site client side, the server passes little to no HTML except a small piece of boilerplate code. The page then requests any data it needs from the server, after the page load event, via AJAX requests.

When an app or page renders client side, the server passes a script to the client that will generate the HTML on the client’s browser. This allows for single-page applications that don’t refresh the browser when you interact with them.

CSR apps are often quick to load on navigation, but they may be slow to load initially. The speed will depend largely on the framework you choose to do the rendering and how many extra libraries and add-ons you use. Most popular modern JavaScript frameworks include an option for CSR.

Fully client-side rendered pages and apps do suffer from the inability to navigate directly to a given page using a URL. When a client-side rendered app first starts, regardless of the URL entered, it will navigate to the same starting point.

SSR: Rendering on a Central Server

SSR stands for Server Side Rendering. This is a much more traditional form of webpage rendering in which sites generate HTML based on templates and send a blend of HTML, stylesheets, and scripts to the client. The majority of the most popular backend web frameworks fall into this category.

Server Side Rendered apps and sites tend to have quicker initial loads, but each successive navigation will require a full refresh. This means that not only will they take longer, but developers working with SSR will need to factor in session management.

The biggest upside to SSR-generated sites and apps is the consistency of path navigation. A user entering a given path will be taken directly to the requested page. Some frameworks manage user redirections from page to page within the app, but users may not be able to access the page they want initially.

Many modern frameworks offer blended solutions that start by serving a server-rendered page to the client. Once the page has loaded, an event known as hydration occurs in which client-side script events are attached to the page’s controls. From here on out, the client handles any navigation.

A blended dynamic offers the ability for users to go directly to any page in an app, while still receiving the speed and smoothness of a single-page application. Next.js offers multiple rendering paradigms, as do Nuxt.js and Sveltekit.

SSG: Minimised Rendering

SSG, or Static Site Generation, bypasses the need to generate HTML on the client or server side. Instead, SSG-style sites and apps pre-compile every page that they could need, and push the results to a CDN for rapid delivery.

This is an extremely effective method of serving web pages extremely rapidly. The results are normally compiled in simple bundles containing all the HTML and stylesheets needed for an individual page. These bundles are kept as compact as possible to ensure that the user will receive them as quickly as possible.

SSG sites tend to offer exceptionally quick load speeds, despite requiring a refresh for each navigation. The major downside to a static site, however, is a lack of flexibility. Highly dynamic systems such as social media apps or complex e-commerce platforms will require far more changes than an SSG can easily handle.

Many static sites will also require a greater amount of overhead to alter since each new change will need to be independently compiled. This makes SSG-style rendering a poor choice for sites that change rapidly, like a digital storefront with rapidly shifting inventory or social media apps.

ISR: A Bit of Everything

Easily the most complex type of rendering, but also the most beneficial, ISR stands for Incremental Static Regeneration. ISR blends the speed and scalability of statically generated sites with the reactivity of SSR and CSR-style apps.

When any page is requested in an ISR-style page or app the server will first check to see if there’s an unexpired cached version of the page. If there is, the server will immediately serve the cached page.

If a cached version of the page doesn’t exist, or enough time has passed since its generation, the server will generate a new version. This new version will be passed to the client and cached for future use.

This type of rendering is more complex to set up, but it automates away most of the issues that SSG sites normally experience. This allows apps to offer both the speed and reliability of a statically generated app while automating away the extra overhead.

Several modern frameworks already offer the option of ISR-style rendering. Many more have support for incremental generation in development. Most major frameworks will soon support ISR rendering if they don’t already.

Which Rendering Type Is the Best?

There are several ways to render a website or app. Each of these four types of rendering has multiple variations. No one type of rendering is ideal for all projects, and which type you choose will depend on what is most important in your site or app.

When choosing a rendering paradigm for your project, it is important to consider speed, how your audience will use your project, and how often the site will change. These will be the primary principles that will help you decide on the best way to structure your site or app.