There are so many acronyms and initialisms in web development, it’s difficult to keep up. Does SSR affect my CWV? How many HTTP methods does it take to make a REST API? Does a SPA use CSR? Help, I need CPR!

Don’t worry, I’m here for you. Let’s break down the acronyms and initialisms of rendering on the web so you can get some much needed R&R.

What is rendering?

Rendering is the process of generating HTML markup to display web pages in the browser. How, and most importantly, where that rendering process happens can have a significant impact on user experience, site performance, and Search Engine Optimization (SEO).

Types of rendering

Let’s take a look at the different types of rendering available on the modern web today, and which types of sites, pages and data they are most suited to.

Static rendering

In the early days of the web, all websites were static sites — collections of hand-written HTML files stored on servers, most probably uploaded via FTP clients (oh, nostalgia!), and served directly to users in their web browsers. Static rendering is still a great option to use today, and is particularly suited to sites serving a single HTML file, such as a single landing page of content. There’s no server computation required — so your page will load fast. And a single HTML file is super easy to host on Netlify, either via connecting a Git repository, or uploading via Netlify Drop. 🫳🎤 Here’s one I made earlier.

Server-Side Rendering (SSR)

As the web evolved, the need for larger sites and more dynamic experiences emerged, and with this came the rise of Server-Side Rendering (SSR). SSR is a rendering method where web pages are built on a server at the time of the request.

1. Type a web address into a browser
2. Submit the request
3. That request travels to a server in a fixed location, where the server processes the request, builds the web page in real-time, and sends it back to the browser as an HTML document.

SSR is still the most prevalent rendering method on the web today, being the default for application frameworks such as Wordpress and large monolithic tech stacks. Historically, SSR required a persistently running managed server, which often comes with undesirable overheads in terms of maintenance, scaling and security. Fortunately, modern front end JavaScript frameworks such as Astro, Next.js, Remix, Nuxt and Gatsby now provide configuration options for using SSR via modern web development platforms such as Netlify, by using serverless functions under the hood.

SSR is best suited to serving pages that need to contain up-to-date, dynamic data, such as product stock levels or pricing if you’re building an e-commerce site, or personalized pages, such as if a user is logged in to an account on any site.

The drawback to SSR is potentially longer latency. Servers usually exist in fixed geographical locations. The further the original request is from the origin server, the longer the request will take to make the journey there and back to the browser. And if your site is being viewed on a smart phone over a 3G or 4G connection, the request may take even longer.

Client-Side Rendering (CSR)

Client-side Rendering (CSR) is the process of rendering content in the browser using JavaScript. When a request is a made for a web page that uses CSR, the server sends back a placeholder HTML document with a JavaScript file that will render the rest of the page and fill in the blanks in the browser.

CSR became increasingly popular with the mainstream adoption of JavaScript in the browser during the late 1990s. Its place as a core component in the web ecosystem was further solidified with the evolution of Single Page Application (SPA) frontend framework technologies such as React, Angular and Vue. Like SSR, CSR is best suited to dynamic up-to-date data, but it comes with some drawbacks.

With potentially megabytes of JavaScript to process on pages using CSR, your site may end up being slow to load and show data. Additionally, a combination of slow internet speeds, old devices, increasing web page complexity, buggy browser plugins or JavaScript simply not being available in the browser all point to using CSR sparingly.

What’s more, CSR isn’t ideal for SEO. Most search engines can only crawl the content returned from URL — not the result of what might happen in the browser. If you use CSR to render your entire website, search engines will only ever be able to read your placeholder content, rather than the rich content that is eventually loaded in by JavaScript.

Static Site Generation (SSG)

Static Site Generation (SSG) is the process of pre-generating HTML pages ahead of time, so that they’re ready to serve to your users instantly without the need for SSR or CSR. In the mid 2010s came the rise in popularity of static site generator tools such as Jekyll, which allowed developers to generate any number of static HTML files from templates during a build process. No more hand-crafting time-consuming single HTML files to get the benefits of static rendering anymore — yay!

And with this came the ability to serve your site from a Content Delivery Network (CDN), such as Netlify’s CDN, which serves your static files and assets from the closest server node location to the request — making your site really, really fast. What’s more, given your website pages are pre-generated as full HTML files containing actual content, you’ll score more SEO points.

There are hundreds of static site generators in the web ecosystem today, allowing you to build static sites using (most probably) any programming language your heart desires, including JavaScript, Go, Ruby, Python, PHP and Rust. Check out a huge list of static site generators on Jamstack.org.

SSG is a rendering method best suited to content sites and pages that don’t change often. Blogs, portfolios, documentation sites and informational content are all great use cases for SSG. To update content, trigger a rebuild of your site, and the newly pre-generated assets will be ready to serve from the CDN once the build process has completed.

Incremental Static Regeneration (ISR)

Incremental Static Regeneration (ISR) is Next.js’s proprietary implementation of a caching pattern called Stale While Revalidate (SWR). This allows for the regeneration of single statically rendered pages that have been modified, rather than rebuilding an entire site from scratch. With SWR, you can publish changes to a specific page — via a webhook trigger in a CMS, for example — without triggering a full site rebuild, resulting in faster site updates.

SWR allows for very quick updates to static content while retaining the benefits of SSG. When you use SWR to render a specific page, a version of that page will be statically generated and cached during an initial build. When that page is updated, a rebuild of that page is not triggered straight away, but the next time someone requests that page. The previous (stale) version of the page is served until the page has been revalidated and regenerated in the background, and the next request for that page will receive the updated version.

Bear in mind that with SWR/ISR, some of your website visitors may see outdated content as the updated page is rebuilt on the server and cached. You won’t want to use SWR for pages displaying data that should be accurate and up to date, such as pricing data. You’ll also want to generate a fallback page to serve if you’re using SWR/ISR to generate new pages, just to make sure your site doesn’t look broken or serve a 404.

Distributed Persistent Rendering (DPR)

Distributed Persistent Rendering (DPR) is a handy rendering method provided by Netlify to use on very large sites in order to dramatically reduce build times. Instead of pre-building your entire site in advance using SSG, you can choose to statically pre-generate only your most popular and/or critical pages, and enhance your rendering strategy with DPR.

DPR allows you to statically generate and cache pages on demand when they are requested for the first time. The first request to a page using DPR will result in an SSR-like experience, after which the generated pages will be served from the cache.

Netlify supports DPR and SWR through the use of On-demand Builders — serverless functions used to generate web content as needed that’s automatically cached on Netlify’s Edge CDN.

Edge Side Rendering (ESR)

Here’s where things get really exciting. Remember the CDN model we talked about, where static pages and assets are delivered to users from the closest geographical server location? Edge Side Rendering (ESR) harnesses the power of the CDN to deliver SSR as close to users as possible, providing the benefits that come with traditional SSR such as personalization and dynamic data, with improved speed for everyone around the world. ESR can be implemented for a full site, single pages, or even for just parts of pages.

ESR on Netlify is provided by Netlify Edge Functions — serverless functions executed at the edge — that can intercept an HTTP request and modify the HTTP response before it is sent to the browser. This means that you can use ESR to enhance your static sites and pages at the time of the request. When you pre-build as much as possible with SSG, and use Edge Functions to modify pages when you need, you retain the speed of static rendering with the power of making dynamic updates to your pages when you need to. ESR is an excellent candidate for personalization, localization, internationalization and more — providing a kind of super-powered SSR wherever your site visitors are around the world.

Wrapping up

That’s a lot of rendering options! And you most probably don’t want to use them all in a single project. Ultimately, the technologies you choose — such as hosting platform and frontend framework — will determine which rendering modes are available to you in your project. Understanding the pros and cons, and the fit of the different rendering approaches to your projects and the types of sites you build is a great way to help inform your choice of tools and technologies, rather than letting those choices dictate your approach.

Happy rendering! TTYL.