Why I no longer use Static Site Generators

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

• SSG sites can be fast as the HTML has already been generated during build time, so your site should be immediately usable.
• Since all the data has been fetched at build time, there shouldn’t be a need to make additional API calls back to the server until you need to add dynamic capabilities.
• Search engines love HTML, and it’s great for SEO.
• Since you are not running a server, SSG sites tend to be very secure as they have a smaller attack surface.

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

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.