Налаштування моніторингу 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.

Для мобільних пристроїв з 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: покрокове керівництво

npm install --save-dev @lhci/cli

{
  "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"
    }
  }
}

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,
  });
});

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);

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;

Типові помилки при моніторингу 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 годин.

Чому Core Web Vitals критичні для технічного SEO

PageSpeed показує 34/100 на мобільних. У Search Console — червоні метрики по всіх сторінках категорій. Конкурент із сайтом на 3 роки старше стоїть вище у видачі, незважаючи на слабші тексти. Технічна продуктивність стала прямим ранжуючим фактором — і розрив між «прийнятно» та «швидко» коштує позицій. Ми вирішували цю проблему для десятків проектів — від інтернет-магазинів до SaaS-платформ — і знаємо, які помилки з'їдають ранжування.

Як досягти хороших показників Core Web Vitals?

Core Web Vitals: що реально впливає на позиції

Google використовує три метрики як сигнали ранжування (Page Experience): LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), INP (Interaction to Next Paint, замінив FID з останнього великого оновлення алгоритму).

LCP: чому 8 секунд — це не проблема зображення

LCP вимірює час відмальовки найбільшого видимого елемента сторінки. Найчастіше — hero image або H1. Пороги: добре < 2.5s, погано > 4s.

Типовий діагноз на реальному проекті: інтернет-магазин одягу, LCP 7.8s на мобільних. Елемент — hero image категорії, 4.2MB JPEG без srcset, завантажується через CSS background-image (не <img>). Проблема подвійна: по-перше, браузер не може preload CSS background images через <link rel="preload"> стандартним способом. По-друге, 4.2MB на мобільному з'єднанні — це фізично повільно.

Рішення по кроках:

1. Переносимо hero з CSS background в <img> з fetchpriority="high" та loading="eager"
2. Конвертуємо в WebP, додаємо srcset: 800w для мобільних, 1400w для десктопа
3. <link rel="preload" as="image" href="hero-800.webp" media="(max-width: 768px)"> в <head>
4. Прибираємо всі render-blocking скрипти вище hero через defer

Підсумок: LCP 7.8s → 1.9s. Без зміни хостингу, без CDN.

Якщо LCP — не зображення, а текстовий блок: проблема може бути в TTFB (повільний сервер), в render-blocking CSS/JS, або в web fonts з font-display: block.

CLS: зсуви, які дратують користувача і Google

CLS вимірює сумарний зсув елементів в процесі завантаження. Пороги: добре < 0.1, погано > 0.25. CLS 0.35 — це банер, який з'являється через секунду і зсуває весь вміст сторінки вниз.

Джерела CLS:

• Зображення без заданих розмірів. <img src="photo.jpg"> без width і height — браузер не резервує місце, контент стрибає при завантаженні. Фікс: явні width/height або aspect-ratio в CSS.
• Рекламні блоки та віджети. Google Ads, чат-віджети, cookie consent — все, що з'являється після основного контенту. Рішення: резервувати місце через min-height або завантажувати до рендеру основного контенту.
• Web fonts. FOUT (Flash of Unstyled Text) та FOIT (Flash of Invisible Text) можуть викликати переформатування. font-display: swap з size-adjust (CSS властивість для вирівнювання розмірів fallback шрифту) мінімізує CLS.
• Динамічний контент. Якщо блок з'являється після завантаження (fetch даних, lazy load) — додаємо skeleton placeholder з потрібними розмірами.

INP: чому інтерфейс «зависає» на 500ms

INP вимірює затримку відповіді на будь-яку взаємодію користувача: клік, тап, введення. Пороги: добре < 200ms, погано > 500ms. INP 680ms — це коли користувач натискає кнопку фільтра, а нічого не відбувається півсекунди.

Головна причина високого INP — заблокований main thread. JavaScript-бандл 2.1MB парситься і виконується синхронно. Поки виконується, користувацькі події не обробляються.

Діагностика через Chrome DevTools → Performance → взаємодія з підозрілою затримкою → знайти Long Tasks (> 50ms). Типові винуватці:

• Безперервна обробка великого списку без requestIdleCallback або requestAnimationFrame
• Важкі event listeners без debounce/throttle
• Синхронний setState в React, який тригерить повний ре-рендер складного дерева компонентів
• Third-party scripts: livechat, аналітика, віджети — вони виконуються в тому ж main thread

Рішення: code splitting через динамічний import(), перенесення важких обчислень в Web Workers, React.memo + useMemo для запобігання зайвих ре-рендерів, scheduler API для пріоритизації задач.

Schema.org: розмітка, яку читають роботи

Структуровані дані через JSON-LD — не прямий ранжуючий фактор, але дають rich snippets у видачі (зірки рейтингів, ціни, дата публікації), що збільшує CTR на 20–30%.

Типи розмітки за сценаріями:

• E-commerce: Product з offers (ціна, наявність, валюта), aggregateRating (рейтинг з відгуків), brand. BreadcrumbList для навігації. ItemList для сторінок категорій.
• Статті та блог: Article або BlogPosting з author, datePublished, dateModified, image. Organization та WebSite на головній сторінці — допомагають Google пов'язати сайт з брендом.
• Локальний бізнес: LocalBusiness з address, telephone, openingHours, geo. Критично для локального SEO.
• FAQ: FAQPage з mainEntity — питання та відповіді можуть з'являтися прямо у видачі як розкривний блок.

Валідація: Google Rich Results Test та Schema Markup Validator. Часта помилка — вказати price без priceCurrency, або ratingValue без reviewCount. Google ігнорує неповну розмітку.

Як проводити технічний SEO-аудит

Сканованість. robots.txt блокує потрібні сторінки (або навпаки, не блокує службові). Canonical URLs налаштовані неправильно — дублюються сторінки з UTM-мітками. Sitemap містить сторінки з noindex. Все це Screaming Frog або Sitebulb покажуть за годину сканування.

Core Web Vitals в масштабі. Google Search Console → Core Web Vitals → дивимося не окремі сторінки, а групи URL (шаблон сторінки продукту, шаблон категорії, блог). Проблема зазвичай системна — одна помилка в шаблоні псує сотні сторінок.

JavaScript SEO. Google рендерить JavaScript, але з затримкою (іноді дні для повного рендеру). Для критичного контенту — SSR або SSG обов'язкові. Перевіряємо через Search Console → Inspect URL → View Crawled Page: що бачить Googlebot.

Internal linking. Орфанні сторінки (немає вхідних внутрішніх посилань) втрачають PageRank. Бите посилання (404) — сигнал якості.

Що входить в роботу

• Документація: звіт зі знайденими проблемами, roadmap за пріоритетами, таймінги для кожного етапу.
• Доступи: налаштування моніторингу (SpeedCurve, Sentry Search Console), передача dashboard.
• Навчання: розбір типових помилок для вашої команди (1–2 дзвінки).
• Підтримка: супровід протягом місяця після деплою — перевірка метрик, фікс регресій.

Зв'яжіться з нами — ми оцінимо ваш проект за 2 дні і покажемо, скільки позицій можна повернути за рахунок технічного SEO. Досвід роботи з проектами рівня сотень тисяч відвідувань на місяць — гарантуємо вимірний результат в Core Web Vitals до/після. Замовте аудит у цій формі — отримайте персональний чек-лист з 15 пунктів.