Managing a High Performance WordPress Membership Site

9 Comments

wordpress-membership-site-puzzle-high-performanceThere’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 WPMU.org 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.

About This Site

This site is hosted by Pagely - running on Amazon's hardware, making it lightning fast. They're a managed WordPress host which means they take care of my site so I don't have to. Starting at $24/month, this may be the perfect solution for you too.
  • http://webendev.com Bruce Munson

    Great write up Chris.

    I has the good(?) fortune of creating a BuddyPress site for a large non-profit organization a while back. Performance was a major issue. They wanted to run it on inexpensive shared hosting (against my advice), and it was quickly a problem once membership grew.

    I did not know about Mark Jaquith’s fragment caching. I’m not quite understanding how I target what is cached though, but I’ll think about it some more.

    I’ll definitely be keeping an eye on ESI as it looks promising.

    Thanks for your time on this!

  • http://benmay.org Ben May

    Alas what you’re written about Fragment caching / transients etc, is true, however if the rest of the site & server isn’t configured correctly to say, use memcached or APC memory caching, all that stuff is going to be stored in MySQL / Databases.

    This means a bucket load of SQL (albeit faster than the original query perhaps) will be getting done.. Depending on the scale and size of the site, the SQL transactions are going to be a problem.

    This is where you get smart people to architect hosting setups that include various forms of caching to make sure it all runs nicely. Not something a plugin can just solve :-)

    • http://chrislema.com chrislema

      Absolutely. That’s why my recommendation is to get some smart help.

  • http://www.facebook.com/webhostingcompany Jim Walker

    I’ve had a good deal of luck in using ‘the trifecta,': Cloudflare, W3 Total Cache and Varnish in combination, set on a standard cPanel server. While these three wonders do not fix the underlying issue of a membership site under load, the results are reasonably easy to demonstrate to client (and can just as easily be turned on or off at a whim).

    Not the silver bullet either, though ‘the trifecta’ seems to have work well for some of my clients.
    Not everyone has the cash to hire a real database guru, so consider these “the poor mans option.”

    Caveat emptor. If using Wishlist Membership plugin remove W3 Total Cache from the equation (lesson learned…).

  • http://dakine.co.nz Mark

    I think it’s pretty fair to say if you’re charging a decent amount for membership you should be looking at getting a developer in to make the situation more ideal. To me (a WP plugin dev) it seems rather stupid to have something that produces a profit and not use a portion of said profit to improve the system.

    My 2 cents (again, as a dev) would be to look towards a more AJAX type approaches, where certain aspects of the interface can be handled better with caching (and specific AJAX query handling can be optimized to a tee), while using WP as a foundation but leveraging some front-end tech even to the point of a JS MVC framework. I say this as I see the main issues with my larger client sites being the server sending unnecessary bits of data, if you only need to retrieve one piece of data then why run through an entire list of queries and hook calls… ouch

    The problem lies with the low-end sites that are monitized poorly, they’re always going to struggle.

  • Pingback: Tips Tuesday – Release of BackupBuddy, Twitter API, MailChimp, and G+ Plugins - BlogAid

  • Pingback: Membership sites: Do we need new metrics?

  • Pingback: Managing a High Performance WordPress Membershi...

  • https://www.facebook.com/jlejuwaan Jordan Lejuwaan

    Hey Chris, do you know of any updates to this issue? I run a massive Buddypress website and am looking for any solutions to solve server bogdown. That includes any references to amazing optimization developers you may know. Thanks for the great article!