Larry Hudson

Writing about making websites

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.

For the last couple of years I’ve seen headless WordPress and the JAMstack (sites powered by JavaScript, APIs and Markup) as the bleeding edge, but not ready for people who just want a basic website. In my experience, frameworks like Gatsby pass too much JavaScript to the client, which can negate the performance benefits of simple HTML, and add a layer of complexity.

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

Working with Eleventy, it’s easy to build a website that is just HTML and CSS, with no JavaScript passed onto the visitor. This means your website is performant – it will load quickly on your visitors’ devices.

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.

I would prefer a server to handle the information and serve it to the user in plain HTML and CSS, rather than giving the user a bundle of JavaScript for fetching information on the client side.

I’m still thinking about this

This isn’t meant to be a definitive verdict for everyone – I’m just trying to spell out the pros and cons. If you have any more ideas, please let me know on Twitter or by sending me an email.