Static websites

For anyone who is not yet familiar, static websites are websites that you can deploy, host and serve as prebundled and the website itself is a collection of static pages that are served as HTML with the site navigation map constructed at build time.

There are some elements that you can include that emulate dynamic content(e.g. content that would normally be fetched from a database), but that is still only updated after the site, or parts of it are rebuilt.

This approach has seen a proliferation of platforms that offer this as a service(Netlify, Vercel, Cloudflare etc.) and also a proliferation of frameworks with different strengths and weaknesses(list of frameworks supported cloudflare).

Why?

One might opt for a static website rather than a dynamic one is that content might not be changing very often and that makes the need for interacting with a backend application server on every request redundant.

That said you can update the content on a cron based approach, every minute, every twelve hours or a mix of on demand and cron, and have the content refresh.

Architecture and pitfalls

The idea when working on a static website is that 90% of the website content is created when the site is built. It is not necessarily static, but it changes at a much slower rate than say a real time application would. For example a Google maps style app for tracking your current route would not be a good candidate for a static website, a parcel tracking website could be static no problem, provided the updates are infrequent.

One nice aspect of static websites is that it makes it more secure, since the access to the core is gated, for the most part, and you can focus on the real dynamic component endpoints and tighten security on those, in effect decreasing the attack surface by quite a bit.

In the end it is a numbers game, infrequent could mean that you only update the site a few times each day. The reason why this is a numbers game is that if you set up your flow optimally the hosting costs can be extremely low if not free which can be a great perk if you are unsure about product market fit or general vision.

A standard flow in static websites is that data comes in from some third party data source that can trigger builds on change(think headless CMS with webhooks - e.g.Contentful). Each change in the CMS should trigger a rebuild of the website.

Most CI/CD platforms offer some kind of free tier for builds and most times the free tier is measured in minutes, so faster builds means more builds, fresher content.

There is another big caveat you should be aware of, that is, the number of inbound requests. In the past couple of years there have been some war stories where people have been billed absurd amounts of money because they were subject to DDoS attacks.

So I would advise to use some kind of DDoS protection on your site as the inbound traffic comes at a cost too.

Case studies

Case study 1: Netlify, Gatsby and build times

The first time I started building static websites is when I discovered Gatsby. I built several projects using Gatsby and hosted it on Netlify free tier. It felt like a really robust architecture and I loved that it was free.

I was working with React so using this model and using Gatsby made a lot of sense. I built all my React workshops as static websites, particularly since it has a free tier and Gatsby has many templates to choose from.

At one point though I realized there is a scaling problem with my build minutes. I knew that golang has considerably faster builds and in my case the easy fix is swapping over to Hugo.

Case study 2: Hugo

Moving over to hugo cut my build times to a third of the time. It was pretty amazing and given the number of builds I was running each month it made the free minute allowance suffice.

Hugo also has a nice template library and one of them was quite fitting for my use case. I think the people at AWSWorkshops are using it for doing their workshops.

Case study 3: Zola

Since then I got more and more into Rust, but I haven't found many static website builders with nearly as much traction as any of the others I have mentioned. I think it has to do with the size of the community. At one point I was doing a rust codehunt and I asked about it and was left under the impression that zola is somewhat deprecated. Of course I was unable to find many resources to either confirm or reject this, so if anyone out there has some insights I would be happy to reframe my thinking.

It comes with a list of templates too, some look quite nice.

One thing worth highlighting with zola is that rust build times are not as fast as Hugo. Go is optimized for very fast builds and it also has fewer compile time checks so it only makes sense that it is faster to build.

Case study 4: Astro

I started looking into other options recently and stumbled upon Astro. It's OSS and it has very good integration with Vercel, but can be deployed on any of the platforms for static hosting. (updated courtesy of Iain Simmons)

Astro is quite nice since it is very hybrid friendly allowing you to integrate any framework in your flow and with a base of Astro templating. It's an elegant way of approaching micro forntends with a static twist to it.

Not everything is easy or even possible in Astro, but you can use a mixture of Svelte, React, Angular and Vue in a single website, if you wanted to.

Astro also has a pretty extensive gallery of themes that you could use.

Conclusions

• building static websites is fun for me, I get to build cheap apps that have clear rules for optimization
• build performance is key
• you get a lower attack surface out of the box
• if you are going to build a blog, static might be a really good way to go
• beware of scaling with number of visitors