Налаштування моніторингу Speed Index: інструменти, алерти, кейси

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

Speed Index — метрика, яку рідко оптимізують цілеспрямовано, хоча вона безпосередньо відображає користувацьке сприйняття завантаження. На відміну від LCP, яка фіксує момент появи одного елемента, Speed Index вимірює, як швидко візуально заповнюється весь видимий екран. Значення 0–3,4 секунди вважається хорошим за шкалою Lighthouse, але реальні цілі залежать від конкурентного оточення.

Що таке Speed Index технічно

Speed Index обчислюється за відеозаписом завантаження сторінки. Алгоритм (спочатку з WebPageTest) розбиває відео на кадри і для кожного моменту часу обчислює, який відсоток видимої області вже відмальовано. Підсумкове значення — інтеграл від «неповноти» за часом.

Спрощено:

SI = сума за всіма інтервалами (1 - візуальна_заповненість) * тривалість_інтервалу

Це означає: сторінка, яка заповнюється рівномірно, отримає кращий SI, ніж сторінка, яка довго стоїть порожньою і потім різко відмальовується.

Чому Speed Index — метрика, яку не можна ігнорувати?

Дослідження показують, що збільшення SI на 1 секунду знижує конверсію в середньому на 12%. При цьому SI більш чутливий до змін у рендерингу, ніж LCP: наприклад, додавання render-blocking CSS може погіршити SI на 25%, а LCP — лише на 10%. Тому моніторинг SI — це ранній сигнал проблем із сприйнятою продуктивністю.

Які інструменти для моніторингу обрати?

Вибір інструменту залежить від необхідної точності та бюджету. Порівняємо основні варіанти:

Lighthouse CI налаштовується в 3 рази швидше за WebPageTest, але поступається в точності на 10-15% для складних сторінок. WebPageTest виграє в точності, але складніший у підтримці. Для команд, які не бажають возитися з інфраструктурою, підійдуть комерційні сервіси.

Як налаштувати алерти в Slack за 5 хвилин

1. Створіть Webhook у Slack (Apps → Incoming Webhooks).
2. У конфігурації CI додайте крок надсилання сповіщення, якщо Speed Index перевищує поріг.
3. Перевірте: при деплої з регресією в Slack прийде повідомлення з посиланням на звіт.

Як ми налаштовуємо моніторинг: стек і конфігурація

Ми віддаємо перевагу комбінувати Lighthouse CI для щоденних прогонів і WebPageTest для глибинного аналізу. Розглянемо налаштування кожного.

WebPageTest self-hosted

Розгортаємо сервер та агента через Docker:

docker run -d -p 4000:80 \
  -e AGENTS=1 \
  --name wpt-server \
  webpagetest/server

docker run -d \
  --network host \
  -e SERVER_URL=http://localhost:4000 \
  -e LOCATION=Test \
  --cap-add=SYS_ADMIN \
  webpagetest/agent

Lighthouse CI з трекінгом SI

Встановлюємо та конфігуруємо @lhci/cli. Файл .lighthouserc.js:

module.exports = {
  ci: {
    collect: {
      url: ['https://staging.example.com/', 'https://staging.example.com/catalog/'],
      numberOfRuns: 3,
      settings: {
        preset: 'desktop',
        throttlingMethod: 'simulate',
        throttling: {
          rttMs: 40,
          throughputKbps: 10240,
          cpuSlowdownMultiplier: 1,
        },
      },
    },
    assert: {
      assertions: {
        'speed-index': ['warn', { maxNumericValue: 3400 }],
        'first-contentful-paint': ['error', { maxNumericValue: 2000 }],
      },
    },
    upload: {
      target: 'lhci',
      serverBaseUrl: 'https://lhci.internal.example.com',
      token: process.env.LHCI_TOKEN,
    },
  },
};

У GitHub Actions додаємо крок:

- name: Run Lighthouse CI
  run: |
    npm install -g @lhci/cli
    lhci autorun
  env:
    LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}
    LHCI_TOKEN: ${{ secrets.LHCI_TOKEN }}

Алертинг і пороги

Одиничне вимірювання SI ненадійне — метрика залежить від мережевих умов. Ми використовуємо медіану з 3–5 запусків і алерт при перевищенні ковзного середнього за 7 днів більш ніж на 20%. Приклад запиту для Grafana:

SELECT moving_average(mean("speed_index"), 7)
FROM "lighthouse_metrics"
WHERE time > now() - 30d
GROUP BY time(1d), "page"

Типові помилки при моніторингу Speed Index

• Запуск одного тесту: через флуктуації ви отримаєте хибне спрацьовування в 30% випадків. Використовуйте медіану з 3 прогонів.
• Ігнорування впливу серверної відповіді: TTFB може сильно викривляти SI. Переконайтеся, що бекенд стабільний.
• Відсутність контролю умов: throttling має бути однаковим для всіх тестів, інакше тренд буде шумним.

Що найбільше впливає на Speed Index

Speed Index деградує, коли:

• Render-blocking ресурси затримують першу відмальовку (CSS без media, синхронний JS)
• Шрифти завантажуються без font-display: swap — текст не відображається до завантаження
• Above-the-fold зображення без явних розмірів викликають layout shift
• Важкі inline-скрипти в <head> блокують парсер

Моніторинг Speed Index цінний як інтегральний сигнал: якщо SI зростає — з'явилася регресія в рендерингу першого екрану, і потрібно дивитися filmstrip у WebPageTest.

Що входить у налаштування

При замовленні послуги «під ключ» ми надаємо:

Ми гарантуємо, що після налаштування ви будете отримувати сповіщення про проблеми зі Speed Index не пізніше ніж через 15 хвилин після деплою.

Строки орієнтовно

Базова налаштування Lighthouse CI з трекінгом SI — 1–2 робочих дні. Self-hosted LHCI сервер з Grafana та Slack — 3–5 робочих днів. Повний стек з WebPageTest та автоматизацією через API — 1–2 тижні.

Оцінимо ваш проект безкоштовно — зв'яжіться з нами для консультації. Замовте налаштування і забудьте про раптові падіння продуктивності. Отримайте контроль над продуктивністю вже сьогодні.

Чому 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 пунктів.