The WordPress of the quiet past is inadequate to the stormy present

WordPress took over for good reason. Its plugin architecture and design flexibility make it easy to build attractive, effective marketing websites. WordPress does this by combining the data in the database with the designs and customization stored in the code to generate each page when users request it. Like all applications, the code needs to be kept updated. The website code itself needs to be on a secure server that is being constantly scanned for malware.

For companies that rarely update their site, that's a lot of overhead which adds to the cost of owning the site and site performance.

For a long time that overhead was part of the price for having a professionally designed site. There are other solutions but they either limit design scope, cost too much, or have similar performance issues.

The technological fix is straightforward. Instead of serving code, build the site with pre-generated files instead of needing something like WordPress to create them.

The problem is until now, building websites that way would've been a logistical nightmare just to keep the code in sync and push live. That started to change a few years ago, when the tools to process and serve the necessary files became simple enough to manage in a web interface.

At the same time, web technologies advanced. Modern web technologies are much more efficient, so less code can do more.

This all freed up the content management system from having to serve the content as well as store it. Now the data can be stored in such a way so it can be sent to the site user as efficiently as possible.

As an example, I recently tested a client's WordPress website on Google's Page Speed Insights, a standard tool used to measure site efficiency. Lower scores may impact google ranking. Here is the report for mobile (the desktop report is always better than the mobile report):

Not great. Accessibility and SEO are alright, but the rest is a mess. We had done everything we could on the WordPress.

Their site doesn't change often, maybe 5 or 10 images are swapped in or out every couple of years. Why do they need the overhead?

As a test, I converted the site from WordPress into Statamic CMS, then configured GitHub to publish the pages as flat files when changes were checked in.

Here's the mobile report after conversion.

Not a difficult call. In a relatively short amount of time I was able to improve important performance statistics, lower the cost of ownership of the site, and completely secure the site from malware. All without altering site functionality.

These tools aren't just to convert existing sites. Because they all work with popular design tools like figma, designers can work in the tools they like best and be sure they are going to get the site they envision.

It sounds strange for someone to be breathlessly excited about making files for brochureware sites, but I've been in tech for one score and seven years and this is the stuff our fortran fathers were dreaming about.