Static Site or CMS?

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.

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.

You Probably Need a Static Site

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.

“Brochureware”

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

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:

  • If your site has a lot of non-technical contributors who need to be able to post using a Word-like what-you-see-is-what-you-get (WYSIWYG) editor experience. A static site generator would require getting a developer involved in getting content published, which could become a burden on your development team.
  • If your blog is extremely large. While some static site generator tools, like Hugo, have a very fast build process, but, with many static site generators, the build can be time-consuming for a large site).
  • If your site is updated very frequently. The build and deploy process can be tedious and time consuming if your site would require a rebuild and redeploy multiple times per day.

Documentation

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 Kendo UI documentation and NativeScript documentation are both built with Jekyll and hosted on GitHub.

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.

You Probably Need a CMS

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.

Large Enterprise Site

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:

  • A large number of pages;
  • Complex site structure;
  • Highly customized layout (where the content is tightly controlled within distinct portions of the page);
  • Complex workflow and user management;
  • Large-scale i18n (internationalization) and l10n (localization) requirements.

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.

Non-Technical Contributors

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.

Dynamic Features

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.

Making the Appropriate Choice

In the end, I’d start by thinking about these criteria:

  • Is the site going to be updated very frequently? (As in, multiple times daily)
  • Do I need complex dynamic features that cannot be easily migrated to a 3rd-party service or does my business prohibit the use of such a service?
  • Do I have a large number of non-technical content contributors or do I need complex user and workflow management?
  • Is my development team unable to be involved in the content workflow – testing and publishing?

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

Comments

  • Pingback: Dew Drop – September 29, 2015 (#2100) | Morning Dew()

  • Ed Charbeneau

    Great points. I’ve worked with a variety of clients and CMSes and there is a lot of confusion out there. The worst cases were when a client’s needs were assessed and provided a solution, yet they wanted WordPress because “a friend told them that’s the best website software”.

  • William Casarin

    They way we solved “non-technical contributions” is by adding a file watcher to the server. All they have to do is drop markdown files in filezilla and then the site rebuilds automatically. We had a “staging” folder as well so they could test their changes. Sure they had to learn Markdown but we found they caught on pretty quickly.

    • remotesynth

      That’s a good workflow. But I’d say you are fortunate that your content contributors are comfortable working in Markdown. It can be tricky for non-technical contributors because it only covers such a small subset of HTML. If you’re content requires more than that subset allows, you end up having to teach them HTML too. Plus every Markdown writing tool I’ve seen is live preview rather than WYSIWYG, which isn’t what content writers are generally comfortable with.

  • I must say, for me, I love Jekyll and Octopress for static CMS’s, even wrote one in good ‘ol JavaScript for my own purposes.
    Most of my freelance clients want WordPress because of ease of use, lol I end up training them and still have to update and create new content for them. Most people are not tech savvy enough or just don’t want to spend the time to learn how to do it, which is fine by me. I’ve even purchased themes that have a drag and drop GUI for the backend, thinking that even a non coder could easily create content of their own. Only a small percent of my clients take advantage or the interface.
    Squarespace seems to be a good fit for the lest tech savvy but it too, has it’s limitations, and I haven’t had the time to learn how to control the custom themes.

    • remotesynth

      Tony – I’ve had similar experiences in my past. That gets to my point that just because they can edit it themselves doesn’t mean they will. I think even WordPress can seem overwhelming to someone without a technical background – and they fear screwing something up. A situation like that is ideal for a static site generator in my opinion.

  • Your link to the Hugo website should probably be to gohugo.io, not gohugo.com.

    • remotesynth

      Thanks for the correction. Fixed.

  • “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.”


    
I don’t think this statement captures everything that’s going on in the static landscape.

    – While prose.io (the wysiwyg editor for Github) hasn’t been a great option, there’s still activity from the community.

    – There are several companies who have content edtiors, including two firms you mention: Netlify and CloudCannon, and there’s one in the works by a govt. entity.

    – Prismic.io, a sass-based CMS has created a static site generator, called Baked.

    – Both Prismic.io and Contently, another sass-based CMS have extensions that can be used with the excellent Metalsmith static site generator.

    – Tarbell is a static site generator designed to publish content from Google spreadsheets.

    – Almost not worth mentioning (as it’s stable but not actively developed), but there’s a minimalistic content editor for Middleman called “Middleman Blog Editor.”

    – Siteleaf is a hosted Jekyll-like static site generator with an easy to use control panel. It’s quite popular with designers.

    – Statamic, a flat-file CMS has the capability to output all its content in a static build folder.

    – Webhook, is a node-based static site generator CMS, with a great control panel and complete feature set, capable of creating complex sites. There’s a hosted and open source version.

    
Not to say the field is caught up with typical CMS, but there’s quite a bit happening, and I would hope the more that people explore these options, the more impetus there will be to make them more user-friendly.

    – Bud Parr
    http://www.thenewdynamic.org (my site devoted to static site generators and the post-cms paradigm)

    • Left one out. Roots.cx allows you to edit your content in WordPress and publish to static.

    • remotesynth

      Thanks Bud. These are excellent suggestions – some I never knew about. I try to indicate here (and especially in the report for O’Reilly) that there is a lot of innovation going on in this space. You are right, things are improving quickly and there are tools that are getting there.

      The services you mention (many of which appear to be commercial, which is fine, just mentioning) are beginning to offer a much better experience for the end user, even if many hide the “static site generator” part. I still maintain that the static site generators, not the services built upon them behind the scenes, are built for developers. If I use something like Prismic (their service not the generator), I don’t know, or care, what it’s running on. There’s a weird middle-ground there, which isn’t one I really discuss – I mean, even WordPress has a plugin to generate static files form WordPress posts and pages.

      One of the benefits, to me anyway, of something like what Netlify and CloudCannon are doing is that it is built around the generator rather than entirely hiding it. My developer(s) can build in Jekyll, for example, but then my end user can edit very easily (looks like maybe SiteLeaf works this way too).

      In some cases, specifically Netlify and SiteLeaf, I think the reliance on writing Markdown, while I love it personally, is a hindrance for non-developers. We seem to hate WYSIWYG editors because of the HTML they output, but the majority of the world just wants to write in something that feels like a word processor.

      • Agree with you, certainly – I only feared that rather strongly worded statement might turn some people away from considering static. Note that, I didn’t mention it, but Netlify is commercial, but the editor they’ve created is open source.

        And very much agree about preferring loosely coupled solutions (though at this point I take what I can get!).

        At any rate – enjoyed the book. If you’re in or close to NYC, come to one of our meetups.

        • remotesynth

          Thanks. Yeah, Netlify’s editor is open source (and finally public!) https://github.com/netlify/netlify-cms

          I’d love to come to a meetup. If you’re ever looking for a speaker, let me know. I have given a ton of sessions about static site generators.

    • I’ll just add another one to the list: DatoCMS (https://datocms.com).

      It’s a SaaS-based CMS too, it supports many static site generators and lets you deploy your site anywhere you want (S3, Netlify, Surge, you name it).

  • Hey @Brian Rinaldi: I would add surge.sh right next to your link for Netlify. An outstanding tool for deploying static implementations. And it’s absolutely free

    • remotesynth

      I do mention it in the O’Reilly report. It’s a great, free service. In this article, I am specifically referring to Netlify’s ability to run the build in the cloud for you. Surge will host the static assets and even simplify the deployment process, but (afaik) you still run the build process locally.