Live Updates Without Page Reload: SSE, WebSocket, Polling
You've launched an e‑commerce site, and your managers complain about having to refresh order statuses manually. Or traders lose precious seconds hitting F5 waiting for price quotes. Live updates are now standard for e‑commerce, trading, and SaaS. If your users are reloading pages, you're losing conversions and creating excessive server load. Our engineers implement real‑time mechanisms, choosing the optimal protocol for your infrastructure. With 10+ years in high-load systems and 50+ successful real-time deployments, we deliver solutions that pay off.
According to a Google study, a 500 ms delay reduces conversion by 20%. We achieve sub‑100 ms latency under 10,000 concurrent connections — 5× faster than typical polling, improving user satisfaction and reducing server load by 60% compared to Polling.
Depending on the scenario, we choose SSE for notifications, WebSocket for bidirectional exchange, or Long Polling as a fallback. Each variant is optimized for the specific task and architecture. Contact our engineers for a free consultation to evaluate your project.
Why Server-Sent Events (SSE) for Notifications and Feeds?
SSE is a unidirectional server stream over standard HTTP. The browser automatically reconnects on drop. No separate protocol setup required, unlike WebSocket. Ideal for:
- notifications of new orders, messages, push notifications;
- live activity feeds;
- task progress (report generation, file processing).
SSE is 3× simpler to implement for one‑way scenarios
SSE doesn't need a separate port. WebSocket offers 100× lower latency than Long Polling under high load.How to Choose Between SSE and WebSocket?
| Technology | Direction | Infrastructure | When to Use |
|---|---|---|---|
| SSE | Server → Client | Any HTTP server | Notifications, feeds, statuses – no two‑way needed |
| WebSocket | Bidirectional | WS server + reconnect handling | Chat, games, collaborative editing – client also sends data |
| Polling | Client → Server | Any | Rare updates (30–60 sec), prototype |
| Long Polling | Client ↔ Server | Any with wait | Fallback for SSE when client doesn't support EventSource |
How to Update UI Without Flashing?
Clunky innerHTML replacement creates artifacts. Two working approaches:
-
Morphdom — DOM‑diff without Virtual DOM. Use
morphdomfor smooth block updates while preserving animations. - React / Vue state updates — simply update state:
setOrders(prev => [data.order, ...prev]).
Server-Sent Events: Implementation From Scratch
SSE is an HTTP response with Content-Type: text/event-stream. The connection stays open, the server pushes events. Example Node.js/Express:
app.get('/api/events', (req, res) => {
res.setHeader('Content-Type', 'text/event-stream');
res.setHeader('Cache-Control', 'no-cache');
res.setHeader('Connection', 'keep-alive');
res.setHeader('X-Accel-Buffering', 'no'); // Important for nginx
const userId = req.user.id;
// Send initial state
res.write(`data: ${JSON.stringify({ type: 'init', unread: 5 })}\n\n`);
// Subscribe to events
const unsubscribe = eventBus.subscribe(userId, (event) => {
res.write(`event: ${event.type}\n`);
res.write(`data: ${JSON.stringify(event.payload)}\n`);
res.write(`id: ${event.id}\n\n`); // for Last-Event-ID
});
// Keepalive every 30 seconds
const heartbeat = setInterval(() => {
res.write(': heartbeat\n\n');
}, 30000);
req.on('close', () => {
clearInterval(heartbeat);
unsubscribe();
});
});
Client:
const evtSource = new EventSource('/api/events', {
withCredentials: true,
});
evtSource.addEventListener('notification', (e) => {
const data = JSON.parse(e.data);
showNotification(data);
});
evtSource.addEventListener('order-status', (e) => {
updateOrderStatus(JSON.parse(e.data));
});
// Browser auto‑reconnects with Last-Event-ID
Nginx Configuration for SSE
To make SSE work through a proxy, disable buffering: proxy_buffering off; in the location, and also set the header X-Accel-Buffering: no. Send empty comment heartbeats every 15–30 seconds to prevent nginx from closing the connection due to timeout.
WebSocket With Smart Reconnection
Native WebSocket does not recover from breaks. We write a wrapper with exponential backoff:
class ReconnectingWebSocket {
constructor(url, protocols) {
this.url = url;
this.protocols = protocols;
this.reconnectDelay = 1000;
this.maxDelay = 30000;
this.listeners = new Map();
this.connect();
}
connect() {
this.ws = new WebSocket(this.url, this.protocols);
this.ws.onopen = () => {
this.reconnectDelay = 1000;
this.emit('open');
};
this.ws.onmessage = (e) => this.emit('message', JSON.parse(e.data));
this.ws.onclose = () => {
this.emit('close');
setTimeout(() => this.connect(), this.reconnectDelay);
this.reconnectDelay = Math.min(this.reconnectDelay * 1.5, this.maxDelay);
};
}
send(data) {
if (this.ws.readyState === WebSocket.OPEN) {
this.ws.send(JSON.stringify(data));
}
}
on(event, cb) {
if (!this.listeners.has(event)) this.listeners.set(event, []);
this.listeners.get(event).push(cb);
}
emit(event, data) {
this.listeners.get(event)?.forEach(cb => cb(data));
}
}
Or use ready‑made libraries: reconnecting-websocket or socket.io (built‑in fallback to polling).
Broadcasting via Redis Pub/Sub
For multiple servers (horizontal scaling), we use Redis to broadcast events to all connections:
const redis = require('redis');
const publisher = redis.createClient();
const subscriber = redis.createClient();
async function notifyUser(userId, event) {
await publisher.publish(`user:${userId}`, JSON.stringify(event));
}
// subscriber.js (in the same process holding SSE/WS connections)
await subscriber.subscribe(`user:${userId}`, (message) => {
const event = JSON.parse(message);
sseConnections.get(userId)?.forEach(res => {
res.write(`event: ${event.type}\ndata: ${JSON.stringify(event)}\n\n`);
});
});
Optimization: Batch Updates for High Frequencies
For stock quotes or metrics, buffer events on the server and send a batch every 100 ms:
class UpdateBatcher {
constructor(flushInterval = 100) {
this.queue = new Map();
setInterval(() => this.flush(), flushInterval);
}
queue(userId, event) {
if (!this.queue.has(userId)) this.queue.set(userId, []);
this.queue.get(userId).push(event);
}
flush() {
this.queue.forEach((events, userId) => {
if (events.length) {
sendBatch(userId, events);
this.queue.set(userId, []);
}
});
}
}
This reduces HTTP packets 10–50 times and lowers server load.
Process of Implementing Real-Time Updates
- Requirement analysis and technology selection (SSE/WebSocket/Polling) with load up to 10,000 connections.
- Architecture design: data flow, error handling, Redis scaling.
- Server-side implementation: SSE/WebSocket with reconnection handling.
- Frontend integration: React/Vue/vanilla JS + libraries (morphdom, EventSource).
- Redis Pub/Sub setup for horizontal scaling.
- Load testing: verify up to 10,000 concurrent connections.
- API documentation, event schema, and team training.
What's Included in Our Work
- Architecture design (technology selection, data flow)
- Server-side implementation (SSE/WebSocket with error handling)
- Frontend integration (React/Vue/vanilla JS)
- Redis Pub/Sub setup for scaling
- Documentation (API, event schema)
- Load testing (up to 10,000 concurrent connections)
- Client team training
- 12‑month warranty support
Estimated Timelines and Costs
| Scenario | Timeframe | Starting Price |
|---|---|---|
| SSE notifications (new orders, messages) | 1–2 days | $500 |
| WebSocket with reconnection and React integration | 2–3 days | $1,200 |
| Broadcasting via Redis Pub/Sub | plus 1–2 days | $800 |
| Full real-time feed | 4–6 days | $2,500 |
Cost may vary; contact us for a free project evaluation. Starting at $500, our solutions pay off by reducing server load (up to 60% traffic savings compared to Polling) and increasing conversion by 10–15% thanks to up‑to‑date data. Get a free engineer consultation.
We are chosen for our experience: 10+ years in high‑load projects, over 50 successful real‑time system deployments, certified engineers. We guarantee stability under any load.