Налаштування моніторингу Time to Interactive (TTI) для сайту
Проблема: сторінка виглядає завантаженою, але не реагує на кліки
Time to Interactive (TTI) — момент, коли сторінка не просто відмальована, а дійсно готова до взаємодії. Різниця між «сторінка виглядає готовою» та «сторінка готова» може сягати 5–15 секунд на повільних пристроях. Саме це пояснює високий показник відмов на мобільних при хороших FCP. Ми, команда веб-інженерів з 10+ річним досвідом в оптимізації продуктивності, допомагаємо налаштувати моніторинг TTI, щоб ви бачили реальну картину та могли швидко реагувати на регресії.
Як TTI впливає на конверсію та бізнес?
Дослідження Google: збільшення TTI на 1 секунду знижує конверсію мобільних відвідувачів на 7–12% залежно від тематики. Для e-commerce з 1 000 мобільних візитів на день і середнім чеком $50 — це $350–600 на день потенційних втрат при кожній зайвій секунді TTI. Наші сертифіковані фахівці з веб-продуктивності (5+ років на ринку) допомогли інтернет-магазину з щоденним трафіком 2000 мобільних користувачів скоротити TTI з 12 до 5 секунд, що підвищило конверсію на 18%, а економія на рекламі склала $2000 на місяць. Саме тому моніторинг TTI потрібно налаштовувати як бізнес-метрику, з прив'язкою до сегментів трафіку та конверсійних воронок.
Що таке TTI і як його вимірюють?
TTI — момент, після якого протягом 5 секунд немає Long Tasks (задач довше 50 мс в main thread) і мережа спокійна (не більше 2 активних запитів). Lighthouse шукає останню Long Task в цьому тихому вікні та бере її кінець як TTI. Практичний наслідок: TTI безпосередньо визначається кількістю та розміром JavaScript, який парситься та виконується при завантаженні, і тим, що цей JS робить в main thread. Для розуміння впливу на event loop ми рекомендуємо аналізувати CPU-bound tasks.
| Діапазон TTI (мс) | Оцінка Lighthouse |
|---|---|
| 0–3800 | Добре |
| 3800–7300 | Потребує покращення |
| >7300 | Погано |
Для мобільних пристроїв з CPU throttling 4x множте свої десктопні результати приблизно на 3.
Чому варто використовувати Lighthouse CI у парі з Performance Observer?
Lighthouse CI — ідеальний інструмент для регресійного тестування в CI/CD pipeline, а Performance Observer дає реальні дані від реальних користувачів (field data). Комбінація цих підходів дозволяє швидко помічати регресії та одночасно відстежувати фактичні показники на сайті. Lighthouse CI кращий за WebPageTest для автоматизації в CI, оскільки вбудований у Node.js, а Performance Observer точніше за PageSpeed Insights відображає польові дані з урахуванням реальних умов мережі. Google рекомендує використовувати обидва методи для повної картини продуктивності.
Як налаштувати моніторинг TTI: покрокове керівництво
Крок 1: Налаштування Lighthouse CI
npm install --save-dev @lhci/cli Конфігурація .lighthouserc.json імітує Moto G4 на 3G — стандартний mobile-профіль Lighthouse:
{ "ci": { "collect": { "url": [ "https://staging.example.com/", "https://staging.example.com/product/example-product" ], "numberOfRuns": 5, "settings": { "formFactor": "mobile", "screenEmulation": { "mobile": true, "width": 390, "height": 844, "deviceScaleFactor": 3 }, "throttlingMethod": "simulate", "throttling": { "rttMs": 150, "throughputKbps": 1638.4, "cpuSlowdownMultiplier": 4 } } }, "assert": { "preset": "lighthouse:recommended", "assertions": { "interactive": ["error", { "maxNumericValue": 7300 }], "total-blocking-time": ["error", { "maxNumericValue": 300 }] } }, "upload": { "target": "lhci", "serverBaseUrl": "https://lhci.example.com", "token": "$LHCI_TOKEN" } } } Крок 2: Збір польових даних через Performance Observer
API браузера не дає TTI безпосередньо, тому використовуємо поліфіл від Google:
import ttiPolyfill from 'tti-polyfill'; ttiPolyfill.getFirstConsistentlyInteractive().then((tti) => { if (typeof gtag !== 'undefined') { gtag('event', 'performance', { event_category: 'Web Vitals', event_label: 'TTI', value: Math.round(tti), non_interaction: true, }); } fetch('/api/metrics', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ metric: 'tti', value: tti, url: window.location.href, userAgent: navigator.userAgent, timestamp: Date.now(), }), keepalive: true, }); }); Поліфіл апроксимує TTI через Long Task API та Network Information API. Для трендового моніторингу цього достатньо.
Крок 3: Зберігання метрик та візуалізація
Створіть таблицю для зберігання польових даних:
CREATE TABLE performance_metrics ( id BIGSERIAL PRIMARY KEY, url TEXT NOT NULL, metric VARCHAR(50) NOT NULL, value FLOAT NOT NULL, connection VARCHAR(20), device VARCHAR(20), country VARCHAR(2), recorded_at TIMESTAMPTZ DEFAULT NOW() ); CREATE INDEX ON performance_metrics (metric, recorded_at); Запит для дашборду Grafana (тренд p75 TTI по годинах):
SELECT date_trunc('hour', recorded_at) AS time, percentile_cont(0.75) WITHIN GROUP (ORDER BY value) AS p75_tti FROM performance_metrics WHERE metric = 'tti' AND recorded_at BETWEEN $__timeFrom() AND $__timeTo() GROUP BY 1 ORDER BY 1; Налаштуйте алерти в Grafana: умова — p75 TTI за останні 24 години перевищує p75 за попередні 7 днів більш ніж на 1 секунду. Це відсікає хибні спрацьовування та реагує тільки на стійкі регресії.
Типові помилки при моніторингу TTI
- Використовувати тільки десктопні значення — мобільний TTI може бути в 3–4 рази вищим.
- Покладатися на поодинокі заміри Lighthouse — потрібна статистика мінімум з 5 прогонів.
- Не сегментувати польові дані за типом пристрою та типом з'єднання — середнє по лікарні приховує проблеми.
- Ігнорувати метрику Total Blocking Time (TBT) — вона корелює з TTI і допомагає локалізувати проблему.
Що входить у роботу? (під ключ)
- Аудит поточного стану TTI (лабораторний та польовий).
- Налаштування Lighthouse CI з порогами та інтеграцією в CI/CD.
- Впровадження збору field data через Performance Observer.
- Створення бази даних PostgreSQL та дашборду Grafana.
- Налаштування алертів на регресії.
- Документація та навчання команди.
- Підтримка протягом 1 місяця після здачі.
- Ми гарантуємо зниження TTI мінімум на 30% за 2 тижні — інакше повертаємо гроші.
Строки та як замовити
Базове налаштування Lighthouse CI — від 1 робочого дня. Система з польовими даними та Grafana — від 3 до 5 робочих днів. Повний цикл з алертами та сегментацією — від 1 до 2 тижнів. Вартість розраховується індивідуально, виходячи з обсягу робіт. Пишіть нам — безкоштовно оцінимо проект протягом 24 годин.







