Static websites are one of the long-time staples of the world wide web. In the early days, this was often the best option for web professionals who needed to create engaging custom websites that were ultra-secure and loaded quickly. What makes these sites so secure and fast  is they have a very simple architecture — HTML files stored directly on the file system of a web server. In certain cases, static sites remain a great option. Over the years, static site generators (SSGs) have also made the process of creating static sites easier; however, these are still fundamentally developer-centric tools that require a fair amount of code-knowledge and retain limitations that make scalability an issue. 

Duda Sales Engineer Jason Hummel has a fair amount of experience working with static site generators and recently sat for an interview to walk through their pros and cons, common use cases, and what makes SSGs different from Duda.

This interview has been edited for clarity and broken into sections for the tl;dr crowd.

Let’s dive in...

Static sites have a reputation for being very fast and secure. Why is that?

“Static sites are super simple and that’s what makes them quick to load and very secure. There isn’t a database associated with the site for a hacker to go poking around in and since site visitors only need to access the HTML files directly from the file system, their load times are usually very fast. However, a static site isn’t guaranteed to be fast. As the developer you need to be cognizant of keeping things snappy by not adding too many assets to the pages. Also, as sites get bigger, it will take the generator longer and longer to generate the HTML files, which can lead to a poor developer experience.”

So if speed, security and the freedom to basically code whatever you want are the main advantages of working with static sites and static site generators, are there any trade-offs digital agencies and web professionals should know about when considering whether or not to use them?

“Scalability is really the biggest issue with static site generators. For example, let’s say you’re using Jekyll and you have 100 clients. That means you’re essentially going to have to set up 100 static site generators. So let’s assume you’re really good at this and you want to make it easy for your client to engage in the process and do some basic site management. You’ve set something up so the client can use a form to send you their business information and some content. You’ve made it possible for a user to preview changes before publishing the site. You’ve integrated with Let’s Encrypt to generate SSL certificates. Let’s say you get all of that set up to create this great experience for you and the client. You have to do that 100 times because you have 100 clients.

Now, you can consolidate all of that somewhat, but you’re managing everything. Additionally, you’re going to be pretty limited in the types of sites you can create. Things like login pages or landing pages with an integration with a CRM or scheduling tool like vcita are going to be very hard to set up.”

Are there any other issues beyond setting up those individual site instances and handling the minutiae of updating HTML files by hand?

“I would say web professionals and digital agencies that work with static site generators need to be extra sure they’re keeping a close eye on the latest industry regulations. For example, let’s take something like accessibility. Web accessibility standards are actually mandated by law in some countries and if you’re working with a static site generator, you can’t outsource bringing those sites into compliance with a solution like AudioEye in Duda’s App Store. You’re on the hook for making those changes yourself.”

Given that they’re not particularly scalable, what are the use cases in which it makes sense for a digital agency or web professional to work with a static site generator? 

“When I was at an agency, we had a client that made network security software. They wanted a static site because they were concerned about the possibility of being hacked and what that would look like to customers if it happened. But they also had a whole content team that was regularly writing blog posts and making updates to the site and needed to find a way to make this work. We ended up implementing a system that would allow them to update the site using a simplified CMS instead of hand coding or writing in Markdown. But even after all of our optimizations and improvements, I’d say we only got them about 80% of the way to where they wanted to be. 

However, if you’re in a position where security is so incredibly important, static site generators might be the way to go."