Serverless WordPress

This article is written in broad terms and aimed towards our clients (Hi!). I will be documenting the technical aspects of the set up for developers in the coming weeks.

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.tld can also have a crack a exploiting access to www.domain.tld/admin.

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.

www.domain.tld/wp-admin > wp.domain.tld/wp-admin

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 www.domain.tld site.

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.

The Catch

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.

—

Good fits

• Portfolio sites
• Small Business & Brochure websites
• Blogs (using third party comments like Disqus)
• Static backup and failover sites

Unsuitable Sites

• Ecommerce (WooCommerce)
• Forums
• 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.