The problem with static websites built with CMS content

The thing you rarely hear mentioned when talking about static websites built with data from a content management system is the poor experience of the people who are responsible for editing the website content.

There are two major problems that website editors face with respect to editing their website data:

  • Previewing how their changes look
  • Seeing their content go live as soon as they hit "publish"

Let's take a look at both situations in more detail.

Side note 📝

I mostly reference Gatsby in this post for the static site generator, but the same problems apply to other static site generators.

Previewing how changes look

When editing your website data in a CMS, it's often convenient to see how your changes will affect the page related to the content you're editing. WordPress has had this functionality baked-in for a while now and it's a feature that website editors expect to be made available.

However, when dealing with a static website, figuring out how to preview the content is complicated. This is because to get instant previews of your content, it is not feasible to build out the entire static page since it takes too much time.

To get instant previews to work, you need to have a mechanism in place that allows the page to be generated dynamically without having to build it from scratch.

If you want to use Gatsby cloud, it has a mechanism for providing previews of your content, but you may need to pay for the service depending on your usage. Here's an article that explains how this can be set up with Gatsby cloud and Sanity CMS.

Prismic CMS has figured out a way to allow you to do previews with Gatsby without using Gatsby cloud, which is useful if you want to avoid potential fees associated with Gatsby cloud.

There may be some other CMSs and tricks that you can do to get content previews working for your static site, but it isn't easy to do when you're website is not server-rendered.

Seeing content updated after publishing changes

Once you hit that "publish" button on a CMS, you can expect a delay between when you hit the "publish" button and when the content will show up as live on your production website. Depending on how long your static website build takes, that delay can be significant. The problem with having a delay when publishing content is that the website editors are always left questioning themselves about whether their published changes "worked" or not.

I've worked on websites in the past that were built with Gatsby and we've always had to tell the content editors that they should expect around a 30 minute way before seeing their content show up live. However, in some instances, the website build failed because some of the code improperly assumed the structure of the data provided by the CMS and that would mean that no matter how long you wait after publishing changes, you will not see the changes appear until the build has been fixed.

Are static websites even worth it?

Depending on what you value, static websites can be worth it. If you want the absolute best performance possible for a website, and don't think you can beat a static website.

However, in my opinion, server-side frameworks provide a better live preview experience with the ability to have content changes go live instantly. The difference in performance is likely negligible for a server-side framework, especially if you take advantage of some CDN caching.

Also, if you want to save on costs, I would avoid using hosted headless CMSs like Prismic, Contentful, GraphCMS, Sanity. Instead, you can reach for server-side rendered frameworks where the CMS lives on your own server. These frameworks include Keystone (JavaScript), Strapi (JavaScript), Statamic (PHP), and of course good old WordPress (PHP).

Robert Cooper's big ol' head

Hey, I'm Robert Cooper and I write articles related to web development. If you find these articles interesting, follow me on Twitter to get more bite-sized content related to web development.