Проблема: страница выглядит загруженной, но не реагирует на клики
Time to Interactive (TTI) — момент, когда страница не просто отрисована, а действительно готова к взаимодействию. Разница между «страница выглядит готовой» и «страница готова» может достигать 5–15 секунд на медленных устройствах. Именно это объясняет высокий показатель отказов на мобильных при хороших FCP. Мы, команда веб-инженеров с 10+ летним опытом в оптимизации производительности, помогаем настроить мониторинг TTI, чтобы вы видели реальную картину и могли быстро реагировать на регрессии.
Как TTI влияет на конверсию и бизнес?
Исследование Google: увеличение TTI на 1 секунду снижает конверсию мобильных посетителей на 7–12% в зависимости от тематики. Для e-commerce с 1 000 мобильных визитов в день и средним чеком $50 — это $350–600 в день потенциальных потерь при каждой лишней секунде TTI. Именно поэтому мониторинг TTI нужно настраивать как бизнес-метрику, с привязкой к сегментам трафика и конверсионным воронкам.
Что такое TTI и как его измеряют?
TTI — момент, после которого в течение 5 секунд нет Long Tasks (задач длиннее 50 мс в main thread) и сеть спокойна (не более 2 активных запросов). Lighthouse ищет последнюю Long Task в этом тихом окне и берёт её конец как TTI. Практическое следствие: TTI напрямую определяется количеством и размером JavaScript, который парсируется и выполняется при загрузке, и тем, что этот JS делает в main thread.
| Диапазон TTI (мс) | Оценка Lighthouse |
|---|---|
| 0–3800 | Хорошо |
| 3800–7300 | Требует улучшения |
| >7300 | Плохо |
Для мобильных устройств с CPU throttling 4x умножайте свои десктопные результаты примерно на 3.
Почему стоит использовать Lighthouse CI в паре с Performance Observer?
Lighthouse CI — идеальный инструмент для регрессионного тестирования в CI/CD pipeline, а Performance Observer даёт реальные данные от реальных пользователей (field data). Комбинация этих подходов позволяет быстро замечать регрессии и одновременно отслеживать фактические показатели на сайте. 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 месяца после сдачи.
Сроки и как заказать
Базовая настройка Lighthouse CI — от 1 рабочего дня. Система с полевыми данными и Grafana — от 3 до 5 рабочих дней. Полный цикл с алертами и сегментацией — от 1 до 2 недель. Стоимость рассчитывается индивидуально, исходя из объёма работ. Свяжитесь с нами для бесплатного аудита и оценки вашего проекта — мы подготовим предложение в течение 24 часов.