Most WordPress speed advice was written for content sites. Blogs, marketing pages, brochure sites — places where the same HTML is served to every visitor and a page cache turns the homepage into a 50 ms request. That advice is correct for those sites.
On a membership site or an LMS, almost none of it applies. The customer dashboard, the course progress page, the quiz submission endpoint, the member-only article — all of these are served to logged-in users, and every serious page cache backs off the moment it sees a logged-in cookie. WP Rocket bypasses cache for logged-in users by default. Cloudflare's "Cache Everything" rule excludes them. LiteSpeed Cache puts them in a separate cache group that mostly stays empty. The 90% cache hit rate you'd get on a blog drops to 20–40% on a membership site, and the 60% that misses is the high-leverage 60% — the part your subscribers actually use.
So the plugin stack changes. The plugins that earned their place on the main WordPress speed plugin ranking by being good at page caching slide down the priority list. Object cache, asset management, and structural plugin loading slide up. Honest disclosure I always include: I make AcceleratorWP, a structural plugin that belongs in the structural-loading category I'll cover at the end. The rest of this post stands alone.
Why membership / LMS sites are slow, specifically
The mechanism, in one paragraph: when a visitor logs in, WordPress sets a wordpress_logged_in_* cookie. Every cache plugin and every edge cache detects that cookie and refuses to serve cached HTML — instead it falls through to a live WordPress boot. On a brochure site that's irrelevant because almost nobody logs in. On a LearnDash site where the student logs in to view their course list, that's 80% of meaningful traffic going to origin.
Three measurable consequences on real sites:
- Course dashboard TTFB 1,400–2,200 ms on plugin-heavy installs, because every plugin's main file loads on every dashboard request.
- Quiz submission AJAX 800–1,800 ms per submission, because admin-ajax requests pay the full boot cost too.
- Course content navigation feels sluggish — every "next lesson" click is a fresh WordPress boot, not a cache hit.
The plugins below address what page caching can't reach. The edge caching post covers the broader pattern; this post is the membership-specific version of the same conversation.
How I'm ranking these
Same three criteria as the main speed plugin ranking, with one membership-specific adjustment:
- Did it move logged-in TTFB? Not cached-page TTFB. Logged-in dashboard TTFB measured over real traffic for a week.
- Did it stay out of the way of the membership / LMS plugin's own functionality? Drip content, quiz processing, subscription renewals, course gating — none of these can be broken in exchange for speed.
- Was the configuration time worth it on a member site specifically? Different stack, different priorities.
1. Object Cache Pro — the single biggest win for member sites
If you install one plugin from this list, install Object Cache Pro. On every WordPress request, wp_options is queried 50–150 times. Post meta is queried for every member's enrolled course. User meta for every dashboard render. Without object cache, every one of those queries hits MySQL. With persistent object cache backed by Redis, the second hit onward is served from RAM in microseconds.
On a LearnDash client I work with (1,200 active students, 40 active plugins, EU-based), Object Cache Pro reduced the course dashboard query count from 312 to 78 per page load, and TTFB from 1,840 ms to 920 ms. That's before any structural fix. Just from caching the queries that were already running.
Pricing is $95/year single-site. Requires Redis or Memcached on your host (most managed WP hosts include it; on a VPS you'll need to install it yourself). The free Redis Object Cache plugin is the budget alternative — it does the same job with less polish on the cache hit ratio.
Use it when: any membership or LMS site with Redis or Memcached available on your host.
Skip it when: you don't have a persistent cache backend installed — install Redis first, then this. Shared hosts without Redis: see the free Redis Object Cache below, or skip the category.
2. Redis Object Cache (free) — the budget version of #1
The free Redis Object Cache by Till Krüss does the same fundamental job as Object Cache Pro — connect WordPress's object cache to a Redis backend. It's free, the configuration is one Redis URL plus a save, and the basic functionality works fine.
What you give up by not paying for Pro: more sophisticated cache hit ratio under high concurrency (Pro has igbinary serialization and connection pooling tuned for this), better admin UI, support response time, and finer-grained per-group cache control. On a 100-student LMS site, the free version is fine. On a 5,000+ student site with concurrent quiz submissions, Pro materially outperforms.
Use it when: budget is genuinely zero, you have Redis available, and the site is moderate-traffic.
Skip it when: Object Cache Pro fits the budget (the gain in cache hit ratio usually justifies it on serious sites).
3. LiteSpeed Cache — the only cache plugin with a private cache for logged-in users
LiteSpeed Cache is unusual on this list because it actually does something useful for logged-in users. Most cache plugins (WP Rocket, WP Super Cache, etc.) bypass cache entirely for any visitor with a wordpress_logged_in_* cookie. LiteSpeed Cache instead maintains a private per-user cache — pages a logged-in member visits are cached for that member specifically, so revisits hit the cache instead of triggering a full boot.
The caveat: this only works on LiteSpeed-based hosts (NameHero, SiteGround, A2 Hosting, Hostinger, ChemiCloud) where the cache is served by the web server rather than PHP. On Apache or NGINX without LiteSpeed, the private cache feature falls back to PHP-based logic that's slower than just skipping the cache.
ESI (Edge Side Includes) is the other LiteSpeed-only feature worth knowing about — it lets you cache the page shell while leaving the cart icon or "logged in as" header fragment dynamic. Genuinely useful on member sites with personalised navigation.
Use it when: your host runs LiteSpeed and you have logged-in users you want to cache without breaking personalisation.
Skip it when: your host runs anything else. The fallback isn't worth it.
4. WP Rocket — useful for the public marketing pages
WP Rocket is on this list because membership / LMS sites still have public pages — the landing page, the pricing page, the sales funnel, the blog if you have one. WP Rocket caches those well, and the time you save on guest visitors finding your site is real even if 80% of meaningful traffic is logged-in members.
What it explicitly does not do on a member site: help your authenticated traffic. Don't expect the dashboard or course pages to get faster from installing it. Set realistic expectations.
The WP Rocket alternatives post covers cheaper options if budget is a constraint — on a member site where the cache plugin only handles 20% of meaningful traffic, the $59/year investment is harder to justify than on a content site.
Use it when: you have public marketing pages that matter for acquisition and you have budget.
Skip it when: the site is 100% behind a login wall (no public sales funnel) — the gain is too narrow to pay for.
5. Perfmatters — strip unused assets from member-facing pages
Perfmatters' script manager is the second-biggest win on a member site after object cache. The reason: member dashboards typically load every plugin's CSS and JS even when none of it is used. Yoast loading on the LearnDash course view page. WooCommerce assets on the MemberPress login. Elementor framework on a Gutenberg-built profile page. None of it renders anything; all of it ships bytes.
On a MemberPress site I optimised last year, Perfmatters reduced the dashboard's cumulative CSS from 384 KB to 142 KB per page by disabling assets that weren't doing anything on member-facing URLs. The course pages got the LearnDash-specific assets only; the membership pages got the MemberPress assets only; the shared dashboard shell got both. The TTFB win was modest; the LCP and Speed Index improvements were real.
Pricing around $25/year. The page-builder-specific post covers the script manager case in more detail; everything there applies to member sites with the addition that dashboard pages tend to be the worst offenders.
Use it when: any member or LMS site with 15+ active plugins (which is most of them).
Skip it when: you have fewer than 10 plugins active and assets aren't the bottleneck.
6. W3 Total Cache — for sites that need granular object cache configuration
W3TC is the configurable old-timer of cache plugins. On a content site it's overkill; on a member site with specific infrastructure to wire into, it's the plugin that lets you wire each cache layer separately. Page cache to disk, object cache to Redis, database cache to Memcached, fragment cache for specific WordPress hooks — all configurable independently.
The UI hasn't been updated since approximately 2012 and the configuration surface is intimidating. But for an agency running a serious LearnDash deployment where the infrastructure is mature (separate Redis instance, dedicated MySQL, edge cache via CloudFront), W3TC is the plugin that lets you wire all of those layers into WordPress's cache API explicitly.
Use it when: you have specific cache infrastructure to wire into, you know what each layer does, and you don't mind the UI.
Skip it when: you'd describe yourself as a WordPress operator rather than an infrastructure engineer.
7. ShortPixel — image optimization for course content
LMS sites tend to be visual. Course thumbnails, instructor photos, lesson screenshots, slide decks rendered as images, certificate previews. Without image optimization, those add up — I've seen LearnDash sites where the cumulative course thumbnail weight on the dashboard was 4–6 MB uncompressed.
ShortPixel handles the WebP / AVIF conversion, compression at chosen quality levels, and bulk re-optimisation of existing media. The free tier handles the initial run on most LMS catalogues; paid tiers cover ongoing uploads at reasonable per-image rates.
Use it when: the LMS catalogue has dozens or hundreds of images that weren't optimised at upload time.
Skip it when: instructor workflow already exports images at correct dimensions in modern formats (rare on real sites).
8. WP-Optimize — database cleanup for sites with lots of user activity
Member sites accumulate database cruft faster than content sites. Every user adds rows to wp_usermeta. Every course progress event adds rows to LearnDash's tables. Every subscription change adds rows to MemberPress's tables. Expired transients pile up. After 2–3 years of active use, the database can be 800 MB to 2 GB.
WP-Optimize's database cleanup half handles this. The cache half is mediocre; ignore that. Run the database cleanup once a quarter as maintenance, not as part of your live stack.
Use it when: the site is 2+ years old with active user growth.
Skip it when: the site is fresh — nothing accumulated yet.
What's not on this list, on purpose
Plugins that show up in similar lists but don't belong on a member site:
- NitroPack. Routes traffic through their edge CDN for cache-side optimization. Member traffic bypasses the edge entirely (logged-in cookies aren't cached). NitroPack does nothing useful for the 80% of member-site traffic that matters, and the pageview-based pricing punishes growth. The NitroPack vs WP Rocket comparison covers the trade-off.
- WP Super Cache, Cache Enabler. Page-cache-only plugins. Same problem as NitroPack — they help guest pages, do nothing for member dashboards.
- Hummingbird, generic "all-in-one" speed plugins. Cover the cache half adequately, ignore the structural and object-cache half that matters more on member sites.
The pattern: anything that's primarily a page cache adds value to the public-pages 20%, nothing to the member-area 80%.
Stack recommendations by setup
The combinations that work for the most common member-site stacks:
- LearnDash on standard WordPress (with public marketing pages): Object Cache Pro + WP Rocket + Perfmatters + ShortPixel. Plus structural (see below). LearnDash's own performance settings (Settings → LearnDash LMS → Advanced) include a "Disable Course Statistics" toggle worth enabling on sites where the front-end stats widget isn't used.
- MemberPress on a behind-the-wall site: Object Cache Pro + Perfmatters. Skip WP Rocket — there's no public traffic to cache. Add the structural layer.
- LifterLMS standalone: Object Cache Pro + WP Rocket + Perfmatters + ShortPixel. LifterLMS is the heaviest of the major LMS plugins on memory; object cache matters most here.
- BuddyBoss / BuddyPress community: Object Cache Pro is essential (community sites generate huge volumes of user-meta queries). Skip aggressive asset optimization — BuddyBoss's frontend is fragile.
- WooCommerce Subscriptions + Memberships (recurring subscription site): All of the above plus the WooCommerce-specific stack. And read the WooCommerce slow checkout post — Subscriptions adds its own footguns.
A note on the recent LearnDash news: as of May 2026, LearnDash's parent company StellarWP folded the LearnDash brand into Liquid Web's main hosting domain. Plugin development is continuing, but the performance characteristics may shift over the next several releases as the integration settles. The advice above holds against current stable versions.
The ninth category — structural plugin loading
Every plugin above operates on cache, database, assets, or images. None of them stop WordPress from loading every active plugin's PHP on every member dashboard request. Your SEO plugin loads on the course page. Your social-share plugin loads on the quiz submission. Your booking calendar plugin loads on the certificate generator. None of those plugins do anything on those URLs; all of them pay the boot cost.
The structural category — survey of cache-free performance methods covers it in depth — addresses this at the mu-plugin layer. WordPress's plugin loader runs after mu-plugins, so an mu-plugin can intercept option_active_plugins and remove plugins from the active list for specific request classes before they're loaded at all.
I make AcceleratorWP, which sits in this category. On a member site, the relevant intervention is per-request-class skipping: your SEO plugin shouldn't load on the LearnDash quiz AJAX call, your form plugin shouldn't load on the MemberPress account page, your slider plugin shouldn't load anywhere a logged-in member actually visits. The Plugin Skipper module is the implementation; Hook Pruner handles the cases where a plugin must stay loaded but its irrelevant hooks should be removed.
On the LearnDash client I mentioned earlier (1,200 active students, 40 plugins), applying the structural layer on top of Object Cache Pro and the rest of this stack: the course dashboard TTFB went from 920 ms (after object cache) to 410 ms; quiz submission AJAX from 1,420 ms to 380 ms. Same hosting, same plugin list — just 28 of the 40 plugins skipped on logged-in member URLs because they had no functional role there.
If you've configured all of the above and your dashboard / quiz / course pages are still slow, the structural layer is what's left. The edge caching post covers the broader argument for why this layer exists.
If you've optimised a LearnDash, MemberPress, or LifterLMS site and got different results than what I described above, I'd genuinely like to hear about it. Send notes to my inbox. I update the rankings as the LMS ecosystem shifts (and it's shifting fast in 2026).