Skip to main content

Continuous Fallback Mode

Continuous Fallback Mode is disabled by default, and we recommend keeping it disabled. This page explains what it does, why the default is what it is, and the rare situations where enabling it is the right call.

WebSocket version

This setting exists in the WebSocket version 2.15.24 and newer, and is visible only when the Realtime Update Mechanism is set to WebSocket. On the free version AJAX polling is the primary transport and is not affected by this setting.

What happens by default#

The WebSocket version delivers messages through a persistent connection opened directly from the visitor's browser to our cloud. Your WordPress server is not involved in real-time delivery at all — that is the core of the load reduction the WebSocket version provides.

When a visitor's browser cannot establish that connection, it does not silently lose messages. By default it makes a single synchronization request per page load, which fetches everything the visitor may have missed. Sending messages, opening conversations, and loading history all keep working normally — every one of those actions synchronizes the conversation state. The only thing such a visitor does not get is live background delivery: a new message will not pop up on its own while they sit on a page, it arrives on their next page load or interaction.

For the overwhelming majority of sites this is the correct trade. Failed connections are almost always transient — a laptop waking from sleep, a network hiccup, a slow page load — and the browser connects successfully a moment later.

What Continuous Fallback Mode changes#

With Continuous Fallback Mode enabled, a visitor whose WebSocket connection cannot be established falls back to continuous AJAX polling against your WordPress server: one request every few seconds while a conversation is open, continuously, for as long as they stay on your site.

This restores live background delivery for those visitors — at a significant cost:

  • Every polling request is a full WordPress request: PHP boots, plugins load, the database is queried.
  • One affected visitor with an open conversation generates over 1,000 requests per hour.
  • On shared hosting, a few dozen simultaneously affected visitors can exhaust the PHP worker pool, producing 503 errors for your entire site — including visitors who have nothing to do with chat.

This is why Continuous Fallback Mode is not recommended: it converts a degradation affecting a few visitors into a load problem affecting everyone.

When you actually need it#

There is one situation where enabling it is justified: when a significant share of your audience is behind networks that systematically block WebSocket connections, so the failure is not transient — those visitors can never connect, no matter how many times their browser retries.

In practice this means:

  • Country-level internet filtering. National firewalls in some countries interfere with WebSocket traffic to foreign servers. Russia and Iran are the most common examples in our support reports — sites whose audience is primarily in these countries may find that a large portion of visitors cannot establish the connection at all.
  • Strict corporate or institutional networks. Some proxies and security appliances strip the WebSocket upgrade from HTTPS connections. If your site serves a closed audience on such a network (an intranet community, a university network), the same logic applies.

If that describes your audience, you have two options — and one of them is strictly better.

The better fix: Self-Hosted WebSocket server#

For audiences behind country-level filtering, consider the WebSocket Self-Hosted plan before reaching for this setting. It runs the WebSocket relay on your own server instead of our cloud — and since your visitors can already reach your server (they are browsing your site on it), a national firewall that blocks foreign cloud endpoints does not affect a relay hosted alongside your site or in your region.

The result is fundamentally better than any fallback: your audience keeps true real-time delivery — instant messages, presence, and typing indicators — with none of the polling load this page warns about. If chat is a core part of your site and most of your users are in an affected country, self-hosting is the solution built for exactly this situation.

The simple workaround: Continuous Fallback Mode#

When self-hosting is not practical — no dedicated server, a small audience in affected regions, or chat is a minor feature — Continuous Fallback Mode is the one-toggle alternative: affected visitors get continuous delivery over AJAX, and the server load is a price you are choosing deliberately.

How to check whether your visitors are affected#

Ask an affected visitor (or test from the affected network) to open the browser console (F12 → Console) on a page of your site while logged in:

  • Connected to WebSocket messaging server — the connection works, Continuous Fallback Mode would change nothing for this visitor.
  • Error while connecting to WebSocket messaging server repeating without an eventual Connected line — this visitor genuinely cannot connect.

A single error followed by a successful connection is the normal transient case, not a reason to enable this setting.

Enabling it#

  1. Go to Better Messages → Settings → General.
  2. In the Realtime Update Mechanism section, enable Continuous Fallback Mode.
  3. Two additional settings appear: Conversation Refresh Interval and Site-Wide Refresh Interval. These control how often affected visitors poll your server. If your server is modest, raise them — for example 10 and 30 seconds — to soften the load while keeping delivery reasonably fresh.

The change takes effect immediately for new page loads, no rebuild or cache purge required.

info

Before version 2.15.24 the WebSocket version behaved as if Continuous Fallback Mode were always enabled. If your site relied on that behavior, enabling the setting restores it exactly.