Performance and Cache Issues

Problems that show up as a community grows: slow lists, stale-looking data, and rate limits that seem not to work.

The feed, member directory, or notification counts feel slow as the community grows

Symptom: Pages that were fast with a few hundred members get noticeably slower as membership climbs into the thousands.

Likely cause: There is no persistent object cache installed. Without one, wp_cache_* values are request-local - they’re computed, used once, and thrown away, so the same expensive lookups (unread counts, the member directory, the first page of the feed) are recomputed on every single request instead of being reused.

Fix:

1. Check whether you have one: BuddyNext > Platform > Tools > Object cache reports the status directly (and will warn you past a few thousand members if one is missing); or check Tools > Site Health > Info > Caching in wp-admin; or run wp eval 'var_dump( wp_using_ext_object_cache() );' - true means you have one, false means you don’t.
2. Install a persistent object cache: Redis Object Cache if your host offers Redis (the common choice), Memcached if your host offers that instead, SQLite Object Cache if your host offers neither (still a real improvement over nothing), or APCu only on a genuine single-server setup.

This is a recommendation, not a strict requirement - BuddyNext works without one, it’s just slower, and the gap widens with member count. See Object Cache at Scale.

Rate limits (comment flooding, sign-up throttling) don’t seem to be working

Symptom: A member seems to be able to post far more comments per minute, or create far more accounts per hour, than the configured limit allows.

Likely cause: The limits do not need a persistent object cache. BuddyNext counts posts from the database, and counts comments and sign-ups in a database table when no object cache is present. The usual causes are a switch that is off, an exempt account, or a shared IP address.

Fix:

1. Open BuddyNext > Moderation > Controls > Content safeguards and check that Rate-limit posting and Rate-limit commenting are ticked, with the numbers you expect. Unticked means no limit.
2. Test as an ordinary member. Administrators and moderators are exempt from the post limit.
3. For sign-ups, open BuddyNext > Members > Registration & Login > Spam & Abuse Protection and check Rate-limit sign-ups per IP (default 5 per hour).
4. The sign-up limit counts per IP address. If your site sits behind a proxy or CDN that hides visitors’ real addresses, everyone can look like one IP address, so the limit trips too early or not at all. A developer can map the real address with the buddynext_client_ip filter.

See Content Safeguards.

The notification bell or “new posts” pill is slow to update

Symptom: A member has to wait, or manually reload, to see a new notification or a new post appear.

Explanation, not a bug (on Free): The free plugin uses polling, not a live push connection. The notification bell checks every 30 seconds while idle (5 seconds for the first minute after the member takes an action), and the feed checks for new posts every 60 seconds. A delay within those windows is expected behavior, not a fault.

Fix, if instant delivery matters: BuddyNext Pro’s Real-time WebSocket feature replaces polling with a live connection (via a Pusher-compatible server such as Sockudo) so notifications, feed activity, reactions, comments, and messages update the instant they happen. If Pro’s realtime is enabled but still feels like polling, use the Test connection button on the Realtime settings tab to confirm the Host, App ID, Key, and Secret are correct and the server is reachable - when the server is unreachable, BuddyNext quietly falls back to polling with no error shown to members.

See Near-Real-Time Updates and Real-time WebSocket.

A companion plugin (SEO tool, page builder, forms plugin) slows down community pages specifically

Symptom: A plugin unrelated to the community loads and adds overhead specifically on the feed, spaces, or profile pages, even though it does nothing there.

Fix: Use Plugin Isolation (BuddyNext > Platform > Plugin isolation) to skip that plugin on community routes only - it is off by default and, once turned on, keeps every plugin loading until you explicitly tick one to skip, so nothing is silently disabled. This is a performance tool, not a security boundary, and it changes nothing on the rest of the site. See Plugin Isolation.

Data still looks stale after switching Include in search off and back on for an integration

Symptom: Turning a companion integration’s “Include in search” switch (under BuddyNext > Integration Settings) back on doesn’t seem to bring old content back into search immediately.

Explanation, not a bug: Switching search off for an integration removes the content already in the search index, not just new content - that’s deliberate, so a search switch that left old results behind wouldn’t actually work as “off.” Switching it back on re-indexes content as it is created or updated going forward, not instantly in bulk. If you need existing content re-indexed immediately after re-enabling search, use Rebuild search index under BuddyNext > Platform > Tools, or wait for members to naturally interact with (update) that content.

See Integrations Overview.

A member sees an old page, or onboarding goes back to step 1, with a caching plugin on

Symptom: In onboarding, pressing Continue after choosing interests lands the member back on step 1 (Skip still works). Or a logged-in member sees a feed, inbox or notification count that does not change until they clear their browser.

Likely cause: A page-cache plugin (LiteSpeed Cache, WP Rocket, W3 Total Cache, WP Super Cache and similar) is set to cache pages for logged-in users, and the site runs BuddyNext 1.2.1 or earlier. The member is served a stored copy of their own earlier page.

Fix:

1. Update to BuddyNext 1.2.2 or later. It marks every page a logged-in member sees as uncacheable, so no exclusion list is needed.
2. Purge all caches (page cache, and any CDN) after updating.
3. If you cannot update yet, turn off your cache’s “cache logged-in users” option, or exclude your onboarding page (by default /onboarding/).

See Page Cache and Optimisation Plugins for what was tested and where each plugin keeps these settings.

Related

• Object Cache at Scale
• Page Cache and Optimisation Plugins
• Plugin Isolation
• Near-Real-Time Updates
• Real-time WebSocket (Pro)