Does the new trend of Static site generation have an impact on API server resources? Let’s see!

What is Static Site Generation?

With Static Site Generation, a website dynamic content is generated via a build process.

The result of the build process is a static website: something like a 1996 pure HTML website, but often with very smart JavaScript tricks to preload content when it is likely to be needed, obtaining a perceived performance which is the best you can have.

All the calls to external resources that are needed to gather content and generate the pages (for example a CMS API) are made during the build process.

Then, the resulting static website may be hosted on a CDN, with no other call to the APIs.

In this way the website is:

• Super fast (static content + CDN + preload tricks)
• Very secure, as the attack surface of a static website is very limited
• Less demanding on API / DB server resources

If you like to see the differences between Server Side Rendering and Static Site Generation, see this post.

Note

Actually, the static website could need API calls at run time: if we think of an e-commerce, all the product pages may be statically generated, but the order management requires API calls to create an order. Anyway, these “POST” calls typically represent a small part of all the API calls to “GET” the content.

Impact on API and DB Server resources

As we saw, with static site generation, most of the API calls are at build time, so they are:

1. From just 1 client machine (the one where the build is launched)
2. Many at once for each build (all the API calls to build all the pages)
3. Interleaved by a (more or less) long idle time before the next build

As for the 2nd point, the API calls may be less if we can use an incremental build process, so that just the new / changed / needing frequent updates pages are generated.
For example Next.js recently created an RFC for incremental site generation.

As for the 3rd point, if we think that on a server we may host the APIs / DB of more than one website, the high-CPU / idle cycles may be balanced between the hosted websites.

The same, we have requests in burst and from few clients.

This will mean, on the API server:

• Less network usage
• Less DB usage (only for builds, not for every request)
• Less average CPU usage
• CPU/disk usage in bursts
• A higher write / read ratio on the disk (having much less read operations)

In general, the usage on the API server will be much less with SSG, especially with the adoption of incremental builds, which greatly flattens the usage bursts for websites with many pages.

Of course, this is true unless you have a website with 100K pages, just 2 visitors per day and you rebuild it all every minute… 😊

Advantages of a serverless architecture

I manage servers since 1997 (I still jealously guard the Windows NT 4.0 box) and we still manage our servers, so I am "old school", but with SSG, serverless services are great, because:

1. You need bursts usage, and with serverless architectures you just pay for what you use (so you don't pay during the idle time between builds)
2. Absolute performance is not required, as the build process is a batch process with no user perceiving the performance. So, even the cold startup time of a lambda function is not a problem here.

Impact on reliability and brand image

With a server side rendered website, if the API server goes down, the site goes down.

With a static generated website, if the API server goes down, we have no immediate impact.
The website is served on the edge by the CDN and works independently of the API server.

We still have an impact, because we cannot update the website content: the users don’t see errors, but stale content, until the API server is restored. The API server in a way becomes less critical.

Even if we have an e-commerce website, with API calls to manage orders, the impact of a failure is limited to the checkout phase, while the website is still visible. In this case, we surely have impact on the income, but less damage on the brand image of the website.

Conclusion

With Static Site Generation, in general, we need less resources on the API server than using server-side rendering.
What’s more, a server admin could sleep better at night, as the impact of the API / DB server failure is less severe and less immediate.

Let me know what you think about this post: I'd be super interested in receiving usage data stats that confirms (or prove wrong) my educated guesses. Thank you.

React Bricks

By the way, if you’d like to build a blazing fast static website using Gatsby or Next.js and keep the WYSIWYG editing that is missing in headless CMSs, you may try our hybrid block-based CMS React-Bricks! It’s now in beta! 🚀