Advanced Site Rendering Patterns on the Jamstack

Rate this content

In this session, I'll go over these patterns (Sharding, ISR, DPR, DSG) and show our viewers and 2million+ other Jamstack developers how to leverage them to build large sites without the overhead on lengthy build times.

23 min
21 Oct, 2021

Video Summary and Transcription

Today's Talk discusses advanced site rendering patterns in the JAMstack, including the benefits and challenges of using this approach. It explores solutions like incremental builds, microsites, and incremental static regeneration to improve build times and performance. The Talk also introduces distributed persistent rendering and Gatsby v4 as new solutions to enhance static site generation and server-side rendering.

Available in Español

1. Introduction to JAMstack Rendering Patterns

Short description:

Hello. Today I'll be talking about advanced site rendering patterns in the JAMstack. You will learn how rendering works, the pros and cons of rendering patterns, and how to improve performance. Building the JAMstack way solves the problem of slow loading times by processing requests at build time. However, there are trade-offs to consider.

Hello. Thank you very much for the introduction. Of course, my name is Ekene Eze, and today I'll be talking about advanced site rendering patterns in the JAMstack. Well, I'll get to my introduction just in a minute. Yes, so I work as a developer experience engineer at Netlify and I have a YouTube channel where I make video tutorials about web development. If you want to follow me on socials, I'm on Twitter, at Ekene underscore IO. Let's jump into it.

Okay, we're not jumping into it quite yet because I'd like to also tell you that outside being a developer experience engineer and doing my thing on YouTube and learning JavaScript and doing work with it, what I really want to do is be a mixologist so that I can get all my friends drunk for no reason at all. That's probably a story for a different But eventually, I will get to tell the story. And I hope you all are here to hear it when that happens. But I will go on and get started for today.

So what you will learn today is how rendering works on the jumpstack. If you've been building jumpstack applications with Knox or with any other framework, in your static sites generator, you will better understand how rendering works. You will also understand the pros and cons of some of the rendering patterns we have, what they bring to the table and what trade offs they also bring. Finally, you will also learn what to do when your jumpstack site is performing poorly. For instance, if it's taking like too long to build, you'll understand why that is happening and the things you can do to help speed up that process. But before we dive into it, let's take a trip back memory lane to understand why this is even important in the first place.

All right. So before now, what happens is when a user comes to your site and requests for products. And in this case, I mean, what I mean is if a user comes to your website and they click on products, ideally what happens is a request goes off to your server and depending on your server architecture and how it's configured. This request could go through your load balancers, your web servers, your application servers, and databases and all of that thing that goes on behind the scenes to serve that request. So ideally, this goes out, your server processes the request, produces the right contents, and sends it back to the user. While all that is going on behind the scenes, of course your user will be seeing either a blank screen or a loading screen or a spinner, depending on how you build your site. So this is not very good for the developer and not also very good for the user who is using the application because they get to stay at a blank screen or a loading screen for a while before the actual contents get served. But building the JAMstack way kind of like helps us solve that problem, and it solves it this way, right? All of that processing happens before the site goes live. So for instance, if you've built your JAMstack application, once you run the build command, what happens is the static site generator goes off and makes all the requests on your behalf, right? And generates all the pages, generates all the dynamic routes and all the parts that will be available in your application. And then the content is now served to your users. So what happens now is instead of users coming to your site and clicking buttons to make requests, all of those requests happens at build time so that when your users come to the site, all the contents they need are readily available. So there's no lags, there's no waiting time, there's no loading spin-outs going on forever. So this is a good way, but as you can imagine, like every solution, like everywhere that technology comes with a solution, they also have some trade-offs.

2. Benefits of JAMstack

Short description:

The benefits of using the JAMstack way include faster site speed, improved user experience, better SEO, and enhanced security through CDN deployment. Developers can focus on their core skill sets without worrying about infrastructure.

But before we talk about the trade-offs, the benefits we get from using the JAMstack way is that your site is faster and your users are happy. I mean, right? If you don't ever have to wait on loading screens to fetch content, or if you're visiting a site and you're seeing that it's fast, if you click a button, everything happens as it should without any lags, your users will be happy. As a user, I would be happy, right? And then you also get better SEO out of the box as the developer or as the owner of the site, all your sites is being, all the content of your site is readily available. So Google and all the search engines will be happy. They can crawl and index your site properly because all the contents is available ahead of time. And also deploying on the CDN means you have limited point of attack. So it's more secure because you only have to worry about your site and the CDN. You don't have to worry about securing your databases, your load balancers, your web servers, and all of those things, you just have to care about your own application and then the CDN does the rest for you. Building this way also enables developers to stay within their core skill sets. I mean, I see myself as a front end developer. I like building with Vue.js and Nox.js. I don't ever want to have to worry about how load balancers or containers or Docker works, right? And building this way kind of like helps me just stay within my skill set and not worry about those things that I'm not comfortable with by default.

3. Challenges of Building with JAMstack

Short description:

Building websites using the JAMstack can lead to longer build times as all pages are generated at build time. For example, if you have a site with thousands of products, each product page needs to be generated before deployment. This can result in significant wait times, especially when updating the site. To address this issue, the Jamstack community has come up with solutions, starting with incremental build.

Anyway, that's that about building this way. If you feel like these people who are dancing here, that's exactly how I felt when we finished the JAMstack Explorer platform with my team, we built it all on the JAMstack, we did a lot of dynamic things, but at the end of the day, we had fun and we didn't really do so much of the things that makes us uncomfortable as developers.

All right, but like I said, every new solution introduces its own trade-offs. So there's a little bit of a trade-off here, which is that if you build this way, when your site gets large, as you can imagine since the build process kind of generates all those pages for you ahead of time, it means that if you have so many pages in your application, if you have 10,000, 100,000 pages, all of those pages are going to get generated at build time, which means you get to spend a little bit longer waiting for your sites to build as opposed to just deploying it as it is.

And to make that a little bit clearer, imagine that you have a site like this that has a thousand products. Once your build process kicks off, all of those products, all of those products are going to get generated. This is before your site is deployed before it goes live. So the build process takes like, let's watch this 100, 200, 300, 400. It goes all, all the way to 8,000 products gets generated, and then if you have more, if you have like 50,000, for instance, you're going to have to wait for all of that time to expire before your, before all your product pages are generated and deployed.

So take, for instance, that I have a site called my In that site, I have 1,500 product pages, blog pages, and press releases. Now, what happens is I have a total of 4,000 pages, right? So if I want to deploy this site, my build process is going to kick in and pregenerate all of these pages. And let's just say that hypothetically, this is not ideal in any way, but let's just say for the purposes of this presentation, that it takes our static site generator one second to build one page. Like I said, this is not the reality, but let's work with that. So assuming it takes one second to build one means it's going to take me 4,000 seconds to deploy the sites, to build the site before I deploy it. And that is like an hour plus, right? So imagine building your site, getting ready, finishing, putting out the finishing touches and just want to deploy your site and you have to sit there and wait for its build for one hour. That is not good. Nobody wants that. And that's not even all, right? Like if you want to update the site, you go through the same exact process. In this case, imagine that you want to add one more product page to your existing site, which you have built and deployed. What happens is your product is going to get one more product page, right? So instead of having 1,500, you have 1,501, which gives you 4,001 pages. And what happens is because it's a Jamstack site, the build process is going to start again. And when that happens, it's going to rebuild the entire site all over again. So that's another one hour plus that you have to wait for your site to build, just because you updated one product page. That is not ideal. I don't want that. I'm sure you don't as well, which brings us to the solutions. So while all this is going on, everyone in the community realized that this is a bottleneck that needed to be fixed. So that's one good thing about the Jamstack community, everyone rallies around to find solutions to problems like this that affects everyone. So the first solution is incremental build.

4. Incremental Builds and Trade-offs

Short description:

Incremental builds allow you to regenerate only the new page you added to your site, saving time during subsequent builds. However, it doesn't impact the initial build and breaks the atomic and immutable deploy concepts.

I think this originated from Gatsby some years ago when they were figuring out how to lower build times on the Jamstack. And just to make that very clear, what incremental builds does is, imagine that you have a site that has just seven product pages. When you deploy the site, it's going to be a live site. People can interact with it, but they can only see seven products, because that's what is available on your site. But what happens when you update that site and add another product page to make it eight pages? In this case, your entire site is going to get regenerated. And what that means is, as opposed to building just one page, it's going to build eight pages, because it's going to build even the one that has already been built before, because of course it has to regenerate the entire site. What incremental builds does is, give you an opportunity to build only the new page that you introduced to your site and leave the previous pages as they are. This kind of saves an incredible amount of time when it comes to subsequent builds of your site. In this case, you had seven pages built before, you added one more page, only that new page gets generated, everything else stays as it is. So while updating your site, you don't ever have to wait for all those long times to rebuild your entire site. But of course, it had its trade offs, it doesn't impact the initial build. For instance, if I had like 4000 pages like I had in I had in the other examples, when I deploy that site, I'm still going to wait for that one hour plus time, hypothetical time to wait for that site to build the first time so it doesn't get impacted. It only has an impact on subsequent builds and the site updates. And also it breaks the atomic and immutable deploy concepts, which is something that we are very particular about in the JAMstack. If you don't know what that is, I will put a link in the description in the output a link in the resources section so that you can look it up and see what that is all about.

5. Microsites and Incremental Static Regeneration

Short description:

The microsites pattern suggests splitting a big website into distinct sites for easier management. Each site can be built and updated independently without affecting the others. This can be achieved using proxies or redirects. However, there are trade-offs, such as complex redirects and proxies, and the need to manage multiple sites individually. Another solution is Incremental Static Regeneration (ISR), which allows you to choose which pages to build at build time.

Alright, and the next solution that came up in the community is microsites. This pattern literally says if you have a big chunk of sites that is together and has a lot of different pages, consider splitting them out into different micro sites so that it's easy to manage as independent variations of your site as opposed to one big bulk that has to build together. To visualize that, consider this globe on screen right now as a big website that has three different sections, has the product, the blog and the press what this pattern is suggesting is why not split this into three different distinct sites so that they are not all buckled up into one big site that has to build together and that are all together.

The advantage of doing things this way is all the parts of your site are independent of each other, which means if I'm building my product site, it doesn't affect my blog and it doesn't affect my press. If I'm updating a blog page, my product site will not rebuild. The press releases site will not rebuild because they are all individual and independent sites who are just like tied back together to my main sites using proxies and redirects.

And how that works is imagine that I have these three sites split out into different deployed into different websites. So I have a products website. I have a blog website, a press website that are all individual, standalone websites. And then I come to my, which is where I want to bring them all three together. I can use a redirect to point my, my slash products page, to point to that products website that I've built somewhere else. The same will happen for blog and press. And if you don't like redirects or you'd rather use proxies, that is also available to you depending on your preference and how you want to architect your site.

Ah, well, of course it do have some trade offs and some caveats. Uh, like I was saying before, it has complex redirect and proxies. So if you're not very familiar with redirects or how proxies work, this might not be very friendly for you because you really need to understand how to do that. Uh, to build a microsite, it doesn't impact initial builders. It's kind of like just how incremental build work, it doesn't have so much impact on the, on the initial build because if you're deploying your product sites, if you're deploying your blog, if you're deploying your press, it all deploys as independent sites. But if you still have like 5,000 product pages on site, it will still take all that time to build again. Although now smaller because it's one site as opposed to when it's building the three sites together. Of course you have several sites to manage. I mean, uh, in this case I just have three sites, products and blog and press, but imagine that you have like 15 different sites, sections of your site that you're building independently of each other. It means that you have it. It means that you have like so many sites that you have to manage in individually that could be tough sometimes. Uh, which then brings me to the last, uh, to the, uh, ISR solution. This is where things start getting interesting. I would say, right. Incremental static regeneration. That is always a mouthful. why? Uh, it enables you to choose, uh, what kind of pages, uh, how much pages you want to build at build time.

6. Incremental Static Regeneration and Caveats

Short description:

You can choose how many pages to generate at build time, serving the rest on user request. Pages not pregenerated are dynamically generated in the background while a fallback version is served. This approach impacts the initial build, allowing faster deployment. It combines static generation with SSRs. However, it has tradeoffs like serving stale content during revalidation and compromising atomic deploys. It's not framework agnostic and only available to future developers. The last solution is distributed persistent rendering.

Does that make sense? No, it enables you to choose how many pages you want to generate at build time as opposed to generating everything by default, right? It just says, okay, I have 10,000 pages, but I want to generate only a hundred of those pages when my site is building and I will do the rest when you use us request for them. And how it works is see, this is a typical JAMstack process, right? When you build your site, it generates all the assets and all the pages and all the dynamic routes and everything, right? But I say is, I will give you the opportunity to generate only some part of those pages. You don't have to do everything at a build time. You can generate only the ones that you want your users to see immediately, and then you can do the rest whenever people ask for them, which is cool, right?

Now, this is how it plays out. I know you're already asking, like what happens when a user asks for a page that wasn't pregenerated at build time, right? That's a good question. But what happens is first you need to understand that when your site is generated and deployed, all the contents of the sites gets pushed to the CDN that then serves your users, right? Now, when a page doesn't exist in the CDN and a user requests for them, like in this case, the page that I circled with the red circle thing, what happens is that particular page starts getting regenerated. Well, in this case, it starts getting generated the first time because it wasn't generated before. And while that is going on, ISR will serve a fallback version of that page to your users so that they don't see a loading screen or something like that. And while that's going on, the page is being generated in the background. And when the generation is done, the page gets put into the CDN that then serves your users the actual content. Cool. Cool.

It's... before I talk about the caveats, notice how it has a high impact on the initial build that we've been trying to solve for a while. So because you now have the opportunity to say, oh, I don't want to generate every part of my site at the same time when my site is building, I only want to generate 5% of it. Like, you can literally decide which pages you want to generate at build time. It impacts our initial build a whole lot because as opposed to waiting for 5,000 pages to build, you can build 100 or 500. And that will ensure that your site is deployed a lot faster than before. It also gives us the best of both worlds, right? You can statically generate all your pages, but when you just ask for content that wasn't generated at build time, you can use SSRs to generate those pages and serve them to the users. But of course, it has its tradeoffs as well. Because ISR uses stale while revalidates caching strategy, it means that you run the risk of serving stale contents to your users when the site is revalidating. I also put a link in the resources section if you want to understand stale while revalidates better, I will put it there to explain that very well for you. It also compromises atomic and limited pool deploys because of how it affects content going in and updating a site that has already been deployed without redeploying the sites to purge the cache and all of that. This is also not framework agnostic. I'm a front-end developer and I like building with Vue and Knox. But this is only available to next year's developers, which means it doesn't really help me in any way. Those are a few caveats. Let's see the last solution that I want to talk about today. And that is distributed persistent rendering that is currently in beta, but will probably be out of beta soon.

7. Distributed Persistent Rendering and Gatsby v4

Short description:

Distributed persistent rendering removes the need for revalidation and purges the cache completely with each new deploy. Critical content is generated during build time, while deferred content is generated on user request. Gatsby v4 introduces deferred static generation, allowing SSG and SSR without compromising core principles. Additional resources will be provided for further understanding.

And that is distributed persistent rendering that is currently in beta, but will probably be out of beta soon. What this does is it removes the need for revalidation and just purges the cache completely when there's a new deploy. So this way, all the content that you've generated is available to your users called critical content, the content that you've deferred will be generated when and only when a user requests for them.

And I think this uses serverless functions to generate those pages on demand and then put them in the cache. When you need to update the cache, you just run a new deploy and it will purge the cache. And this is intentional because this way you preserve atomic and immutable deploys and we are not compromising any of the Jamstack concept that we really care about.

And we've seen this come to life with the new Gatsby v4 release, something called deferred static generation, which is a new rendering mode that was introduced in Gatsby 4. And as you can see, it's out there in the world, people are using it. I think I'm particularly liking it. I'm currently building something with DSG and I'm seeing how we can completely do SSG and SSR on Jamstack sites without compromising any of the core principles that we really care about.

The resources section that I talked about, I'm going to add all the links to the things I talked about so that I will just provide you more resources to kind of like understand some of these things if you don't already know them or if you're not familiar with any of these things.

And thank you all for having me. It's been fun. I've had a good time sharing these things with everyone. Once again, I'm on Twitter and everywhere else on the web at kenny underscore io and that's my YouTube channel on screen if you want to check that out. Thank you all and see you next time.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Summit Remote Edition 2021React Summit Remote Edition 2021
43 min
RedwoodJS: The Full-Stack React App Framework of Your Dreams
Top Content
Tired of rebuilding your React-based web framework from scratch for every new project? You're in luck! RedwoodJS is a full-stack web application framework (think Rails but for JS/TS devs) based on React, Apollo GraphQL, and Prisma 2. We do the heavy integration work so you don't have to. We also beautifully integrate Jest and Storybook, and offer built-in solutions for declarative data fetching, authentication, pre-rendering, logging, a11y, and tons more. Deploy to Netlify, Vercel, or go oldschool on AWS or bare metal. In this talk you'll learn about the RedwoodJS architecture, see core features in action, and walk away with a sense of wonder and awe in your heart.
Vue.js London 2023Vue.js London 2023
28 min
A Saga of Web Rendering Woes
This talk will look at the evolution of web rendering modes and what the Jamstack movement is all about. We will build a demo project to show how a static site generator and a Headless CMS can be combined to create dynamic and engaging stories while maintaining a static site's performance and scalability benefits.You will learn about the advantages and limitations of each rendering mode and gain a deeper understanding of how to use Jamstack to build powerful and dynamic storytelling experiences.
React Advanced Conference 2021React Advanced Conference 2021
8 min
How do Localise and Personalize Content with and Next.js
Structuring your content with means you can query content based on signals from your visitors, such as their location. Personalisation is a tricky problem with static sites and the jamstack, this demo will show you how it can be done with, Next.js, and Vercel.
React Summit Remote Edition 2021React Summit Remote Edition 2021
9 min
Keeping It Simple
Netlify CEO and co-founder Matt Biilmann reflects on the history of React, the promises of the Jamstack, and the complexity that can creep into developer workflows if we don't continue to defend simplicity over time. In this lightning talk, Matt describes the trade-offs developers face to deliver large sites and introduces a new idea for a more scalable future solution.
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
API-first Development with Headless WordPress
When the burden of rendering is removed from WordPress, it becomes an open source API platform. With a few plugins like WPGraphQL, you can create an extensible backend for your React apps to consume which enables modern architectures and development practices in WordPress.
React Advanced Conference 2021React Advanced Conference 2021
22 min
Incremental Static Regeneration: Static Sites on Steroids
Static sites are great. They are fast, cheap, secure, and easy to maintain. But generating static assets is a process that takes more and more time while our site gets bigger. We will talk about ISR, a feature that Next.js framework offers us to generate static pages at runtime.

Workshops on related topic

React Day Berlin 2022React Day Berlin 2022
161 min
Crash Course into the Jamstack with Next.js & Storyblok
You might have read already about Jamstack. You probably already used Next.js, and recently you may be hearing a lot about the headless CMSs. This quick course will put all the pieces together and show you why Storyblok, combined with Next.js, is the best combo for your next project. Stop by and try it yourself!
- In-depth Jamstack knowledge. How it changed from old times to the modern world. Learn how Jamstack was created by comparing Static Sites and Dynamic Sites.- How Next.js serves content, and how content is served with Static Site Generation (SSG).- Atomic design methodology, and how this is applied to the content management system.- Hands-on project experience by building a Jamstack project with Next.js and Storyblok.
Prerequisites- Any Text . Visual Studio Code recommended- Node.js LTS- NPM or Yarn- GitHub account- Vercel account- Familiarity with JavaScript, React, and Git. Having worked with Next.js before is a plus
What's included1. Introduction and overview of the workshop2. Introduction to Jamstack3. Introduction to Atomic Design4. Overview of Headless CMS5. Introduction to Storyblok6. Next.js app creation7. Storyblok space creation8. Next.js and Storyblok connection9. Custom components creation10.First-page creation11. Introduction to Visual 12. Dynamic pages addition13. Blog section creation14. Deployment on Vercel
React Summit Remote Edition 2021React Summit Remote Edition 2021
120 min
E-commerce on the Jamstack with NextJS and Netlify
Jamstack frameworks are changing the way we build top-of-the-line experiences on the web. They are performant, secure and enable developers to build web apps faster than before. In this workshop, Nick DeJesus will walk you through what it's like to build an e-commerce site using NextJS, use-shopping-cart and theme-ui. You will learn how serverless functions with Netlify to help you make secure transactions and how to build accessible UI components that extend use-shopping-cart's abilities.
JSNation Live 2021JSNation Live 2021
199 min
Jamstack eCommerce 101
Digital commerce has changed, and there is an increasing demand for faster and kite efficient solutions. In this workshop, you'll learn about the evolution of ecommerce and how Jamstack and headless commerce evolves shopping experiences on the web. We will explore the basics of headless commerce building a minimal Jamstack ecommerce product page with static content, HTML5, CSS, and Javascript. Finally, we will integrate Commerce Layer for headless commerce capabilities and deploy our application to Netlify.