For our most recent hackfest, I did some research on a topic that had been on my list for a year. I wanted to learn more about open source server-less content management systems. This had intrigued me for years (I saw a great presentation from Ara Howard at Boulder.rb where he talked about the benefits of static site generators for scalable websites.

Here at Culture Foundry we have clients with intense scaling needs. But some sites are 99% readonly. And with some careful use of technologies like AWS Lambda, I believe they could be 100% readonly. (Of course, that is for the public. Editors and administrators of the site would need read/write access.) For these kinds of sites, I think that a serverless CMS would have significant benefits.

Here was my list of wishes for/definition of a serverless CMS system:

• Open source.
• Outputs to pure HTML with support for javascript.
• Incremental output (so that if you change one page, not all pages are rebuilt).
• Capable of publishing to S3.
• If you change a core component (nav) all pages are rebuilt.
• A good editor experience
  • Upload images
  • WYSIWYG text box
  • Categories
  • Tags

Note that I didn’t care if the editor experience requires a server. I also didn’t evaluate commercial options, even though I know there are some good ones.

There are a number of options out there, but they all had subpar editor experiences (typically encouraging markdown use, rather than a WYSIWYG experience). Many were abandoned.

Here are some that I looked at (I found this post useful) and issues I had with them:

• https://netlifycms.com # markdown only
• https://github.com/tivac/crucible # has an issue with an out of date library
• https://github.com/Rajan/lesspod # markdown only
• https://github.com/Miserlou/Zappa-CMS # markdown only

Astonishingly, the system I found that met most of the requirements was the same piece of software that’s been eating the internet for a while. WordPress. Specifically WordPress with a plugin called WP2Static.

I had some time to experiment with WP2Static. It was intuitive to use. I tested it out on a copy of the Culture Foundry site and deployed it both to the filesystem. With the default settings, it took about six to seven minutes to build a static file copy of the site. Tweaking a few of the settings, in particular the publish and the crawl settings (which are defaulted to work on a cheap hosting system), dropped that to under two minutes (for the filesystem). I also experimented with publishing to an S3 bucket. This took more than 10 minutes.

After I published the static site (to the filesystem of the same server running the WP application and to S3), I ran Google’s page speed insights. I expected to see a massive speed increase, but it really didn’t affect it much (a score of 39 for a WP page, 41 for a static page on the filesystem). In fact, the s3 page speed score was really bad (15, if I recall correctly). The current website has performance issues not due to delivering the HTML via PHP/WordPress, but rather to other factors.

An additional complication is that some of the WP plugins used for the site used PHP to build the front end. In particular a slideshow component used both PHP and Javascript, and so was incompatible with the static site generation. This is not an insurmountable problem, but is indicative of the types of issues I think we’d run into trying to backport an existing site of any complexity to a WP2Static build. You can of course do a risk assessment before beginning to evaluate all plugins used. If this were being used for a greenfield site build, you’d simply set up the static page generation as part of your build process and any incompatible plugins would be identified rather quickly.

The benefits of static site generators are clear. If your website has certain characteristics, you can generate the site and place it on a service like S3, front it with a CDN and have a tremendous amount of scalability with limited complexity and cost. However, this comes at a price. None of the straightforward solutions I was able to find had a robust editor experience, and WordPress, while it has an impressive editor experience, would need careful curation of front end plugin choices to ensure publishability. Finally, a static site generator is not a magic wand for a fast site. Javascript weight and correct headers, among other things, are important no matter what HTML delivery method you use.