Instant Message Delivery
The WebSocket version delivers messages instantly to all recipients using a persistent WebSocket connection. Unlike AJAX polling (which checks every 3-10 seconds), WebSocket maintains a live connection — messages appear the moment they're sent, with sub-200 ms latency. Up to 200x faster than AJAX mode.
Instant delivery is the headline benefit of the WebSocket version. Other features (typing indicator, presence, web push, voice/video) all depend on the persistent connection.
What it adds#
- Instant message delivery — sub-200 ms latency (vs 1-10 seconds on AJAX)
- Persistent WebSocket connection maintained in the background
- Single shared connection across all browser tabs (via SharedWorker)
- Automatic reconnection after network interruptions
- Works on all modern browsers supporting WebSocket
- No additional setup beyond enabling the WebSocket mechanism
How it works#
When a user opens a page with the messenger, the browser establishes a single WebSocket connection to the cloud relay. SharedWorker shares this connection across multiple tabs of the same site — so a user with 5 tabs open uses just 1 connection.
When someone sends a message:
- Browser → your WordPress server: save the message (your server stores it)
- Your server → cloud relay: push the encrypted event
- Cloud relay → all participants' open connections: deliver the event
- Participants' browsers: render the message immediately
End-to-end latency from sender → recipient is typically under 200 ms even across continents — meaningfully faster than what users perceive in AJAX-polling apps.
| Mode | Latency | User experience |
|---|---|---|
| AJAX polling, 3-second interval | 0–6 seconds | "I'll see your reply eventually" |
| WebSocket | < 200 ms | "Real-time conversation" |
When instant delivery matters most#
| Use case | Why instant delivery is essential |
|---|---|
| Live customer support | Visitors expect chat-app speed; AJAX feels broken |
| Marketplace buyer-vendor messaging | Pre-purchase questions need instant answers |
| Dating community | Lag breaks the flow of natural conversation |
| LMS office hours | Students and instructors need real-time back-and-forth |
| Public chat rooms | Many participants — polling at scale becomes server-heavy |
| Mobile-app users | Battery-sensitive: polling drains battery much faster |
How to enable#
- Purchase and activate the WebSocket version license
- Navigate to WP Admin → Better Messages → Settings → General
- Set Mechanism to WebSocket
Frequently asked questions#
What happens during a brief network drop?#
The connection auto-reconnects when network returns. Messages sent during the drop are queued and delivered on reconnect. No data is lost.
Does the SharedWorker work in all browsers?#
SharedWorker is supported in Chrome, Firefox, Edge, and most modern browsers. Safari supports SharedWorker too (since version 16). For older browsers without SharedWorker support, the plugin falls back to a per-tab WebSocket — slightly more connections but same functionality.
How does delivery work for users not currently on the site?#
- Tab open: instant via WebSocket
- Tab closed but browser open: instant via web push (if enabled)
- Browser closed: web push notification appears when the OS allows
- Offline entirely: email notification fires after a delay
Does instant delivery work on mobile?#
Yes — the same WebSocket connection runs on mobile browsers. The native mobile app also uses WebSocket for instant delivery.
Is there a way to test the latency on my site?#
Send a message between two browser tabs (one logged in as each user). On the WebSocket version, you should see the message appear on the other tab within ~200 ms. On AJAX, expect 1-6 seconds depending on polling interval.
See also#
- Real-time messaging — AJAX vs WebSocket comparison
- Load optimization — why WebSocket also reduces server load
- Typing indicator — depends on WebSocket
- Presence indicator — also WebSocket-only
- Message status — sent / delivered / seen via WebSocket