7 Reasons to Use a Static Site Generator
What is a static site?
When the site grows in size and complexity, challenges arise. Consider navigation: it may be consistent with all files, but adding a new page necessitates changes to all others. As folder structures change, even references to CSS and images can become awkward. You may have considered server-side includes or PHP, but a content management system (CMS) is a more straightforward alternative.
What is a Content Management System?
Usually, a CMS includes administrative control panels. These allow authors to create content that is stored in a database on the back end. When a visitor types a URL into the CMS, the CMS:
identifies which page is required
requests content from the database that is relevant to the situation
an HTML template is loaded (normally from the file system)
renders the template's content, as well as
The visitor's browser will receive a formatted HTML file.
This happens almost immediately. The template can include code that generates menus based on the hierarchy of navigation. The PHP/MySQL-powered, open-source WordPress CMS is used by more than four out of ten people to manage their websites.
Unfortunately, using a CMS introduces a new set of issues: you must follow the CMS's workflow. Adding custom text or components can be a pain. Since the server is working harder, performance will suffer. There are additional failure points. Your website could be brought down by a software update or a database malfunction.
What is a Static Site Generator?
An SSG is a hybrid of a hand-coded static site and a complete CMS that retains the advantages of both. In essence, you use CMS-like concepts like templates to create a static HTML page-based website. A database, Markdown files, an API, or any other functional storage location may be used to extract information.
When updates are pushed to the code repository, the site can be built on your development machine, staging server, or using a service. The HTML files and other properties that result are then uploaded to a live web server.
The word "static" does not imply "unchangeable." An SSG creates a page only once, while a CMS creates a page for each request. Users would never notice the difference since the result is similar.
A "Headless" or "Decoupled" CMS is a similar term. These use a content management interface like WordPress to manage content but allow other systems to access the data through a REST API or GraphQL API. As a result, a static website can be built using WordPress page content extracted from an internal server by an SSG like Eleventy. The resulting HTML files can be submitted to a web server, but the WordPress installation should never be made freely available to the public.
Jekyll, Eleventy, Gatsby, Hugo, and Metalsmith are all common static site generators. SSGs are available in a variety of languages (see StaticGen for many more). Where possible, frameworks like Next.js make pages statically, but they also allow the developer to run server-side code when necessary.
Let's look at the advantages of using an SSG...
Since they're linked to a database with unique fields, CMSs usually limit your choices. You'll almost always need a plugin, a short code, or other custom feature to add a Twitter widget to some websites.
The widget can be directly inserted into a file or through a partial/snippet in a static site. Since the constraints set by a CMS do not bind you, there are few restrictions.
2: Better Performance
To ensure that pages are created and reused as much as possible, most CMS applications have built-in or plugin-powered caching systems. Although the overhead of managing, validating, and regenerating cached pages remains, this method is efficient.
Static sites will generate pre-cached pages that never need to be refreshed. Files can also be minified before being deployed to ensure the smallest possible load and can be conveniently distributed across global content distribution networks (CDNs). A static site will often outperform a CMS-powered version based on the same design.
3: Fewer Server-side Dependencies
A standard WordPress installation necessitates the following:
- Ubuntu or CentOS are two examples of suitable operating systems.
- Apache or NGINX are examples of web servers.
- PHP and its plugins, as well as web server configurations
- MySQL is a database management system.
- the WordPress software
- any plugins that are needed
- the code for the theme/template
These dependencies need to be set up and maintained. While WordPress needs less effort than some other applications, a single update can still cause havoc. A static site generator may have the same number of dependencies, but it can run on a developer's computer rather than on a production server. Client-side HTML files and associated assets are generated by an SSG, which can be hosted on any web server. Nothing else needs to be installed, managed, or maintained.
4: Higher Reliability
A CMS is a complicated system with a lot of moving parts and failure points. If you run a WordPress site for long enough, you'll almost certainly get the dreaded "Failed to create a database link" error. Sudden traffic spikes can cause CMS problems by overloading the server, crashing the database, or restricting active connections.
Serving a static site requires less effort. In several instances, the server just needs to return flat files, making traffic demand scaling easy. It's still practicable to crash a web server or overburden APIs, but it'll take a lot of requests at the same time.
5: Extraordinary Security
Someone may choose to target your website for a variety of reasons. Unauthorized users can benefit financially and/or win kudos by using traffic hijacking, rogue ads, linking, authenticity spoofing, and malware hosting.
A CMS opens up a slew of attack opportunities. The login screen is the most obvious example: it's just as safe as the weakest user password. Be aware that any page with server-side code can be exploited, for example, by sending spam emails via your contact form. It may not be clear that anyone has gained access; the most heinous criminals prefer to remain anonymous.
Server-side features can be minimal or non-existent in a static site. Some dangers exist, but they are rarely as serious:
Someone may use SSH or FTP to gain access to a server and deface pages or upload data. However, checking for changes (perhaps with git status), wiping the site, and regenerating it is typically easy.
APIs named by a static site is visible in the browser and can be used in the same way as any other server-side code, such as a type emailer. CORS, CSP, and good security practices can all benefit.
6: Considerations for Client Control
You can spend weeks creating a beautiful CMS theme just for the client to trash it minutes after handover! Using a CMS isn't always easy, and it gives content editors a lot of control. You can restrict access to certain functions like plugin installation, but it won't stop anyone from altering fonts, inserting clashing colours, adding bad photography, or corrupting the layout.
A static site can be as simple or as complex as you want it to be. When you use Markdown or other flat files, editors are less likely to make mistakes or have a negative impact on page styling. Some people would skip the CMS content management tables, but you have two options:
Alternatively, they might use their current CMS and cleanse the data before generating the report, or Simpler workflows, such as editing Git-based files in StackEdit or Hackmd.io, are available.
7: Testing and Version Control
The data in a database is inherently unstable. A content management system (CMS) allows users to add, remove, or modify content on the fly. It just takes a few clicks to wipe the entire web. You can back up databases, but you're bound to lose some info even if you do that regularly. In general, a static site is better. Content can be saved in the following formats:
Flat files: using Git or similar frameworks, they can be version managed. Changes may be undone easily, and old material is preserved.
Private databases: Data is only needed when the site is created, so it does not need to be exposed on a public server.
Testing is also made simpler because the site can be created and previewed from any location, including a client's computer. You can use deployment systems to develop the site remotely and update the live server as new content is pushed to a repository, checked, and accepted with a little more effort.