Websites are incredibly complicated. You need to write code to tell a different program to display it in a certain way. You need to make sure any third-party code you use is from a valid developer, that they keep their code up-to-date with the latest security patches, and that they don't break your existing code when they make an update.
Websites can have thousands of dependencies. Those dependencies have dependencies.
You need to make a way to deploy your code to staging/production–a way to autoscale your servers so no matter the amount of traffic for your site, it is fast for everyone.
You may need databases, sessions, local caches, and a CDN. You have to write logic to clear that cache when needed, know when to expire a session, and figure out how to deal with a new version of your database that no longer supports your old syntax you wrote a few years ago. I can go on.
Let's talk about what happens technically when you visit a website.
First, there is a series of communications between your device and the server of the website which sorts out what IP address to visit and exchanges details about the SSL certificate.
Lets just say the website is a WordPress site. That page goes to the PHP scripting language and says give me the page.
The PHP page loads some dependencies, fires off a series of functions, connects to a database, receives the results, gives it back to the PHP which then decides what it wants to do with it.
All of this takes time. Milliseconds. Milliseconds sound small, but they add up. You may put a cache in place so that after the first time visiting, which was expensive computationally, future visits won't take as much time. This is great, but that first time was slow for someone, and now you just added a single point of failure and something that you need to update consistently. Now that you have to update, you have to worry it will break your code.
Static site generators solve so many of these issues. They do the computationally hard work once and generate static files. When your website serves those static files, other than the initial DNS and SSL details, everything from the paragraph above is not needed. You are saving your users time, every time.
There are seven very important reasons why you should use a static site generator.
If done right, your website is read-only. There is no database to connect to, no credentials to worry about securing, and no server side files or hidden files an attacker can try to exploit or find. Other than ensuring your markup and libraries are safe, there is nothing to update or manage. You have less attack surface now, so you can focus on preventing a smaller subset of vectors.
Not having to render a page and talk to a database saves many milliseconds. A static page does that time consuming dance once, at build time. Using a static generator like Hugo, it is incredibly fast.
Static generators can combine similar assets into one file, minify, and fingerprint. That improves speed and cacheability.
Because the files are static, you can host them just about anywhere. You can use a provider that handles scaling for you. The days of managing infrastructure are over. The days of being tied into a provider are over. You are agile enough that if that current provider is not meeting your needs, you can move off to another provider within hours, not days.
For low volume sites, most hosting companies will allow you to host the entire site for free. Most are pay-as-you-go services, so there are no long term contracts or worries about the cost of running too much or little infrastructure.
Going from a local development environment to a website is as easy as a push to a Git repository. You set up workflows that will deploy your code to your hosting provider and those are very simple to create. If you are using a CMS like NetlifyCMS, on save of a page or media, that is saved as a Git commit automatically for you, which then runs your workflow, pushing your changes live.
Because everything is committed via Git, it is very simple to get up-to-date with the latest content. Most static generators have built in web servers that a developer can use. No databases or virtual worlds to install and maintain.
Because the workflow is triggered by a Git push, adding another origin to a different Git provider can add redundancy in case of failure to your primary provider. You can set up a little deploy script that deploys to both Git providers at the same time so you always have code that is stored vendor independent.