WordPress rose to fame with its five minute install. The ease of administration has made it possible for large corporations, and grandmas as well, to build a winning blog, and it has matured into a content management system with a thriving ecosystem of contributors.
What happens when a single install of WordPress on a shared host is not enough? For some the answer is to abandon WordPress. Considering WordPress’ market share is still slightly increasing despite already being a dominant force, obviously many chose to stay with it.
Virtually every hosting company has an article dedicated to tips and tricks to speed up WordPress. Eventually there is a level beyond this where more control is needed and a single installation can’t provide a fast enough response time regardless of optimization.
Both AWS and Azure have reference architectures of how to scale WordPress to a potentially massive level. As you can see from the complexity below, it isn’t trivial to accomplish this.
I have tried similar systems with multiple instances of WordPress. It does make WordPress more robust, more resilient to failure and can scale wonderfully for most server-side metrics. For instance, take requests per second, it can automatically scale to handle virtually any number up to the network limits of the ec2 servers. It’s not a panacea though; for instance it won’t necessarily make your pages pass Core Web Vitals; it measures more than speed. Also, it may not be the most cost effective.
The tact I’ve taken is to remove the database from the client server request response cycle as much as possible. There are hosts, like Strattic, that cater to making it static with a few clicks. What I don’t see a lot of is AWS reference architecture diagrams for serving WordPress in a static fashion like the one below.
One of the key missing parts that AWS doesn’t provide is a script on the ec2 WordPress admin server to create static pages. WordPress includes a save_post hook that can be used to call a script at the appropriate time to create a static page and send it to an s3 instance. The application load balancer can direct read requests to the s3, searches to Elasticsearch, and write requests to a second ec2.
Having a second ec2 depends on how much writing is a focus for the site; if it is primarily reading with a newsletter sign-up, it may not be necessary. Also, if the activity for the database is only administrative the Aurora instance may not be needed.
WordPress has no shortage of competitors: Wix, Squarespace, Google Sites, Shopify, etc. Despite pushing 20 years old, Wordpess has handled itself quite well and continues to be flexible enough to adapt to new architectural styles.
