0

I develop wordpress membership sites and I never enable any caching plugin on those sites.

I presume, if I enable caching then members might have some issues due to cache or there might be an issue during checkout process.

I have never tried this though:

The membership plugins I use are: Wishlist Members, Digital Access Pass (DAP), OptimizeMember

Similarly cache plugins are: Wp Super Cache, WP Total Cache

I need expert advice on this matter.

Whether should I enable cache or not?

Please share your thoughts.

Thanks Abu

2

Source: Chris Lima - Managing a High Performance WordPress Membership Site


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.

Most sites 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 (like menus, sidebar widgets, content..etc) that needs to be current. So full page caching isn’t a solution – from a plugin or hosting provider.

Instead, what you need is part of page caching.

1. Part of page caching: 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. 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.

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

2. Fragment caching: You can use a little class created by Mark Jaquith. He calls it fragment caching, but it’s not different 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.

So finally there is one option that you need to try cache only database do not catch page data, browser data. I do not proposed to use W3 Total Cache but check it once this plugin may be your solution.

0

@absikandar In this article I explain how I cache logged in user pages on my membership sites: http://s2member.net/how-to-cache-your-membership-site-225

A better approach would be to cache separate copies of the page, unique for each logged in user. A member would not benefit from the cache someone else caused, but he'd still benefit from it when visiting the same page again.

I hope that helps! :)

  • That doesn't make much sense. Cache expires at some point and registered users is not always on the site to actually benefit from this kind of caching as the cache will most likely expire between sessions. So you end up wasting CPU time to generate a cached version which will never be used. – Mark Kaplun Oct 10 '15 at 6:34
  • It is true that it won't be as used as the cache for visitors, which many benefit from, but it's better for the logged in user than no cache at all. There are some pages that he will visit repeatedly, that will now be cached from his previous hit. The CPU use is practically the same as just serving the page, so it's not really much more expensive, and sometimes he'll get the cached copy so that'll save CPU too. It will use more disk space, though. – Cristián Lávaque Oct 10 '15 at 16:50
  • It will make logged in users sessions slower as there is a cost to generating the cache and it impacts the performance. If you think that it doesn't impact performance then you don't understand the cost to the extra writings to the disk. It is true that the cost is much smaller then access to the DB but generating so many pages and deleting them every hour accumulates in the end and impacts your hard drive performance which impact the serving of not only the HTML but also the serving of JS, CSS and image files. – Mark Kaplun Oct 10 '15 at 16:57
  • I see your point, but disk I/O with an SSD is negligible. Or if you're writing the cache to memory instead of to a disk: zencache.com/kb-article/… In either case, disk I/O for some sites (even if you use a regular drive) is going to be worth it in many cases. However, I do agree that care should be taken, and one should not just enable user caching without considering the resource that such a thing will consume. :) – Cristián Lávaque Oct 11 '15 at 17:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.