Long story short, I had to investigate and get to the bottom of this whole headless WordPress hosting thing!
What follows is a look into the world of serverless WordPress: what it is, how it works, why bother with it, who should potentially use headless WordPress hosting, which solution to choose when building your setup.
What is serverless WordPress? | Why would I go static WordPress? | Who needs static WordPress hosting? | Who should avoid serverless WordPress? | How serverless WordPress works | Top static WordPress hosting companies compared | What about the performance? | What if I want to go DIY? | Final verdict
What is serverless WordPress?
The word “serverless” is perhaps not the most fortunate since you still do need a server to make your site work. “Static WordPress” is much more on point.
So the basic idea of serverless / headless / WordPress to static is this:
Instead of generating every page on the fly each time a visitor wants to see it, you can convert your whole WordPress site to static HTML just once, and then serve that to everyone multiple times.
Something like this:
What this means is that headless WordPress is a process involving two main steps:
- Convert your site to static (HTML, JS, CSS).
- Serve it to people instead of the regular site.
Now the cool thing is that you can still work with your “seed” WordPress site pretty normally. You get to add plugins, themes, work in the wp-admin, change stuff, write posts, etc. The only difference is that when you’re done with all that, you have to convert the site to static and deploy it to the server.
There are some pros and cons to the whole approach:
Why would I go WordPress to static?
👍 There are four reasons headless WordPress makes sense:
- Security. Static is extra safe. I would even risk saying that it couldn’t be more safe. No WordPress security plugin, no security guideline (complex password much?) can give you the same level of security as does headless WordPress. Basically, since it’s all static, there’s nothing to break into … other than the actual machine on which the files are sitting.
- Speed. Static files load faster than dynamic files. PHP instructions and database calls simply take time to execute. Since there’s no such step, static loads faster.
- Cost (usually). Static should be cheaper to host, especially if you’re dealing with high traffic. After all, there’s less server time required to process the requests. I’m saying that it “should” be cheaper because, in practice, this is not always the case.
- Peace of mind. This is a combination of all of the above, but the idea is that you don’t have to worry about any updates, hackers, maintenance, scripts breaking, bad plugins, etc. Static sites simply
👎 There are some pretty significant downsides as well, and especially if you’re used to that “WordPress life”:
- Constant reconverting. You have to reconvert and deploy your site each time you change anything on it.
- Comments don’t work. Okay, I’m being harsh. What I actually mean is that the native WordPress comments won’t work on serverless WordPress, plus no comment plugins will work either, since they all require PHP. Your only solution is to switch to Disqus or use social comments (those work off outside sources).
- Contact forms don’t work. Same thing as with comments. If you want contact forms, you’d need to embed from Typeform, Google Forms, Zendesk, etc.
- WooCommerce doesn’t work. Again, WooCommerce is a dynamic PHP plugin. Therefore, it won’t work. Alternative? Switch to Shopify and then integrate it with your WordPress site.
- Forums don’t work. Forget about bbPress. Zendesk provides some alternatives.
- Membership modules don’t work. If you’re using BuddyPress or WPMember or anything like that, again, those won’t work. You’ll need to switch to third-party.
- Site search doesn’t work (!) – yep, your good ol’ WordPress site search won’t work. You can add a Google Search module as an alternative. Though, of course, not perfect.
In general, if you use a plugin that does any sort of dynamic thing based on the visitor’s input, it won’t work on serverless WordPress.
Pretty significant downsides, that’s for sure. Plus, those serverless WordPress setups are generally difficult to manage if you want to go the extra budget-minded route (read: you want to pay just for the server space and not sign up to an out-the-box serverless WordPress solution, which we’ll compare a couple of below).
In such a DIY scenario (we also have some DIY serverless options for you at the bottom of the post), you will find yourself working with the command line and communicating with the server directly. Of course, this might not scare you at all, but for many people, this is a no-go area.
So, before we list some of the viable headless WordPress hosting solutions in the market, let’s first answer the main question:
Who needs static WordPress anyway?
So despite the advantages of the serverless WordPress setup – the speed, security, etc. – isn’t the whole point of WordPress that the site remains dynamic with the changes taking place in real time?
It’s hard to argue with that, but there are still some viable use cases where WordPress to static can be, dare I say, better.
a) Freelancers and agencies
This is probably the most intuitive scenario where static WordPress makes a lot of sense.
As a WordPress freelancer, you may encounter clients that aren’t very interested in updating their sites at all (or even publishing content) after you hand them the keys to their new site. Maybe they need a simple business-card website, or can’t be bothered to do anything with it due to lack of time or personnel.
At the same time, you don’t want to leave anything to chance and risk the site getting broken into when there’s a new vulnerability discovered or something.
In a scenario like that, converting the site to serverless WordPress just makes sense:
- the site remains online,
- it can be accessed by everyone,
- it’s cheaper to run and uber-fast,
- the client doesn’t even notice nor care that the thing is static.
You get all of static’s benefits with none of the downsides.
In such a case, you basically treat WordPress as your “site builder” and not the engine running the site.
b) Sites that don’t get updated a lot
Generally speaking, having your WordPress in an always-on state – where everyone can log in at any time and do whatever – isn’t perfect.
If you’re already updating the site very infrequently then why not lock it down completely when nothing is going on. Again, this is a much safer and much cheaper way to host your site.
Speaking of security:
c) Sites where security is of the highest importance
There are cases where you just can’t afford for your site to be broken into and messed with.
And this isn’t even about government sites and so on (I’m sure those live by their own standards).
But, for example, even your local school wouldn’t want their website to be hacked into and populated with content that is inappropriate or obscene. Even though situations like that can be explained afterwards, the bad impression remains.
d) Sites with complex designs
In the age of the page builder, it’s not uncommon to handle the bulk of a site’s design in the builder itself. As in, you get just a simple framework theme and then build everything else with your favorite page builder, plus add some cool plugins to the mix to make the site look extra-great.
The only problem with that is that such a site ends up being a bit heavy, which will be reflected in its performance.
Going WordPress to static is a quick fix that still lets it look great, and also perform great at the same time.
e) Sites that have run their course
Certain types of websites have limited shelf lives. This might be a site for an event, gov-founded project, an archive, etc.
Some of those sites may have to remain active for legal reasons or just to show people what had happened. Keeping those sites as live WordPress installs only creates problems. You have to maintain them, come back and update the scripts, etc. It’s therefore a lot simpler to go WordPress to static and be done with it for good.
f) Demo sites
For example, if you’re a WordPress themes developer and want to showcase demos of your themes, why not do that on static sites rather than run some elaborate WordPress setups?
A bonus is that you also don’t have to worry that things will break after a rogue WordPress update.
Who should avoid static / headless WordPress hosting?
This basically all comes down to one factor:
If you find yourself logging into wp-admin every day, avoid serverless WordPress!
It would just be too much work on a daily basis to have to deal with converting your site from WordPress to static over and over again. Especially since converting a normal-sized blog can take anything from 20-60 minutes.
In other words, if you’re a blogger, you can forget about headless WordPress hosting.
How serverless WordPress works
There are two paths to serverless WordPress:
- path (a) is simply about signing up with a headless WordPress hosting company and letting them do all the heavy lifting, while you can use a WordPress dashboard pretty normally
- path (b) is the DIY approach; this time it’s you who takes a working WordPress site, converts it to static and then uploads it somewhere from where it can be served to visitors
Let’s focus on path (a) here since it’s more approachable for everyone. We’ll have some recommendations on the DIY approach at the end of this post.
In general, all static WordPress solutions out there are similar from a user’s point of view.
Your experience starts when you sign up with a headless WordPress hosting platform and pick your plan, the usual.
After that, you get to create new WordPress sites with a single click – multiple ones as well.
Those sites are fully functional and can be used like any other WordPress website. You can log in, install themes, plugins, configure anything, do custom code modifications, the lot.
The only difference is that the site is not visible to the public. For all it’s worth, it’s your own personal staging environment.
When you’re done making your tweaks, you can roll it all out to the public with a couple of clicks. The conversion process might take a while depending on how big the site is (20-60 minutes, even).
The whole process is very approachable and simplified to the max. Basically, no server management skills are required.
That being said, there are some differences between the top serverless WordPress solutions out there.
Top static WordPress hosting companies compared: Shifter vs HardyPress
Here’s a simplified comparison table:
Here’s the in-depth comparison. The players we’re looking into here are: Shifter vs HardyPress:
Overall, the company is active in the WordPress community – sponsoring WordCamps – and also in tune with the users’ true needs.
Pricing and features
Shifter offers five main pricing tiers, based on how many sites you need and how much traffic you expect. Overall, those seem to cater well to the different type of users that might be interested in converting to Shifter.
- $0 – 1 site // 1 GB storage // 1 GB monthly transfer // backups disabled
- $20 – 3 sites // 10 GB storage // 1 TB monthly transfer
- $40 – 10 sites // 500 GB storage // 5 TB monthly transfer
- $90 – 30 sites // 1 TB storage // 10 TB monthly transfer
- $150 – 50 sites // 1 TB storage // 10 TB monthly transfer
There’s also a free trial that allows you to test things out (credit card required). And you get a discount when paying yearly.
This pricing is not crazy, but also not super attractive. If you’re running 2-10 sites, you can find cheaper standard hosting options out there. Of course, you don’t get the “WordPress to static” ability.
Overall, Shifter offers some cool features apart from the whole static thing. All plans include integrated CDN and HTTPS. Custom domains are also available. Plus: there’s HTTP/2 enabled gateway, it’s IPv6 ready, cache optimized, and you get one year of backups.
How to use it
Shifter offers a solution that’s exceptionally easy to use. And I do really mean that.
The signup process is … a signup process. Nothing fancy. Standard stuff.
After that, you get access to a clean user panel through which you can do all your work.
This is where you can create your new site. After giving your project a name, you will see the main project panel.
The natural first step is to click on “Start WordPress” and get to work on your site.
After WordPress initializes (this might take a minute or so), you will be able to log into the dashboard.
It’s business as usual there. A standard wp-admin panel where you can do all the usual stuff.
When you’re done with your changes, you can come back to Shifter and click on “Generate” to create what’s called an artifact – your final static image of the site.
That artifact can then be made public – deployed.
On the face of it, your serverless WordPress site looks like any other site. It even says “WordPress” when you look up the
generator meta tag in the HTML source.
The thing to be aware of is that Shifter doesn’t remove all the static-incompatible things automatically. Meaning, if you leave the native WordPress comment system enabled, Shifter will display the comment forms – they just won’t work in the final headless WordPress hosting setup.
When you’re done with all your changes, you can simply “stop WordPress” and lock it down, leaving you with only the static version available to the public.
Pros and cons
They’re also similarly involved in the WordPress community, making appearances at WordCamps and addressing their product to the WordPress pro.
Interestingly, with HardyPress, you can still use contact forms and site search on your static WordPress website.
Pricing and features
HardyPress’ pricing model is a bit more simplified – there are four tiers that differ in price much more significantly than with Shifter:
- $5 – 1 site // 500 MB storage // 50 GB monthly transfer
- $20 – unlimited sites // 3 GB storage // 500 GB monthly transfer
- $65 – unlimited sites // 30 GB storage // 2 TB monthly transfer
- from $350 – custom setups for enterprise
There’s a free trial available (no credit card required), plus a discount if you pay yearly.
HardyPress offers a handful of neat features, including things like, WordPress shutdown (turn off your live WordPress instance when you’re done working), everything is hosted on Amazon AWS, integrated CDN, HTTPS, HardyPress Site Search (a search engine for your site; since the standard WordPress search won’t work), one year of backups.
Plus, if you use Contact Form 7 specifically, it will still work even after the WordPress to static conversion. Not sure what sort of trickery is behind this, but that’s cool!
How to use it
As of this writing, you cannot simply create a new account on HardyPress. You need to request access via the signup form and then wait a while to be approved (took 10 minutes in my case, so no biggie).
After that, working with the platform is pretty clear. Right up front, HardyPress asks you if you want to import an existing site or create a new one.
If you go with the empty site, you just need to provide your new WordPress login details and click on Install.
After a short while, you will see your new WordPress instance on the dashboard.
From now on, everything is pretty easy to work with. Similarly to Shifter, you get your standard WordPress site install.
I also have to give it to HardyPress’ onboarding. Good stuff!
You can log in to your WordPress site, do whatever changes you want, and then deploy them to the public. When you’re done, just shut down the site.
It’s also worth noting that the user panel looks to be more feature-rich than with Shifter. You get a lot of info on how to connect to your site via FTP and PHPMyAdmin, the deploys you have generated, the backups that are kept for you, the plugins active on your WordPress site (plus if they’re compatible with HardyPress), and also a general info panel listing things like your service usage, PHP version, cache settings, and more.
When you view your static site, it looks just like its WordPress version – as you would expect.
Pros and cons
What about the performance?
To do this test, I created the same site on each of the platforms and then deployed them as static. The sites run the same Hestia theme, a handful of plugins, plus some test content.
Here are the loading times:
|The site generated in||1.5 min||1 min|
Overall, it’s all very good! As you can see, the loading times hardly go above the half-a-second mark. This has probably a lot to do with the integrated CDN. Granted, the sites were not that complex in themselves, but it still shows what sort of performance upgrade you can expect from headless WordPress hosting.
What if I want to go DIY?
If you’re not afraid to experiment with serverless WordPress on your own – as in, without a user-friendly tool like either of the ones above – then there are a handful of viable options for you:
- You can get a Google Cloud or Amazon AWS account on your own and then go WordPress to static using the Simply Static plugin. Here’s a good tutorial.
- Use Gatsby. It’s a JS framework that helps you build sites with React. You can use it to make WordPress static as well. Here’s a tutorial.
- Use Pressless. To quote the docs, “A tool that migrates an existing WordPress site into a fully functioning serverless site, powered by AWS (Cloudfront, API Gateway, Lambda, S3).”
Each of them involves a different level of “DIY-ness” so you should find something that fits your needs and skills.
The final verdict on serverless WordPress
Overall, the static WordPress hosting space in itself is my no.1 surprise of the year.
The sole idea of taking a fully featured WordPress site and converting it to static HTML sounded bonkers to me. But now, after examining what’s possible first hand, I have to admit that … it makes sense.
It’s not groundbreaking, not 100% right for every scenario, but it certainly does make sense for some.
As for Shifter vs HardyPress: is any of them better? Not quite. Both solutions are pretty similar from the user’s point of view and have their pros and cons. There are free trials available with both of them, so it’s probably best to experiment with either one and make up your mind based on that.
Don’t forget to join our crash course on speeding up your WordPress site. With some simple fixes, you can reduce your loading time by even 50-80%: