Incremental Static Regeneration: Static Sites on Steroids

Hello, everyone. My name is Facundo, and today we will talk about incremental static regeneration.

I want to introduce myself. As I said, my name is Facundo Giuliani, I'm from Buenos Aires, Argentina. I work as a developer relations engineer at Storyblock. I'm also an Auth0 ambassador, Prisma ambassador, and Cloudinary media developer expert. If you want to talk about any of these products or anything, you can write me. My website is fgiuliani.com, and I'm on Twitter as Facundo Zurdo.

First of all, I wanted to define what a static web page is. It's a web page that is delivered to the user's browser exactly as a store. So we can have a web page that is conformed by an HTML file, CSS file, and JavaScript file. And that will be considered a static page. That doesn't mean that the content of the page will be static, but we will be delivering the same files to all the users that visit our website. And that is the difference with a dynamic web page, where it's a web page where some of the content is generated dynamically when needed.

We have different ways of generating this dynamic content. One of these ways is using server side rendering, where the HTML content that is generated dynamically is done in the web server. So the web server will be the one that will generate the HTML content and will deliver to the user a web page that will look like a static page, but on the flight, it was the HTML content or part of the HTML content was generated. On the other hand, the client side rendering is when the HTML content is rendered directly in the browser using JavaScript. This will be like the common use case for React where the HTML content that we generate or the markup that we generate is based on the components that we have in our application. And what any other single page application that we can create using React or other JavaScript frameworks.

But let's go back to the static web page, because if we analyze them we can see that we have different benefits that the static web pages offer. For instance the static web pages are fast because we are just delivering files that are stored in a web server as they are stored, so we don't have to do any logic to generate the content that we want to deliver. They are cheap because we are just storing files like any other file system. They are easier to maintain because these files that we create I don't know probably write in the content in a text editor or something like that uh using the method that we want. We can move one file from one place to the other we can deploy new versions of our website like just moving the new files to the web server and etc. They are secure because we are not executing any code in each request that we receive so we don't have to worry about the security of any code that is executed because there is no code being executed. It's easier to scale because we can add storage space to our web server and that will be enough to get more files and create more pages for our website. And it's stable because as we are not doing any calculation or processing on every request we are just delivering files and that will be more stable for our website. So having these benefits in mind from the static web pages that were created, I don't know, at the beginning of the 90s for instance, with the latest frameworks and tools that were developed in the latest years a new concept appeared.

So having these benefits in mind from the static web pages that were created, I don't know, at the beginning of the 90s for instance, with the latest frameworks and tools that were developed in the latest years a new concept appeared. The concept of static site generation which is compiling and rendering a web application at build time, generating static assets like HTML, JavaScript and CSS files.

So we will have different data sources, content, template engines, databases, APIs, third-party services and we can generate the logic that will create the HTML content for our website and we will use a static site generator to run a build process for our project and generate static assets that will be our website.

So these static assets that we will deploy to the web server later are generated when we run a build process with the static site generator and all the dynamic content that we generate using the different processing and data resources that we have will be analyzed and let's say rendered at build time. So we can be sure that when the users visit our website they will be seeing static assets, static pages and I mean that is using the benefits of the static sites but using frameworks and tools from the latest years.

There are several static site generators, today I will focus on Next.js which is a react framework that allows us to create user interfaces, static pages and server side rendered pages. So we can work at the page-based level, let's say I mean we can create javascript files for each page that we will have in our website or we can create dynamic routes that will generate different pages that follow a certain criteria or certain URL let's say and we can use per page level or differentiating each page, how we want to render the content for it.

So we can have static site generation for some of the pages in our website, let's say that we have for instance a blog, we can like use static site generator to generate the home of our blog and then one page per article or per blog post let's say as the content that we will expose in our blog post will be always the same and for all the visitors of our website, we can generate them ahead of time and in a build time, generate static pages and static assets that we will deploy to the web server and they will be available to be visit by our visitors. But we can also have I don't know dynamic pages in our platform or our website and we can use server side rendering in those cases or client-side rendering depending on what we need. I mean client-side rendering would be like the regular react but we can use server side rendering too so the server returns a page with a dynamic html content that was created on the fly but on the server. We can also have API routes in Next.js to execute code like the serverless functions do so they can return we can consume services or APIs using API routes and one of the other cool features that Next.js has is that we will have fast refresh on developed environment. So if we are using for instance static site generation that doesn't mean that whenever we apply a change on the content or the code of our website we will have to run the build process again. The code will be changed for instance and the changes will appear automatically on our browser while we are working locally. So we see that we can create static sites but using new tools and different data sources and template engines and etc everything at build time so again going back to the same example we can create a blog post sorry a blog site with a lot of blog post rendering all the content that we need ahead of time and deploying static assets but this have a problem because um when we start creating more and more articles and blog posts and etc and our website gets bigger and bigger the amount of time that we will need to generate all the static assets at build time will be bigger too.

So if we are working I don't know for instance in an e-commerce platform where we sell products and we start adding new products and changing the description of the products and I don't know changing the price of the products if we want to generate all the pages for all the products again and we have to run a build process the time will increase and will be super big and probably that doesn't help us or doesn't work for the scenario that we are trying to solve.

There's a concept used with the static site generators that is the atomic deployment, that means that when we run the build process we have to generate all the static assets for our website. If there is any error while executing this build process, or if there's any page that we are not generating, we say that we are breaking this atomic deployment because we will have different versions of the pages living in our website and that's something that we don't want. I mean, we want to have in sync all the pages and like we said that all the pages that we are exposing in our website are from one version let's say.

But, well, I mean the build time increasing is a problem so NetJS team analyzed that and created a new feature for the framework which is incremental static regeneration which enables the developers to use a static generation but on a per-page basis without having to rebuild the entire site. This feature works like this. We will execute this build process one time. We will generate all the static assets or all the static pages or probably a limit set of pages in a blog site would be probably the the latest five blog posts and the home page, let's say, and we will cache the version, this version one of the pages, and we will set the value for the revalidate property which is revalidate and we will set an amount of seconds that will happen between the first time that the users visit this version one of the page and when this revalidate time expired, what the the framework is going to do is for the next user that visit our website, we will display the cache version of the page but in the background a build process will be executed just for that page and we will generate the new version of that page that will be created the static page stored in the web server and cached so the next users that visit our website will be seeing this version two of the page. This is helpful because we will have faster builds because we will be generating less static assets at build time and we will have a higher cache because of this because in the meantime we will be generating new versions of the page and we will keep that cached.

This helps also to work with headless content management systems or different content systems that we can use to generate the content that we will display in our website because if a change is applied to the content of our website let's say the same example as the blog post if we have a typo or we are changing some content for a blog post the next time that the user visits that blog post or the page for that article we will use incremental site regeneration to generate a new version of the page and display that to all the other users that visit our website. And these pages will persist between deployments so if we want to deploy a new version of our file of our website because i don't know we did a lot of changes to the code or anything, the pages that were generated using study incremental study regeneration will persist there which is cool but also we have the problem that we are breaking the atomic deployment the concept that we mentioned before.

Let's see a quick demo of how this works. I have this website with a title and a grid of features let's say and i will use the three different methods to generate a page that we mentioned. Server-side rendering, static site generation and incremental static regeneration. So I'm running this page with server-side rendering. We will always generate on the flight the content so the content will be always up to date because we are running it for every request. If I use static site generation we will always see the same page because it was generated at build time. If we use incremental static regeneration we will see the page that was created at build time, the static page. But if we do a change we will see that change for the next visitors after we apply that because we will run this build process again just for this page. If we go to the code of my website, I won't stop on explaining the hierarchy of folders and files that Next.js creates for a project. We will have a folder called pages and inside of it we have the three URLs that I visited with the dynamic routes that I mentioned before. Depending on the slug which page we will display. We will have a main function that we will use to render the html content for our page using components here like react components. I have a layout and a page and we use the content that we bring from an API which is an API calling of a headless CMS that I'm using to maintain the content for my website. The headless content management system that I'm using is storyblock. We are using the storyblock client to get the information for a certain page or certain story and with the data that we are bringing from the API we are returning that as a property as a story to the main function that will render all the markup for our page. If you see here I'm like hardcoding the slug or the url for a page because this is the only page that I have in my site and this get server site props is a method that will be executed for every visitor that comes to our website. If we go to this example which is the static site generation the main function is exactly the same. We have a very similar function called get static props which executes the same and brings the information and returns that to the main function to generate the markup. But as we need to define which pages are we going to render at build time we have this other function called get static paths with the logic to generate all the urls or all the pages that we want to render at build time.

As we have only one page in our website which is the slack home, we are returning a json object with the property paths and only that item that will be used in get static props to get those params and use the slack that we are sending to generate the markup for that page. If we have more than one path we will have a list of paths here that we are returning and we are rendering the content for each one of those paths.

On the example of incremental static regeneration the code is very similar to the one that we just saw, I mean the main function. We have get static props too because we are generating the pages at build time and get static paths because we want to generate this homepage at build time too. But we are changing this fallback to blocking because we want to generate the markup for the page in the background if we set a revalidate value, which is here and which is 10 seconds. This means that if a user visits our website after 10 seconds from the first time that we display the page in the background we will run a build process for this page to generate the new markup. And that is the example that i want to show here. We will apply the change to the content and see how it works for each type of rendering.

This is the real-time visual editor that we have for storyblock which is connected to my local host. So what i would do is go here and apply a change. We can apply this change here, the feature one will be called now feature test, and i will save the change here. You can see that i can see the changes even if i don't save or apply the changes to the information. That is one feature of the real-time visual editor of storyblock. But now let's go to our real site. Let's say so i will see what's happening with server-side rendering which is after loading the page we see the feature test which is correct because for every visitor we are generating the dynamic content on the fly and we are displaying the updated content for each visitor. But if i go to static site generation what i will see is the previous version because we created this page at build time and we didn't execute any build process again. So we are displaying the static page that we generate at first and we can see the updated content.

Lastly if we see the incremental static regeneration example what we will see is again the static page that we generate at build time but in the background we should be executing this build process to generate a new version of the page for the next visitors that will come to our website. So if I refresh the page what I will see is the updated content and we have this version two of the page for all the visitors that will come to our website and well we are using the feature incremental static regeneration here.

So if you want to learn more about this you can go to NetJS official website they have an e-commerce demo which is an e-commerce platform using incremental static regeneration to probably understand better how the concept works or probably see a more complex example or if you don't know NetJS or you want to learn more about it they have a very cool learning platform that you can visit also in their official website. So thank you very much I hope you enjoy this presentation and see you soon.