I talk and write a lot about static sites and static site generators. When I do, I typically cover the benefits they offer over a traditional content management system (CMS). The primary benefit, in my opinion, is less complexity in deployment, hosting, backups and security.
It may seem odd for someone who works for a company that makes a very popular CMS to appear to be disrespecting content management systems. And, truth be told, CMS can be easy targets.
Pronounce it with me: “CMS” === “See a mess"
— David Walsh (@davidwalshblog) August 20, 2015
However, that’s not my intent.
Complexity does not necessarily equate to “messiness.” In fact, just because something is more complex, does not mean that it is the wrong solution. Just because a solution is simple doesn’t mean that it is sufficient to solve your problem. As with any software designed to meet a broad set of needs, the complexity within a typical CMS versus a static site is there for a reason.
In this post, I want to discuss when you should consider using a static site and, alternatively, when you really need a CMS. Keep in mind that there are no hard and fast rules, but these guidelines will hopefully help.
Some cases are pretty straightforward. With some caveats, the types of sites described below are the ones that I would suggest you look at using a static site generator first – before exploring a CMS.
If you’re interested in learning more about what static site generators are and how to use them, check out my free report published by O’Reilly – Static Site Generators – Modern Tools for Static Website Development.
Let me start by saying, I don’t like the term brochureware. It’s intended to sound derogatory, even though it would accurately describe a large number of sites on the internet. I am using the term brochureware to refer to informational sites that are infrequently updated.
Many company sites, event sites and restaurant sites, to name just a few examples, would fall into this category. These sites sometimes include items like news and events that are updated occasionally, but the majority of information remains the same over extended periods of time.
Brochureware sites are perfect candidates for using a static site generator. The generator offers the ability to quickly build out the site using templates and even an easy way to add things like news or calendar items, but without the overhead of a dynamic site.
Many businesses are sold a CMS-type solution for these sites with the pitch that they can update them whenever they like, but, in my experience, can rarely translates into do. Having to work through a developer to get minor updates to the site added and deployed would not cause any major bottleneck in these cases, but they would greatly benefit from the simplicity and low cost of hosting.
Blogs are what most static site generators are designed for by default, and, thus, what they excel at. Plus, services have made it possible to add dynamic aspects that visitors have come to expect on a blog – for example, comments using Disqus.
WordPress is probably the common CMS solution for blogs. While it aims to be easier to set up and use than a full enterprise CMS, in my opinion, it can be overkill for a large number of blog sites. It still comes with some level of complexity in terms of deployment, hosting and backup, as it requires PHP and a database (typically MySQL).
WordPress also has a history of security issues and its enormous popularity makes it a common target. Plus, performance can suffer, especially under the weight of a large number of plugins – and it can be difficult to avoid leaving a trail of plugins on a WordPress site nowadays (it also seems that every plugin adds more scripts and weight to your page).
In most cases, a static site is a “no-brainer” for blogs. All that being said, there are conditions that might make a CMS a better option:
Documentation makes a particularly good use case for static sites for a number of reasons. First, users expect documentation to be fast and easy to access. Second, documentation doesn’t tend to change particularly frequently. Third, many companies now rely upon community contributions to fill the gaps or find issues in their documentation, and static files are easy to share via public repositories on sites like GitHub or Bitbucket.
The caveats to this are, first, that some documentation sites are rather large, meaning they can take time to build and deploy (however, tools like Netlify and CloudCannon can potentially streamline that process). Second, depending on the nature of what you are documenting, your community or even your documentation writers may not be comfortable with writing content in Markdown/HTML or submitting changes via pull requests.
If your site doesn’t fit into one of the above categories, that doesn’t mean going static is out of the question, but it may be a far less obvious (or easy to implement) solution. However, the types of sites I discuss below would be ones that I’d highly recommend evaluating a CMS as your first option.
Enterprise is one of those vaguely defined terms that gets overused in our industry, so let me define what I mean. In this case, this is a site with:
If your site has some combination of the above characteristics, you probably want to first consider a CMS. Much of the complexity of a typical CMS comes with trying to accommodate these specific feature sets – none of which are easy to solve.
You could probably bend a static site generator to meet any of these requirements, but it simply isn’t what the tools were designed to handle.
Let me be clear, as they currently exist, static site generators are tools designed by developers for developers. This includes the process of adding and publishing content.
Sure, a CMS will require a developer or developers to implement or update it, but typically content can be created, edited and published by non-technical content contributors without any direct developer intervention.
Furthermore, the writing tools are designed with Word-like WYSIWYG interfaces that content creators are comfortable with. The publishing process is generally straightforward and done via the site administration – and it may even take into account the company’s publishing workflow.
None of this is true for a static site generator. Content is written directly in Markdown or HTML and typically requires specific metadata (called “front matter”) to be included in YAML, JSON, TOML or other data formats. Previewing content requires a local install of the specific generator and the use of command-line tooling. Finally, publishing requires, at a minimum, the ability to build the site and FTP the pages or commit changes to a source control repository.
These sorts of requirements would not be suitable for most anyone without some level of development experience.
There are a myriad of services that can fill the gaps in a static site, making them more suitable for building a wide array of potential sites. There is Disqus for comments, Wufoo for forms and Google for search, just to name a few commonly used ones.
However, these either may not be able to meet the specific requirements of your application or your site may require so many third-party services to operate that it becomes inefficient to choose a static site. Larger enterprises may face other restrictions against allowing visitor data to be stored in external services as well.
For example, there are 3rd-party services that will manage user administration for visitor logins. However, the nature of a static site would make extensive customization of the content and/or layout based upon a user profile very difficult. Regardless of whether you are building brochureware, a blog or an enterprise site, if your requirements include a significant amount of user customization/personalization, then a static site might not be a viable solution.
In the end, I’d start by thinking about these criteria:
If the answer to any of the above is yes, my advice is to start out by looking at a CMS (like Sitefinity) first. Otherwise, go static.
If you are looking to learn how to build a static site, a good place to start would be my earlier article, Getting Started with Jekyll.
Header image courtesy of Helga Weber