Over the last few months I have been testing ‘serverless’ Wordpress builds and am now giving new clients the option to opt-in to this type of hosting.
Most people ‘get’ how a bog-standard monolithic server works. Your files, database and content mangement system all live on one server. People access that server.
There are three obvious downsides to this type of set up.
Downtime Your eggs are all in one basket. Your server goes down (these things happen) and your website goes down.
Speed Geography means that a user accessing your server in Amsterdam from Singapore is going to load your site slower a user in London. The actual data has to travel further.
Security Having your content-management ‘public’ means anyone who can access
www.domain.tldcan also have a crack a exploiting access to
A Serverless Approach
My approach to serverless hosting moves the content-managed Wordpress install into its own hidden sub-directory. This is accessible only to the content managers and site administrator.
Anyone now looking to exploit Wordpress at
www.domain.tld/wp-admin is not going to find anything.
From your perspective you now have staging server at
wp.domain.tld/wp-admin which you can use to manage content exactly as before.
The only difference is that any changes you make on the staging domain will not be public until you ‘deploy’ them to the public
When you do this the server runs a script that scans every page of your site and generates a static version (similar to how a caching plugin would work).
While this process can take several minutes depending on the size of the site, once you click deploy the server will continue to deploy the changes regardless of you babysitting it. You can log out and get a cup of tea.
Once the deploy script is complete the changes to your site are pushed out to dozens of servers across the content-delivery-network.
When users try to access the now pre-cached site they access it from the nearest geographic location.
Typically I am seeing pages loaded around three times faster using this method vs a standard LiteSpeed cached Wordpress install.
Yeah. There is a catch.
Taking this approach breaks the connection between Wordpress and the public site.
Any forms ( i.e. contact forms, ecommerce functionality, search functionality ) that either feeds information back into Wordpress, or queries Wordpress on the fly, will not work.
This isn’t the end of the world for any simple forms. Basic contact forms can be migrated to Basin (which is excellent) but more complicated functionality that adds content to the Wordpress database (for example comments or ecommerce functionality) will not work.
- Portfolio sites
- Small Business & Brochure websites
- Blogs (using third party comments like Disqus)
- Static backup and failover sites
- Ecommerce (WooCommerce)
- Blogs (using Wordpress’s native comment system)
- Sites reliant on plugins to push out content to other parties (eg. to social media) as it will use the staging URL.