Why I no longer use Static Site Generators

avatar
Simon MacDonald
May 10, 2022

static Photo by Zach Vessels on Unsplash

What are Static Site Generators?

Static Site Generators (SSG) are an excellent solution for building web applications where the content does not change frequently. However, as your website’s scope increases, either by additional content or dynamic functionality, issues begin to pop up. This blog post will detail why I no longer look to SSG as a solution for all but the most trivial web applications.

The benefits of SSG

no database

I mean, this all sounds great. Why wouldn’t I want to use SSG?

The downsides of SSG

While running a developer documentation website for a Fortune 500 company, I discovered some downsides.

Builds get slower over time

For small sites like a personal landing page or a marketing site, build times remain consistent as the total amount of content stays relatively the same. However, if you have a popular site where content is added, your builds will take longer and longer.

In our situation, we solved the slow build time problem by breaking the site up into several micro-sites. Each micro-site had it’s own independent build pipeline which eventually deployed to a shared bucket from which our site is hosted. This had the effect of keeping build times short at the disadvantage of significantly increasing the complexity of our build and deployment pipelines.

This type of incremental build is usually provided at an additional cost by SSG hosting companies. Hey, you’ve got to make money somehow.

Client-side rendering

Depending on which tool you use, you may partially or entirely negate the benefits of SSG by doing client-side rendering (CSR). Despite the fact you have already pre-rendered your assets at build time, by relying on client-side rendering, you will end up showing loading spinners to your users and reducing your overall SEO by not relying on semantic HTML.

Personalization

Did we say all the data was fetched at build time? It sure was, but what if you want to add dynamic personalization to your site based on the current user? You need to make an API call to a third-party service, but where does one put their API keys? You can’t store them in the static assets as that would be equivalent to inviting burglars inside your house.

They might look cute, but they’ll rack up a massive bill

cute raccoon Photo by Gary Bendig on Unsplash

A standard solution to this problem is proxying requests to third-party API’s via a serverless function. Your API keys are protected, but you are now maintaining a back end that you were trying to avoid in the first place.

What’s the alternative?

I recommend using Server-Side Rendering (SSR) techniques for all but the most trivial sites. For our use case, a developer documentation site, SSR solved our issues.

Build times became non-existent as no matter how much content we added to the site, we never needed to run a build. Instead, this build process was replaced by a single cloud function that converted markdown to HTML.

Client-side rendering went away as we sent semantic HTML directly down the wire. The documentation was immediately readable, and we could add dynamic functionality by progressively enhancing the site. Any third-party API’s calls happen on the server-side, so they remain secure.

What’s next?

Join us later this week when Taylor will detail our solution to SSR markdown files.