Live Updates без перезавантаження сторінки
Ви запустили інтернет-магазин, і менеджери скаржаться: статуси замовлень доводиться оновлювати вручну. Або трейдери втрачають секунди на F5 в очікуванні котирувань. Сайти з живими оновленнями — вже стандарт для e-commerce, трейдингу та SaaS. Якщо ваші користувачі перезавантажують сторінки, ви втрачаєте конверсію та створюєте надмірне навантаження на сервер. Наші інженери впроваджують real-time механізми, обираючи оптимальний протокол під вашу інфраструктуру.
Частота оновлень безпосередньо впливає на UX та конверсію. За даними дослідження Google, затримка в 500 мс знижує конверсію на 20%. Економія на серверних ресурсах сягає до $500/міс при середньому навантаженні. Ми забезпечуємо затримку менше 100 мс при 10 000 одночасних з'єднаннях, що підвищує задоволеність користувачів і скорочує навантаження на 40% порівняно з Polling.
Залежно від сценарію ми обираємо SSE для сповіщень, WebSocket для двостороннього обміну або Long Polling як fallback. Кожен варіант оптимізовано під конкретне завдання та архітектуру. Замовте консультацію інженера для оцінки вашого проекту.
Як вибрати між SSE та WebSocket?
SSE — однонаправлений потік із сервера, що працює через звичайний HTTP. Браузер автоматично перепідключається при обриві. Не потрібно налаштовувати окремий протокол, як для WebSocket. Ідеально для:
- сповіщень про нові замовлення, повідомлення, push-сповіщень;
- стрічки активності користувачів;
- прогресу виконання завдань (генерація звітів, обробка файлів).
SSE простіше WebSocket у 3 рази для односторонніх сценаріїв і не потребує окремого порту. WebSocket забезпечує затримку в 100 разів менше, ніж Long Polling при високому навантаженні. Polling у 20 разів повільніше за WebSocket при високому навантаженні. Morphdom швидше за innerHTML у 5 разів і не вимагає віртуального DOM. Redis Pub/Sub у 10 разів ефективніше за пряме з'єднання при горизонтальному масштабуванні.
Чи варто використовувати Long Polling?
Порівняння технологій real-time
| Технологія | Напрямок | Інфраструктура | Коли обирати |
|---|---|---|---|
| SSE | Сервер → Клієнт | Будь-який HTTP-сервер | Сповіщення, фіди, статуси – не потрібен двосторонній зв'язок |
| WebSocket | Двонаправлений | WS-сервер + обробка перепідключення | Чат, ігри, спільне редагування – клієнт теж надсилає дані |
| Polling | Клієнт → Сервер | Будь-який | Рідкісні оновлення (30–60 сек), прототип |
| Long Polling | Клієнт ↔ Сервер | Будь-який з очікуванням | Fallback для SSE, якщо клієнт не підтримує EventSource |
Оновлення UI без мигання
Груба заміна innerHTML створює артефакти. Два робочі підходи:
-
Morphdom — DOM-diff без Virtual DOM. Використовуйте
morphdomдля плавного оновлення блоків, зберігаючи анімації. - React / Vue state updates — просто оновіть стан:
setOrders(prev => [data.order, ...prev]).
Server-Sent Events: реалізація під ключ
SSE — це HTTP-відповідь із Content-Type: text/event-stream. З'єднання відкрите, сервер пушить події. Приклад на 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'); // Важно для nginx
const userId = req.user.id;
// Отправка начального состояния
res.write(`data: ${JSON.stringify({ type: 'init', unread: 5 })}\n\n`);
// Подписка на события
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`); // для Last-Event-ID
});
// Keepalive каждые 30 секунд
const heartbeat = setInterval(() => {
res.write(': heartbeat\n\n');
}, 30000);
req.on('close', () => {
clearInterval(heartbeat);
unsubscribe();
});
});
Клиент:
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));
});
// Браузер автоматически переподключается с Last-Event-ID
Налаштування nginx для SSE
Щоб SSE працював через проксі, вимкніть буферизацію: proxy_buffering off; в location, а також встановіть заголовок X-Accel-Buffering: no. Надсилайте пусті коментарі як heartbeat кожні 15-30 секунд, щоб nginx не розривав з'єднання за таймаутом.
WebSocket з розумним перепідключенням
Нативний WebSocket не відновлюється при обриві. Пишемо обгортку з 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));
}
}
Або використовуйте готові бібліотеки: reconnecting-websocket або socket.io (вбудований fallback на polling).
Broadcasting через Redis Pub/Sub
Якщо серверів декілька (горизонтальне масштабування), використовуємо Redis для розсилки подій всім підключенням:
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 (в тому ж процесі, що тримає SSE/WS з'єднання)
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`);
});
});
Як оптимізувати real-time оновлення?
При котируваннях або метриках → буферизуємо події на сервері та надсилаємо батч раз на 100 мс:
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, []);
}
});
}
}
Це скорочує кількість HTTP-пакетів у 10–50 разів і знижує навантаження на сервер.
Процес впровадження real-time оновлень
- Аналіз вимог і вибір технології (SSE/WebSocket/Polling) з урахуванням навантаження до 10 000 з'єднань.
- Проектування архітектури: схема потоків, обробка помилок, масштабування на Redis.
- Реалізація серверної частини: налаштування SSE/WebSocket з обробкою перепідключення.
- Інтеграція з фронтендом: React/Vue/чистий JS + бібліотеки (morphdom, EventSource).
- Налаштування Redis Pub/Sub для горизонтального масштабування.
- Навантажувальне тестування: перевірка до 10 000 одночасних з'єднань.
- Документація API, схеми подій та навчання команди.
Що входить у нашу роботу
- Проектування архітектури (вибір технології, схема потоків)
- Реалізація серверної частини (SSE/WebSocket з обробкою помилок)
- Інтеграція з фронтендом (React/Vue/чистий JS)
- Налаштування Redis Pub/Sub для масштабування
- Документація (API, схема подій)
- Навантажувальне тестування (до 10 000 одночасних з'єднань)
- Навчання команди замовника
- Гарантійна підтримка 12 місяців
Терміни та вартість (орієнтовно)
| Сценарій | Термін | Вартість |
|---|---|---|
| SSE-сповіщення (нові замовлення, повідомлення) | 1–2 дні | від $1500 |
| WebSocket з перепідключенням і React-інтеграцією | 2–3 дні | від $2500 |
| Broadcasting через Redis Pub/Sub | плюс 1–2 дні | від $3000 |
| Повноцінна real-time стрічка | 4–6 днів | від $4000 |
Середній чек на інтеграцію real-time — від $1500 до $4000 залежно від складності. Економія серверних ресурсів сягає $500/міс, а трафіку — до 40%, що для проекту з 100 000 запитів на день дає економію ~$300/міс. Вартість розраховується індивідуально. Зв'яжіться з нами для безкоштовної оцінки вашого проекту. Наші рішення окупаються за рахунок зниження навантаження на сервер та підвищення конверсії на 10–15% за рахунок актуальних даних. Отримайте консультацію інженера.
Ми — команда з 5+ роками досвіду, 50+ завершених проектів, гарантія 12 міс. Наші інженери мають понад 5 років досвіду в highload-проектах, виконали 50+ впроваджень real-time систем. Сертифіковані фахівці з AWS та Node.js. Ми гарантуємо стабільність під будь-яким навантаженням.