The pains of Gatsby and Wordpress

December 3rd, 2019 - 4 minute read

Wordpress powers at least 30% of the internet (Source 2018). Naturally a lot of businesses have their company website hosted with a Wordpress setup which in comparison to a static Gatsby site can be extremely slow.

I pitched we replace the site with a Gatsby version, but to ease a transition to a good headless CMS, I proposed we continue to use Wordpress as the backend.

In hindsight, if you can convince someone to move to Gatsby, you can probably push a bit further for a simpler CMS like Sanity Studio or Contentful.

Tools we used

  • WPGraphQL
  • Gatsby
  • S3
  • Github API v3

Why this process?

So we already had a site I had built earlier in the year using ACF (Advanced Custom Fields) which worked better and suited a custom layout. But to accomodate for future developers we needed to move this from PHP to a language better suited to frontend developers we hire (React).

Gatsby is an incredible tool. It's a static site generator for React with an emphasis on speed. I could be wrong, but I'm pretty sure it pans out faster than an equivilant HTML site as you're only loading changed content when navigating between different pages (through code splitting magic).

WPGraphQL allows access to all the Wordpress data via a GraphQL api which can be consume by Gatsby. Gatsby can consume from multiple GraphQL hosts, meaning once we had the majority of the data coming from Wordpress, we could introduce a new CMS and slowly phase out Wordpress.


Wordpress doesn't lend itself well to graphql. It's fiddly as heck to configure to get all the data you want and whether it could stand the test of time is still questionable.

It's also quite early days for WPGraphQL, there was a source from wordpress plugin which I had to use initially but it had a ton of issues leading me to WPGraphQL. WPGraphQL doesn't fit well with Gatsby nessecarily and requires some massive queries to get the appropriate data.

Another downside is the build time between Gatsby and Wordpress. With a traditional Wordpress site you can edit the content and have the changes reflect almost immediately. This also feeds into another problem with this setup no preview builds. This wasn't a big issue for us as we didn't update the content a whole heap or need to double check out previews.

The way we deployed it was also a problem. My initial pitch used Netlify, but as a startup we needed to cut costs resulting in us hosting it ourselves. If we had used Netlify we could use a community plugin to re-deploy Gatsby. I took an existing Netlify build hook plugin and adjusted it to hit our own AWS lambda which would re-run the Gatsby build script.

We had to connect the lambda to a Cloudfront API route as well, so that we could hook into Github too for deployments on git push.

Final thoughts

The downsides might outweigh it for you, but if you have a huge Wordpress site and want to switch it out slowly. It could be a solution for you, I recommend that you redirect certain pages to a Gatsby site instead. Gently move it over page by page and replace it, redirect to the original Wordpress site if you don't have the page yet. Its a better solution than trying to get Wordpress to play ball, less downtime for your developers, and potentially might be a faster transition.