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
Rendering is the process that turns the code you write an application in into something that users can interact with on a web page. Declarative code, even plain HTML files, cannot just be plopped into the browser and work properly. When a user requests a website it needs to be parsed into something usable by the JavaScript engine inside the browser before anything is rendered on the screen. The code has to be transformed before it can even start the process of the Critical Rendering Path (CRP). These are the steps the browser takes to convert your code into actual pixels on the screen including the Document Object Model (DOM), CSS Object Model (CSSOM), the render tree, and layout.
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)
Client Side Rendering or CSR lets the browser do as much of the work as possible to render the page. The "client" is the current browser being used to view the site. Initially a request is sent to the server and a single HTML file with any JavaScript that is needed to load the rest of the site is returned. If your site contains JavaScript, then it will be ran completely inside the browser from that point on. Even plain HTML and JavaScript sites without a framework will be rendered on the client (CSR). Sites that use CSR commonly have a loading spinner or some indication that you are waiting on content to load. By delaying the initial load, once the site is on the screen everything is fully interactive and functional. In most cases, this requires extra JavaScript to be ran and can be hard to keep performant at scale.
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.
Rendering Techniques
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
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.
Wrapping up
There are many choices when it comes to getting a page to a user and each comes with its own implications. It comes down to choosing the tool that is right for the job, but don’t be stuck in decision paralysis. One way to test if you need SSR or CSR is to disable JavaScript and load the web page. If your page is still functional, it can likely be prerendered. Using the Jamstack architecture allows you to start small and add in complexity where it is needed. Prerendering as much content as possible and using less JavaScript is better for everyone. Increased performance, portability, and maintainability are just a few of the reasons why to use the Jamstack.
Latest comments (0)