Оптимізація WebSocket через SharedWorker: архітектура без втрати з'єднання

Чому патерн вкладки-лідера більше не ідеальний

Коли користувач відкриває складний вебсервіс у кількох вкладках — будь-то CRM, фінансовий дашборд чи трекер замовлень — кожна вкладка намагається відкрити власний WebSocket. Запуск десятків одночасних сокет-з'єднань для одного клієнта перевантажує як серверний кластер, так і пам'ять браузера.

Довгий час класичним вирішенням цієї проблеми був патерн вибору лідера: за допомогою Web Locks API (navigator.locks) одна з вкладок стає головною, відкриває єдиний сокет і транслює дані іншим через BroadcastChannel. Це робочий підхід, але він має архітектурну вразливість. З'єднання фізично прив'язане до конкретного документа. Щойно користувач закриває лідер-вкладку, браузер повинен провести нове голосування, призначити наступника та заново ініціювати повний цикл рукостискання WebSocket. Для сервісів із чутливими реальними даними (котирування, онлайн-чати, спільне редагування) секундна затримка передачі даних є неприпустимою.

SharedWorker: з'єднання поза контекстом сторінки

Існує спосіб відокремити життєвий цикл сокета від життя окремих вкладок. Для цього команда ViAcore використовує SharedWorker — окремий фоновий потік JavaScript, до якого одночасно можуть звертатися кілька вкладок одного домену.

Як працює цей підхід:

• Ізольований контекст: воркер створюється під час запиту першої вкладки й продовжує жити незалежно, доки відкрита бодай одна сторінка.
• Спільна шина даних: кожна нова вкладка підключається через власний MessagePort.
• Нульовий час простою: закриття будь-якої сторінки, навіть тієї, що відкрилася першою, ніяк не впливає на активний WebSocket. З'єднання не перезапускається, тому втрати пакетів не відбувається.

Нюанси реалізації та керування життєвим циклом

На відміну від блокувань у navigator.locks, які браузер звільняє автоматично в момент знищення сторінки, SharedWorker не отримує нативної події про закриття порта. Якщо просто зберігати посилання у списку Set, закриті порти залишатимуться в пам'яті до спрацьовування збирача сміття.

Щоб контролювати кількість активних підключень і коректно гасити сокет, коли клієнт повністю закрив застосунок, варто передавати подію прощання:

• На рівні клієнтської вкладки підписуємося на pagehide та надсилаємо повідомлення про завершення сесії.
• У воркері видаляємо відповідний порт із реєстру.
• Коли кількість активних портів досягає нуля, викликаємо планове закриття сокета на стороні сервера.

Стратегія підтримки та бізнес-ефект

Використання SharedWorker суттєво зменшує навантаження на інфраструктуру: сервер утримує лише одне з'єднання на кожного реального користувача замість десятків дублікатів. Це гарантує миттєву синхронізацію даних без фризів під час навігації вкладками.

З точки зору підтримки платформами, технологія стабільно працює в усіх десктопних браузерах і сучасних версіях Safari для iOS. Для специфічних мобільних оточень раціонально використовувати прогресивне покращення: використовувати SharedWorker за замовчуванням, а як фолбек — повертатися до зв'язки Locks API та BroadcastChannel.