top of page

Managing a High Performance WordPress Membership Site

There’s nothing wrong with running a WordPress membership site for a few folks. Lots of people do it. But that’s not the path to high profits unless every single member is paying you hundreds of dollars a month. If you have one of those sites, hit me up – I want to know about you. 🙂

But like I’ve told others, the average membership site generates between $8-18/month. Some make a bit more and on average, the only sites earning over $50/month consistently are financial/investment sites. So if you’re only charging twenty dollars a month, and you still want to make good money, you’re going to have to have a system that scales.

Membership Sites & Caching

If you’re non-technical, this article may not provide you with a ton of insight, other than to say, find some help by getting some great developers to help you and host your site on an awesome infrastructure. If you want to learn more about what caching is, I suggest you read this incredible article by Zack Tollman.

But if you’ve worked with WordPress and performance a bit, then you’re likely to tell me that I should look at caching plugins because it makes things faster, better and worked for you. The problem with that answer is that most caching plugins don’t do much for logged in users.

See the paradigm most people have is that non-logged in users should get pre-cached pages that load super fast, and logged-in users are the authors and admins who are working on the back-end, and don’t need the same level of performance.

And for most sites, this works. But membership sites are a bit different.

The end user is a logged-in user. So you need a solution that works for logged-in users. Additionally, membership sites are often filled with user-specific data (from menus, to sidebar widgets, to content) that needs to be current. So full page caching isn’t a solution – from a plugin or hosting provider.

Instead, what you need is partial page caching.

Partial Page Caching Options

Unfortunately, and I could be wrong here, these kinds of approaches are neither in abundance, nor are they often talked about when you’re evaluating a membership plugin. I’m to blame too.

I created a comparison of membership plugins, and wrote about decision criteria for membership plugins and never mentioned partial page caching or high performing membership sites.

But that doesn’t mean they’re not available at all. In fact over the last few months, I’ve seen more people writing about it. So let me introduce you to a few different approaches you might want to consider.

The first option is using Transients. About a year ago, this was covered over on with a video showing you how to use Transients to create a partial page caching system. While this is possible, I find that it doesn’t scale super well for membership sites.

There’s a great article explaining why it’s not great by Austin Gunter of WP Engine on their blog. Suffice to say, if your options table is growing like crazy, you may be doing it wrong.

By the way, garbage collection for transients (an issue raised in Austin’s article) may get added to WordPress in 3.7

A second option is to use a little class created by Mark Jaquith. He calls it fragment caching, but it’s not different, per se, from partial page caching. You’d want to check out this article that has the code in it, and read the comments.

I think this is a pretty powerful option for a lot of situations, but scaling a membership site is all about limiting the application processing side of things.

To do that right, you need a solution that doesn’t have to process as much logic on the second and third trip (by the same or other parties). Zack Tollman highlights this in another of his well-written articles:

For what Jaquith and Ruter’s functions purport to do, they work quite well; however, it does not provide system for partial page caching that might allow for a shorter WordPress page load in cases where only a small amount of data is needed.

A third is to look at Edge Side Includes (ESI). When  you’re building a seriously large membership site that needs to scale, you want the least amount of server load as possible.

Supporting high concurrency will mean limiting not only how many database calls you make, but how much application server processing you do. After all, you don’t want to peg CPUs either. You’re looking for high simultaneous connections per server before your CPU hits whatever threshold you’ve set.

ESI provides that option – even though it’s not a WordPress-specific solution. Because Zack already wrote a great paragraph defining it, I’ll quote him again.

ESIs, which were developed by a number of prominent technology companies, allow a developer to denote specific fragments of a full page that have a different eviction policy than the whole page itself. Moreover, it allows a developer to pinpoint parts of a page that can be generated separately from the whole page. By using special tags in the HTML, the HTML can be parsed to determine which parts of the page need to be generated. As such, this approach opens the door for identifying a fragment that needs to be generated uniquely for each logged in user.

Zack is clearly on to something here and it sounds like he’s going to try to create a WordPress approach to this solution, integrating with Varnish, for example this summer.

I don’t know where to send money yet, but when I find out, I plan to sponsor some of his effort. Making this available to everyday folks would be great, when creating membership sites.

Lastly, there’s a solution that exists today – by Scott Kingsley Clark in Pods. He’s built a partial page caching solution – it’s called a pods view. Now, I’ll be honest, I hadn’t ever heard of partial page caching in Pods. I always thought about it as a solution for post types.

But the more research I did, the more I would find Scott’s comments and links back to the Pods site. So I checked it out and it looks like it could work today.

I haven’t used it yet, but put it on your list to check out if you have a slow performing membership site.

A WordPress Membership Site is Work

If you’re building or managing a WordPress membership site that is seeing a lot of traffic, you’re going to want to dig into what’s going on behind the scenes. It may not be that you need partial page caching. It’s not the silver bullet (there are no silver bullets). But if you do, then you’ll want to check out the four solutions above, because I think they’ll help your site scale.

Of course, things don’t start there. They start with picking the right plugin. But I’ve written all about membership plugins before, so you know that by now.

0 views0 comments

Recent Posts

See All

What does it take to scale WooCommerce?

Can you scale WooCommerce? One of the most common questions I hear a lot about WordPress and eCommerce revolves around the notion of WooCommerce and it’s ability to scale. “Can you scale WooCommerce?”


bottom of page