Технічні подробиці

Ця сторінка — для тих, кому потрібні подробиці. Усе тут виміряно або прочитано безпосередньо з джерела; нічого не оцінено приблизно.

Як завантажується віджет

Два етапи. Спочатку невеликий завантажувач малює кнопку й більше нічого не робить. Сам чат отримується лише після одного з п’яти тригерів: браузер не зайнятий (щонайпізніше через три секунди), миша чи палець на кнопці, команда зі сторінки, сигнал труднощів MousePlayer або push-звернення, наприклад від вашого service worker.

Причина є: більшість відвідувачів ніколи не відкривають чат. Для них він не має затримувати завантаження сторінки; діючі тригери задаються в тегу скрипту.

• Завантажувач: 3,48 кБ у передачі з нашого CDN із gzip
• Увесь віджет: 85,5 кБ у такій самій передачі й лише після спрацювання одного з тригерів
• До появи кнопки: 11–21 мс
• Зміщення макета: 0,0000 — місце резервується до появи будь-чого

Для порівняння, теж виміряно й усі три стиснуто brotli: завантажувач Crisp — 2876 Б, Intercom — 3161 Б. Наші 3069 Б посередині, а не на порядки менше. Той, хто стверджує інше, не вимірював.

Він не заважає вашому сайту

Віджет перебуває в закритому shadow DOM. Ваші стилі його не досягають, а його стилі — вашої сторінки, навіть якщо ви задасте * { box-sizing: border-box } або використовуєте CSS-фреймворк, що перевизначає все.

Він працює за суворої Content Security Policy без жодного повідомлення в консолі: без eval, вебшрифту й пікселя відстеження. Стилі задаються через constructable stylesheets, на які style-src не поширюється. Тому кнопка, вікно чату, тури продуктом та консоль операторів на вашому сайті не потребують unsafe-inline — виміряно за style-src 'self' і навіть style-src 'none': нуль порушень, повне оформлення. Виміряно в поточному Chromium; старіші браузери без constructable stylesheets (як-от Safari до 16.4) використовують запасний елемент <style>, який сувора політика блокує.

Нуль запитів до інших серверів. Усе надходить із reactive.chat або, із власним доменом, із вашої адреси; зображення, як-от логотип і аватари, — з адрес, які ви задаєте самі.

Протокол

З’єднання використовує WebSocket; якщо мережа його не пропускає, використовуються звичайні HTTPS-запити (server-sent events або довге опитування). Протокол має версії й визначає 31 код помилки, з них 26 для віджета, решта — для панелі операторів і пошуку сайту. Кожен має визначену реакцію клієнта (повторити негайно, після очікування, після повторного підключення, не повторювати), деякі також мають код закриття. Невідома помилка обробляється як тимчасова серверна: повтор після очікування, а після п’яти спроб повідомлення вважається недоставленим і його можна надіслати знову — без нескінченного циклу.

Повторне підключення зі зростанням затримки. Якщо з’єднання обривається, повідомлення потрапляють у буфер і надсилаються після відновлення. Кожне має ID; сервер розпізнає повтори й не зберігає їх двічі.

Доступність

Створено відповідно до WCAG 2.2 AA:

• Утримання фокусу у відкритому вікні, ESC закриває, фокус повертається на попереднє місце
• Нові повідомлення озвучуються через aria-live
• Контраст тексту й поверхні обчислюється, а не припускається — див. нижче
• Повне керування клавіатурою, видиме кільце фокусу

Контраст обчислюється

Ви задаєте колір. Поверхня отримує саме його. Текст на ній змінюється до досягнення співвідношення 4,5:1 — вимоги WCAG для звичайного тексту.

Виміряно для 178 кольорів у двох темах і трьох поєднаннях, тобто 1068 точок даних: жодної нижче 4,5:1, найгірше значення — 4,50:1.

Це відмінність від інших провайдерів: там віджет можна налаштувати так, що його ніхто не прочитає.

Персональні дані

Маскування відбувається у двох місцях: у браузері відвідувача до виходу будь-яких даних із пристрою та знову на сервері перед збереженням. Розпізнаються номери карток (із перевіркою Луна), IBAN, електронні адреси, номери телефонів, податкові номери й номери документів. Номери замовлень і клієнтів не змінюються.

Два місця, бо одного недостатньо: браузерне можна вимкнути, а серверне бачить лише те, що надійшло.

Правила

Коли віджет звертається до відвідувача, визначає декларативний список правил, а не умова в коді. Стандартно є шість правил (затримка на сторінці, роздратований клік, помилка JavaScript, застрягання у формі, намір купити, вихід з оформлення замовлення); роздратований клік, застрягання у формі та намір купити визначаються лише разом із MousePlayer. Власні правила додаються в обліковому записі. На тарифі Free діє одне активне звернення на проєкт.

Різниця практична: зміна правила — це зміна налаштування в обліковому записі, а не розгортання.

Інтеграції

Вебхуки й Slack готові. Для понад 30 інших сервісів є підключення; більшість перевірено на змодельованих відповідниках, але вони ніколи не працювали зі справжнім сервісом, і сторінка інтеграцій це позначає.

Серверний API (REST і MCP) читає розмови, повідомлення, проєкти, відвідувачів, події й правила, записує повідомлення та події й реєструє вебхуки. Список відвідувачів і MCP можна вимкнути для проєкту.

Кожна інтеграція проходить через чергу із запобіжником: якщо сторонній сервіс завис, після повторних збоїв його на деякий час пропускають. Повідомлення чату ніколи ним не затримується — це найважливіше правило цього шару.

Що не завершено

Щоб ніхто не дізнався про це вже під час інтеграції:

• Міст MousePlayer виконує опитування, бо MousePlayer ще не надсилає узгоджені події самостійно.
• Вкладення, A/B-тести й власний домен працюють як бета: вони працюють і виміряні, але ще можуть змінитися.
• Канали електронної пошти, Telegram, SMS, WhatsApp, Messenger та Instagram перевірено на змодельованих відповідниках, ще не зі справжніми обліковими записами. Якщо відповідь через канал остаточно не доставлена, у розмові це поки не показано.

Докладніше в документації

Взаємодія віджета, сервера й з’єднання: Архітектура й робота. З’єднання, резервний канал HTTP і повторне підключення: Транспорт. Усі розділи: документація.