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 serverless CMSes. 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.
- 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
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.