Load Optimization
The WebSocket version dramatically reduces server load by replacing AJAX polling with a persistent WebSocket connection. Where the free version's polling generates dozens of requests per minute per active user against your WordPress server, the WebSocket version generates zero request-driven load for real-time delivery.
Load reduction is one of the most underrated benefits of upgrading. Sites with 100+ concurrent users see meaningful CPU and database reduction.
What it adds#
- Eliminates repeated AJAX polling requests to your server
- One persistent connection per user instead of continuous HTTP requests
- Dramatically lower CPU and database load on your WordPress server
- Faster site performance for non-chat pages (more resources available)
- WebSocket relay handles connection management offsite — no extra infrastructure on your end
Load comparison#
| Concurrent users | AJAX (free, 3s interval) | WebSocket version |
|---|---|---|
| 10 | ~200 requests/min to your server | 0 polling requests |
| 100 | ~2,000 requests/min | 0 |
| 1,000 | ~20,000 requests/min (often overloads shared hosting) | 0 |
| 10,000 | ~200,000 requests/min (requires dedicated infrastructure) | 0 |
Polling requests aren't free — each one fires WordPress's full init, processes auth, queries the database. The WebSocket version cuts ALL of that out for real-time delivery.
How it works#
Once a user opens a page with the messenger loaded:
- The browser establishes a single WebSocket connection to the cloud relay
- Real-time events (new message, read receipt, typing indicator, presence) flow through that connection
- Your WordPress server is only touched when the user sends a message or loads history — both rare events compared to polling
| Polling pattern | WebSocket pattern |
|---|---|
| Browser asks "any new messages?" every 3 seconds → server checks DB → returns yes/no | Server pushes new message to all participants when it happens |
| 100% wasted requests when nothing's new | 0 wasted requests |
When the difference matters#
| Site profile | Impact |
|---|---|
| Shared hosting with 50+ active users | Free version may overwhelm hosting; WebSocket fixes it |
| VPS / dedicated server | Free version works but consumes resources WebSocket would free up |
| Cloudflare / caching layer | Polling requests bypass cache; WebSocket bypass-cache impact is zero |
| Sites running other heavy plugins | WebSocket frees DB capacity for those plugins |
Frequently asked questions#
Where does the WebSocket connection go?#
To the Better Messages cloud relay — a separate infrastructure included with the WebSocket-version license. The connection doesn't touch your WordPress server.
Does this require a dedicated WordPress hosting upgrade?#
No — quite the opposite. Sites on shared hosting that struggle under AJAX polling often see no issues after switching to WebSocket because the polling load is eliminated.
What about message sends — don't those still hit my server?#
Yes — sending a message and saving it to the database is one request to your server. But that's ONE request per message, not 20 polling requests per minute per user. Net load is much lower.
Does WebSocket bypass my caching layer?#
The WebSocket connection itself talks to the cloud relay, not your origin. Caching layers (Cloudflare, Varnish) aren't involved. Your WordPress origin gets only the message-send and history-load traffic, both cacheable in different ways.
Will my hosting provider complain?#
Most hosting providers prefer the WebSocket version because it reduces requests against your shared hosting. If yours objects to the WebSocket connections specifically (rare), they're not really objecting to your hosting — they're objecting to the cloud relay traffic, which doesn't impact your hosting at all.
See also#
- No limits — unlimited concurrent users on the relay
- Servers location — where the relay is hosted
- Real-time messaging — AJAX vs WebSocket comparison
- Instant delivery — why messages arrive faster too