Super fast WPGraphQL at scale with GraphQL edge caching at Patronage

Patronage builds a whopping 30 to 40 websites a year (a feat for a team of six!), providing A/B testing and conversion optimization at an incredibly high volume. Focused on the niche of political advocacy, they’re often dealing with clients and projects on limited budgets with limited timelines — for sites that get a lot of visits and experience large traffic spikes.

Non-technical folks may be tempted to say just go to Squarespace and nab a template. But that template won’t build you a list of 9 million people from scratch, which is what Patronage helped one of their clients accomplish in a matter of months. Mic drop. 

How does Patronage build and maintain so many websites? By standardizing on a stack across all their websites that they’re only slowly evolving over time. Their base boilerplate is completely open-source, which they then fork for every project they build.

WordPress + WPGraphQL + Next.js

Because Patronage deals with many projects, short timelines, and lots of traffic, they want to use popular tools that their customers already know and stand up infrastructure that can scale without being too complex. On top of that, their customers also expect modern websites with fast performance that load quickly – a major driver of conversion.

That’s why Patronage relies on WordPress as their CMS, which content editors tend to be familiar with, in a headless manner with Next.js websites hosted on Vercel fetching data via WPGraphQL.

WPGraphQL, Next.js, WordPress; sounds like a dream stack, giving their content editors the tools they love and their users a fast experience — so what's the problem?

Traffic spikes.

Given the nature of political advocacy, a lot of people will visit the websites they build in a short amount of time, which aren’t exactly the conditions that help WordPress shine. But when you think of traffic spikes, you think of (edge) caching – and hopefully, Stellate!

Lucky for us, that’s exactly what Patronage did.

GraphQL Edge Caching WPGraphQL APIs

“We’d have all these Next.js serverless functions,” Patronage founder Cameron Corda told us, “that would just sit there and wait for our WordPress server to respond to the GraphQL queries — often 1 to sometimes 5 seconds. So we’d see these pretty decent-sized bills and usage on Vercel and when the page wasn’t prebuilt, the websites would also just be slow, taking seconds to render for the current user.”

It’s as if everyone were about to wish you happy birthday at your surprise party, but then you never showed up. Kind of a bummer.

Yet the party goes on! They put the Stellate Edge Cache in front of all their WPGraphQL APIs, which reduced the traffic their WordPress servers have to handle by a jaw-dropping 99%:

That reduced load led to a big speed up even for uncached responses due to the reduced load on the origin. Their p99 origin response time almost immediately dropped from over 2 seconds to below 1 second:

(guess when Patronage deployed their Stellate service integration to production!)

That’s not even mentioning the 99% of responses served from the cache with a p99 response time of 50ms worldwide! Finally, that massive performance boost across the board also reduced their serverless function execution time by over 95% and thus reduced their infrastructure costs significantly:

(did you manage to figure it out yet?)

Purge all the things!

Because their clients publish so infrequently, Patronage simply does a full purge of the entire cache whenever the data changes. While always purging everything isn’t the right solution for every use case, their data changes so infrequently that they can have their 99% cache hit rate even without fine-grained invalidation!

Cameron also mentioned that “our purging is 30 lines of code. I’ve appreciated that with the Stellate Edge Cache: it’s not endless documentation to do simple things. Simple things are simple!” (That’s our new motto.)

The entire WPGraphQL Stellate Edge Cache integration along with the rest of their standard boilerplate is open source on GitHub, by the way. If you’re curious about using the Stellate Edge Cache with WPGraphQL, consider their boilerplate your keys to the castle!