Pros and cons of using WordPress to build static sites
29 March 2021
The idea of “headless WordPress” – using WordPress as a content management system and then pulling the data out to build a static site – has been around for a while now. I remember seeing Jason Lengstorf talk to Jason Bahl about the WPGraphQL plugin back in 2019.
After building this site with WordPress, WPGraphQL and Eleventy, I think it’s time to reconsider. The developer experience was a lot smoother than I expected, and I’m really happy with the output.
In this post I’ll weigh up the pros and cons of static sites versus a traditional WordPress site (using WordPress as a back-end and a front-end). This isn’t meant to be definitive – it is a way to put my thoughts down in writing.
The benefits of static sites over traditional WordPress
Building and deploying static websites – simple HTML files with assets – have a few overlapping benefits.
Simple HTML files are easy to host
Netlify makes hosting a folder of HTML files very easy – they handle all the difficult challenges (eg. caching, rebuilding when the Git repo changes) and let you focus on building.
They also make it cheap – Netlify’s generous free tier gives you 100GB of bandwidth per month.
Simple HTML files are fast for visitors
Because your website only rebuilds when you change content, your site will feel even faster for return visitors because the content will likely be cached in their web browser.
Search engines love simple static sites
Google’s webmaster guidelines advocate for:
- websites that load fast
- properly tagged content – eg. SEO tags
- content broken up into headings
If you are building simple static sites with semantic HTML, and deploying it to Netlify, you are satisfying these requirements.
The shortcomings of static sites over traditional WordPress
These are the reasons that are holding me back from pushing for headless WordPress in every scenario.
An extra step for things to go wrong
When you make a change to a traditional WordPress website, your changes are immediately available because rendering a page is handled by WordPress itself.
When you build a static site from WordPress, there is an extra step where your build process pulls the data from WordPress, compiles it into HTML files, and then deploys separately.
While there are tools that make this more seamless (eg. automatically rebuilding on page changes), it is still an extra step where things could go wrong:
- a bug in your code could stop the build process
- the hosting provider that handles the build step could go down
Harder to preview content
Working with traditional WordPress, it is very easy to use the ‘preview’ button to see what a page will look like before you publish.
Working with a static site, it is harder to know what the website will look like before you publish your changes.
A solution to this is to turn off Netlify’s ‘auto publishing’ feature – this means that your site will still re-build when content changes, but you’ll need to approve the new build to make it live. This might suffice, but it is not as seamless as the feedback loop of WordPress’ built in preview button.
Interactive and dynamic pages
If your website relies on realtime information and dynamic content that needs to be ready on each page request, I believe a traditional WordPress setup is a better fit.