← Усі пости

Як ми прискорили появу launcher Lavenity до менш ніж 100 мс

Loader на 2,9 КБ gzip, миттєвий рендер кнопки, idle preload iframe і локальний paint менш ніж за 10 мс допомагають чату не сповільнювати сайт.

Віджет підтримки має швидко зʼявлятися, але не конкурувати зі сторінкою, якій він допомагає. Ми перебудували шлях завантаження Lavenity навколо цієї межі: спочатку показати маленький launcher, а повний інтерфейс розмови підготувати тоді, коли у браузера зʼявиться вільний ресурс.

Чому launcher має завантажуватися окремо

У поточній production-збірці embed loader має 8 058 байтів без стиснення і 2 947 байтів із gzip. Він підключається через async script, додає невеликий ізольований набір стилів і створює launcher звичайними browser API. Для появи кнопки не потрібно чекати Vue, історію розмов, WebSocket-зʼєднання чи завантаження конфігурації робочого простору.

Важчий застосунок чату залишається ізольованим в iframe. Після появи launcher Lavenity використовує requestIdleCallback для фонового preload фрейму, із timeout як запасним шляхом. Тому iframe не заважає першому рендеру сайту, але встигає підготуватися до відкриття. Якщо відвідувач натискає раніше, той самий ідемпотентний setup запускається одразу.

Що саме ми виміряли

Ми також змінили кешування стабільної адреси widget.js. Loader може пʼять хвилин віддаватися свіжим із кешу й добу перевірятися у фоні. На повторному візиті кнопка зʼявляється без блокуючого запиту на перевірку, а оновлення loader усе одно швидко доходять до сайтів.

21 липня 2026 року ми виконали пʼять локальних вимірювань у Chromium із cache-busted URL: від додавання script до готовності launcher. Кнопка потрапляла в DOM за 2,9–3,6 мс, а наступний paint відбувався за 4,4–8,8 мс. Це вимірює виконання в браузері на локальному сервері й не включає DNS, TLS, географічну затримку, навантаження пристрою або реальний шлях через CDN.

Кешування, iframe і реальний бюджет швидкості

Отже, на швидкому зʼєднанні або кешованому візиті для launcher залишається практичний бюджет приблизно до 100 мс — але це не універсальна обіцянка для кожної мережі. Реальний час відрізнятиметься, тому зі зростанням трафіку ми вимірюватимемо production percentiles. Головний перевірений результат: локальна робота займає менш ніж 10 мс, а мережею передається лише 2,9 КБ gzip.

Видима кнопка тепер є найдешевшою частиною досвіду, а повний застосунок чекає своєї черги. Саме так має поводитися вбудована підтримка: бути поруч, коли вона потрібна клієнту, і не заважати решті сайту завантажуватися.

Як перевірити вплив чат-віджета на свій сайт

Вимірюйте сторінку щонайменше у двох станах: перший візит із чистим кешем і повторний візит. Перевірте момент появи launcher, зміни Largest Contentful Paint та Total Blocking Time, а також відкриття повного чату. Один локальний тест не відображає мобільну мережу, повільний пристрій і географічну затримку.

Порівнюйте однакові сторінки й умови, а не загальні оцінки з різних запусків. Якщо віджет додається через tag manager, врахуйте затримку самого контейнера. Launcher може виконуватися швидко, але зʼявитися пізно через порядок завантаження, consent-правила або сторонні теги перед ним.

Поширене запитання

Чи означає «менш ніж 100 мс» однаковий час для кожного відвідувача?

Ні. Це практичний бюджет для швидкого або кешованого візиту, а не універсальна гарантія. Реальний час залежить від мережі, пристрою, CDN, порядку скриптів і навантаження сторінки; локальне виконання launcher у наших вимірюваннях займало менш ніж 10 мс.