Guides & Tutorials
The Acronyms of Rendering on the Web
Many frontend frameworks now offer the ability to choose how you want to deliver your website to users. Each will give the user a different experience depending on the way it is rendered. First, let’s break it down. What is rendering?
What is rendering
Types of rendering
When a user navigates to a website, a request is sent off to a server and data is returned before the CRP begins. How that data gets returned is the type of rendering that occurs. There are three different types. These include Client Side Rendering (CSR), Server Side Rendering (SSR), and Static Rendering or Static Site Generation (SSG). Each will change the user experience of the website and how the performance or perceived performance is optimized. Many frontend frameworks give you the option to choose how to render different pages on your site.
Client Side Rendering (CSR)
Server Side Rendering (SSR)
Server side rendering, SSR, is what the web of old was built on. Trends went far in the opposite direction with CSR with single page applications (SPAs) and popular libraries like React. Now SSR is starting to fall back into style. This puts most of the work back on the server. When the browser requests a page, the server builds the page, compile all the data, and return the entire HTML page back. Data is dynamically grabbed from the server every time a user visits the page. This causes the server to do the work all over again. Internet speed, server location, and too many users at once can impact the performance of these sites.
SSR has become the new trend because Content Delivery Networks (CDNs) like Netlify, provide servers across the globe that distribute the content closer to the end user. That request to response trip is shorter in most cases than the traditional single server location. This is also where the term serverless comes in. You are able to build and deploy your applications without having to maintain the actual server infrastructure. SSR uses serverless functions under the hood on the Jamstack. On Netlify, serverless functions default to use a single server location. Static pages are still served from the CDN and SSR can be ran on the CDN with Edge Functions.
Static Rendering / Static Site Generation (SSG)
Static rendering is when all of the data a page needs is generated when the site is built. Prerendering all of the content in your site emerged with frameworks like Jekyll and Gatsby. These sites do all of their data collection at build time and is cached at that moment in time. Any new data that changes on the site requires a rebuild of the entire application. This built the foundation for the original concept of the Jamstack architecture, a web development workflow that focuses on prerendering as much content as possible. Additionally making them dynamic through application programming interfaces (APIs) and serverless functions. Having to rebuild the entire site for any change led to long build times and new solutions emerged to lessen these.
As sites started going in the direction of more prerendered content and build times started creeping up, new techniques were developed to help combat them. These focused on increasing the speed and the functionality of sites built on the Jamstack.
Distributed Persistent Rendering (DPR)
Distributed Persistent Rendering (DPR) allows developers to defer the rendering of a route or asset until the first time a user visits the page and is then cached on the CDN. This sacrifices the load time somewhat for a single user to lower the build speed and have the newest content available. With this technique the most visited pages can be prerendered at build time and less popular pages can be built on-demand. When the page is built on demand, the cached page is immediately invalidated. That means if there is ever a need to rollback to a previous build, users would never see stale content.
Incremental Static Regeneration (ISR)
Another technique that came from Next.js, a React framework, is Incremental Static Regeneration (ISR). Rather than deferring the rendering of the page, it is rendered at build time and cached. When a user requests the page, the cached page is shown for a time while a new build of the page is triggered in the background. The cached page is not invalidated until the new page is generated.
Edge rendering is a new term that is popping up everywhere. Most of this comes down to serving things at the CDN level, the “edge”. This piece comes in when a page has already been rendered and needs to be updated with personalization or locale data giving atomic updates to your application. There are a handful of vendors offering this in some form, but each has their own flavor. Netlify uses Deno, a runtime based on modern web standards, rather than Node.js for their implementation.