Skip to main content

Real-Time Messaging on WordPress: Beyond Page-Reload Chat

· 7 min read
Andrij Tkachenko
Creator of Better Messages

The single biggest UX gap between a WordPress messaging plugin and a serious modern messenger is delivery latency — how long it takes a sent message to appear in the recipient's window. A page-reload messenger feels like email. An AJAX-polling messenger feels like a fast email. A WebSocket-powered messenger feels like WhatsApp. Better Messages supports both shapes — AJAX polling on the free version (no separate server, runs on any WordPress hosting) and WebSocket on the paid version (instant delivery, online presence, typing indicators) — so any site can pick the right delivery mode for its scale.

Three delivery models compared​

Page reload (the old default)​

The legacy BuddyPress messages component, the bbPress private messages, and most WordPress messengers built before ~2015 work this way: the recipient clicks Refresh (or hits F5) to see new messages. Acceptable for "post a comment occasionally"; broken for actual conversation.

Not what Better Messages does. Mentioned here for context.

AJAX polling​

The browser asks the server every few seconds "any new messages?" If yes, render them inline. If no, wait a few seconds and ask again. No page reloads, no server-push infrastructure, no separate Node.js process — just standard WordPress REST endpoints.

This is what the free version of Better Messages uses. Trade-offs:

  • Pros: Runs on any WordPress hosting. No extra infrastructure. No license needed. Standard PHP / MySQL stack.
  • Cons: Polling delay (typically 3–10 seconds depending on configuration). Server load scales with open tabs (each tab polls independently).

For sites under a few hundred actively-chatting members, AJAX polling is sufficient. The messenger feels responsive even if not instant.

WebSocket push​

A persistent TCP connection between the browser and a WebSocket server. When a message lands at the server, it pushes the message to every connected recipient instantly — no polling, no waiting. The same connection carries typing indicators, online presence, read receipts, and call-signaling events.

This is what the WebSocket version of Better Messages uses. Trade-offs:

  • Pros: Instant delivery. Online presence is cheap. Typing indicators work. Voice / video call signaling works (calls need a WebSocket layer). Server load is constant per connected user, regardless of how often they poll.
  • Cons: Requires a WebSocket server. Better Messages includes the hosted WebSocket cloud with the license, so you do not run your own.

Why WordPress hosting cannot just "do WebSockets"​

Standard WordPress hosting runs PHP-FPM behind nginx / Apache. PHP-FPM is request-response: each HTTP request gets a worker, the worker runs PHP, the worker returns the response, the worker is freed. There is no persistent connection. WebSocket connections must stay open for the duration of the user session — minutes to hours.

To run WebSockets natively on your origin, you would need:

  • A Node.js or Go process (or similar) holding open connections
  • A way to route WebSocket-upgrade HTTP requests to that process
  • Memory budget for tens of thousands of open file descriptors at scale
  • Operational tooling for restarts, deployments, monitoring

Most managed WordPress hosts (WP Engine, Kinsta, SiteGround, etc.) do not provide this. Better Messages solves it by running the WebSocket layer on Better Messages' own cloud — your WordPress site talks to it via HTTPS, your members talk to it via WebSocket, no extra infrastructure on your end.

What the cloud relay does (and doesn't do)​

The WebSocket relay at cloud.better-messages.com:

  • Routes events between connected participants of a thread (message-sent, typing, presence, call-signaling)
  • Is blind to message content — encrypted transit, no storage, no inspection
  • Does not store any message data — message persistence lives in your WordPress database

The relay is a routing layer, not a storage layer. Even on the WebSocket version, all message data lives in your WordPress database. See GDPR-compliant WordPress messaging for the full data-flow picture.

Picking the right mode for your site​

Site stageRecommended mode
Brand-new community, < 100 membersFree version (AJAX polling) — install, try it, see how members engage
Active community, members chatting dailyWebSocket version — polling delay starts showing
Marketplace where vendors compete on response timeWebSocket version — instant delivery is a competitive feature
LMS / paid courses with cohort discussionsWebSocket version — group calls + web push are essential
Customer-support widget on a single landing pageFree version — low concurrency, polling fine
Anything needing voice / video callsWebSocket version — calls require the relay
Anything needing end-to-end encryptionWebSocket version — E2E is a WebSocket-version-only feature

How it feels in practice​

A side-by-side comparison of the same interaction:

  • AJAX polling: User A types "Hi", hits send. User B's browser, on its next 5-second poll, fetches the message and shows it.
  • WebSocket: User A types "Hi", hits send. The message reaches the server, the server pushes it through the WebSocket to User B's browser instantly. User B sees "Hi" within ~50ms.

For 1:1 conversation, the difference is noticeable but tolerable on AJAX. For group chats where 5 people are typing simultaneously, the WebSocket experience feels qualitatively different — like Slack vs like email.

Installing Better Messages​

Both modes use the same plugin. The mode is determined by whether you activate the WebSocket license:

  1. Install Better Messages from WordPress.org — this is the free (AJAX) mode.
  2. (Optional) Buy a WebSocket license from your Better Messages account dashboard and activate it under Better Messages → Account — this switches to WebSocket mode.

No reinstall, no separate plugin, no migration. The mode is a license-activation flip.

Frequently asked questions​

Will my site's hosting work for the WebSocket version?​

Yes — the WebSocket server is hosted by Better Messages, not on your origin. Your WordPress site only needs to make outbound HTTPS calls to cloud.better-messages.com (standard outbound HTTPS works on every WordPress host).

What about firewalls that block outbound HTTPS?​

The WebSocket version needs outbound HTTPS to the BM cloud and inbound callbacks on the standard /wp-json/ REST path. Both work on standard WordPress configurations. Aggressive WAFs (Wordfence, Sucuri) may need callback URLs whitelisted — the plugin includes a Test Callback button to verify.

Can I host the WebSocket layer myself?​

Yes — the self-hosted plan lets you run the WebSocket server on your own infrastructure. Useful for sites with strict data-sovereignty rules. Talk to support about the deployment.

Does AJAX polling work on every browser?​

Yes — AJAX polling uses standard fetch / XMLHttpRequest, supported on every browser since 2010. The WebSocket version uses native WebSocket API, supported since 2012. Both modes work on every modern browser.

What is the typical polling interval on the free version?​

Configurable, default ~5 seconds. Faster polling means lower latency at the cost of higher server load. Most sites leave it at the default.

What happens if the WebSocket connection drops?​

The client auto-reconnects with exponential backoff. While reconnecting, the messenger falls back to AJAX polling so messages still arrive. Once the WebSocket reconnects, real-time delivery resumes.

See also​

Install Better Messages from WordPress.org →