Уявіть собі, що у вашому застосунку кілька разів на секунду мають надходити повідомлення
{ “timestamp”: 1747008028, “price”: 997.538642664439 }
Як тут краще організувати серіалізацію payload-у?
1️⃣ Чому розмір payload має значення?
- Менший пакет → коротший TTFB і менше затримок.
- Економія трафіку = нижчі витрати на інфраструктуру та швидший фронтенд.
2️⃣Порівняння розмірів повідомлень
- JSON-об’єкт {timestamp, price} – 49 byte
- JSON-об’єкт {t, p} – 37 byte
- JSON-кортеж [t,p] – 29 byte
- Protobuf – 15 byte
3️⃣ permessage-deflate (RFC 7692)
- WS мають вбудоване стиснення яке активується у фазі HTTP Upgrade: браузер пропонує, сервер вирішує.
- Алгоритм — DEFLATE (zlib); стиснення «повідомлення-за-повідомленням».
Приклад
new WebSocketServer({
port: 8080,
perMessageDeflate: {
threshold: 1024, // не стискати < 1 KB
clientNoContextTakeover: true, // менше пам’яті
serverNoContextTakeover: true
}
});
4️⃣ Коли вигідно стискати, а коли ні
- Великі JSON (>1 KB) - економія 70-90%, але навантаження на CPU
- Часті дрібні котирування (< 200 😎 - економія ~0%, бо заголовок DEFLATE «з’їдає» вигоду
- Protobuf – простіше вимкнути
👉 Висновки
- Оптимізація payloads нагадує оптимізацію зберігання в MongoDB.
- Перехід з JSON-object → JSON-array → Protobuf вже зменшує пакет у ≈3 р.
- Якщо потрібна читаємість разом з помірним зменшенням трафіку - {t,p} непоганий компроміс.
- Для максимальної продуктивності в стрімах котирувань усе ще лідирує бінарний формат (Protobuf)