# Speed Up Membership & LMS Sites — xSpeed Cache

> Logged-in users are the hard case: personalised pages defeat naive full-page caching exactly where your paying customers live. xSpeed Cache splits the problem — static speed for the public side, object-cache speed for the member side, and precise rules to draw the line.

Page: https://xspeedcache.com/use-cases/membership-lms/

## The problems

- **Caching stops where members start** — Most cache plugins simply bypass logged-in users, so the people paying you get the slowest version of the site.
- **Course and community pages hammer the database** — Progress tracking, access checks, and activity feeds mean hundreds of queries per page — every page, every member.
- **Idle dashboards drain the server** — The WordPress heartbeat polls constantly from every open tab. A few hundred members with the dashboard open is a constant background load.

## How xSpeed Cache handles logged-in speed

- **Redis / Memcached object cache** — The workhorse for logged-in pages: repeated queries for access checks, course progress, and member data come from memory instead of the database. Guide: https://xspeedcache.com/docs/object-cache-redis-memcached
- **Cookie & URL cache exclusions** — Draw a precise line between the cached public site and dynamic member areas — by login cookie, URL pattern, or both. Guide: https://xspeedcache.com/docs/excluding-pages-urls-and-cookies
- **Per-post cache rules** — Override caching per page: sales pages fully cached, the member dashboard never, a semi-private page with a custom TTL. Guide: https://xspeedcache.com/docs/per-post-cache-rules
- **REST API cache** — LMS and community plugins lean on the REST API for feeds and progress data. Caching those responses removes a hidden source of load. Guide: https://xspeedcache.com/docs/rest-api-cache
- **Heartbeat control** — Slow or stop WordPress’s background polling where it isn’t needed — hundreds of idle member tabs stop taxing the server. Guide: https://xspeedcache.com/docs/controlling-the-wordpress-heartbeat
- **Custom cache rules** (Pro) — Full rule-level control for the odd cases every membership site has — bypass by user agent, query string, or your own logic. Guide: https://xspeedcache.com/docs/custom-cache-rules

## 6 ways people put xSpeed to work

### Fix the 8pm course-area crawl (Course creators)

Every evening, every member hits the same lessons at once — and every page runs the same access checks against the database.

- When: Member pages degrade at predictable peak hours while the public site stays fine.
- Setup: Connect Redis or Memcached; repeated access and progress queries come from memory, and peak hour stops stacking up.

### Keep the sales side instant (Course creators)

The pages that sell the course deserve full static speed — being a membership site is no excuse.

- When: Landing, pricing, and curriculum pages are public.
- Setup: Full-page cache for everything outside the login; cookie-based exclusions draw the exact line where members begin.

### Stop the feed from hammering the API (Community managers)

Activity feeds and progress widgets poll the REST API constantly — invisible load that scales with logged-in users.

- When: Server load is high even when page views look modest.
- Setup: REST API cache serves those repeated plugin requests from cache instead of rebuilding them per poll.

### Quiet a thousand idle tabs (Community managers)

Members leave the dashboard open all day; WordPress’s heartbeat polls from every tab, forever.

- When: Concurrent logged-in sessions are high relative to actual activity.
- Setup: Heartbeat control slows or stops background polling where it is not needed — idle tabs stop taxing the server.

### Cache the odd pages correctly (Site owners)

Every membership site has them: the semi-private page, the affiliate link with a query string, the page that must never cache.

- When: The default rules almost fit, but not quite.
- Setup: Per-post cache rules and custom rules override behavior page by page — fully cached, never cached, or a custom TTL.

### Prove no member ever sees another’s page (Site owners)

One cached “My Account” page served to the wrong person is a trust catastrophe.

- When: Before launch, and any time caching config changes.
- Setup: Cookie-based exclusions keep personalised pages out of the page cache by design; the object cache stores query results, never rendered personal pages.

## Copy-paste AI prompts

Connect via xSpeed MCP (https://xspeedcache.com/docs/mcp-server-setup) or xSpeed Hub, then paste:

### The logged-in speed fix

```
My members say the site is slow after login. Using xSpeed, connect and test the Redis or Memcached object cache, enable REST API caching, and set heartbeat control to a sane interval. Show me the queries-per-page before and after.
```

### Draw the caching line

```
Using xSpeed, fully cache my public pages, exclude everything behind login by cookie, and set per-post rules so the sales and curriculum pages are cached but the member dashboard never is. List the exclusion rules you applied so I can review them.
```

### The peak-hours check

```
Using xSpeed, check my current cache hit rate and object cache status, and tell me whether the site is ready for 500 members online at once — and if not, exactly what to change.
```

## Industry stories

- [Online course creators](https://xspeedcache.com/use-cases/for/course-creators/) — Launch day fills the classroom. Keep the lights on.
- [Communities & forums](https://xspeedcache.com/use-cases/for/communities/) — A busy community is the goal — and the load.
- [Recruitment & staffing](https://xspeedcache.com/use-cases/for/recruitment-agencies/) — Filtered job searches are the query that hurts the most.
- [Job boards & directories](https://xspeedcache.com/use-cases/for/job-boards/) — A directory is a search engine wearing a theme.

## FAQ

### Can members ever see another member’s cached page?

No. Logged-in and personalised pages are excluded from the full-page cache by cookie-based rules; they are accelerated with the object cache instead, which caches database query results — not rendered personal pages.

### What speeds up pages that cannot be page-cached?

The object cache. Redis or Memcached keeps repeated query results in memory, cutting database work per page from hundreds of queries to a handful — that is the difference members actually feel.

### Does this work with LMS and membership plugins?

Yes. The pattern — full-page cache for public pages, object cache plus exclusions for member areas, REST API caching for plugin data traffic — applies to LMS, membership, and community stacks generally, and the rules are fully configurable per site.

### Why does my site slow down when many members are online?

Usually concurrent database load: every member page runs access checks and progress queries, and idle dashboards keep polling via the heartbeat. Object caching absorbs the queries and heartbeat control stops the idle polling.

## More

- [All use cases](https://xspeedcache.com/use-cases/index.md)
- [Pricing](https://xspeedcache.com/pricing/index.md)
- [Free plugin](https://wordpress.org/plugins/xspeed/)