Аудит продуктивності сайту (Lighthouse/PageSpeed)

Ми часто бачимо сайти, які втрачають 30–50% конверсії через повільне завантаження. Lighthouse — автоматизований інструмент аудиту від Google — показує цифри, але не пояснює, що саме робити. Наш аудит не просто дає score, а виявляє конкретні причини поганих метрик і пропонує план виправлення. Досвід наших інженерів — більше 50 успішних проектів з прискорення веб-додатків. Типова картина: на десктопі все літає, а на мобільних при 3G сторінка завантажується 8 секунд, LCP зашкалює за 4 секунди, а CLS постійно червоний. Причина — неоптимізовані зображення, важкі JS-бандли і відсутність code splitting. Без детального аудиту ви будете гадати, що саме гальмує.

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

Як правильно запускати Lighthouse?

Синтетичні тести Lighthouse імітують Moto G4 на 4G з CPU throttling 4x. Це медіанний мобільний пристрій — на десктопі цифри будуть кращі. Для стабільних результатів:

• запускайте в інкогніто без розширень (розширення впливають на метрики);
• робіть 3–5 прогонів і беріть медіану (Lighthouse нестабільний ±10–20 балів);
• порівнюйте з конкурентами на тій самій методології.

# Lighthouse CLI — стабільніший за DevTools: розкид на 15-20% менше
npm install -g lighthouse

for i in 1 2 3; do
  lighthouse https://mysite.ru \
    --output json \
    --output-path "run-$i.json" \
    --chrome-flags="--headless" \
    --throttling-method=simulate \
    --preset=mobile
done

Які метрики впливають на швидкість?

TBT має найбільшу вагу і корелює з INP у реальних умовах. Сайти з великим бандлом JS без code splitting завжди мають високий TBT. Синтетика Lighthouse хороша, але реальні дані CrUX (Chrome User Experience Report) ще цінніші — вони показують, що бачать користувачі.

Порівняння Lighthouse та CrUX

Комбінація обох джерел дає повну картину: Lighthouse показує потенційні проблеми, CrUX — реальний досвід.

Чому TBT — найнебезпечніша метрика?

TBT безпосередньо пов'язаний з довгими задачами (>50ms) на основному потоці. Ми використовуємо DevTools Performance та Treemap для аналізу бандла. Типові винуватці: moment.js (67KB), lodash без tree-shaking, повний import import * as Icons from 'react-icons'. Аналіз бандла за допомогою webpack-bundle-analyzer показує, що можна викинути. Оптимізація може скоротити витрати на хостинг до 30% за рахунок зменшення навантаження на сервер.

# webpack-bundle-analyzer
npm run build -- --profile
npx webpack-bundle-analyzer dist/stats.json

Як покращити LCP?

LCP-елемент — часто найбільше зображення або текст. Типові проблеми:

<!-- Проблема: lazy-loading на LCP-елементі -->
<img src="hero.jpg" loading="lazy" ...>

<!-- Виправлення: eager + fetchpriority -->
<img src="hero.webp" loading="eager" fetchpriority="high" width="1200" height="500" alt="LCP hero image">

Якщо LCP — фонове зображення CSS, Lighthouse його не бачить як img. Рішення: перейти на <img> або додати <link rel="preload">. Згідно з Lighthouse на GitHub, додавання fetchpriority="high" може скоротити LCP на 15-20%.

Як боротися з CLS?

Причини layout shift:

• зображення без width/height;
• динамічно вставлені банери/рекламні блоки;
• шрифти з FOUT (Flash of Unstyled Text);
• skeleton screens з неправильними розмірами.

Діагностика через DevTools → Rendering → Layout Shift Regions (виділяє зеленим).

Типові помилки, що викликають CLS:

• Відсутність розмірів у зображень (завжди вказуйте width та height або використовуйте aspect-ratio).
• Рекламні вставки без резервування місця — задавайте мінімальну висоту контейнера.
• Динамічний контент, що завантажується після відображення — використовуйте min-height або skeleton.

Автоматизація з PageSpeed Insights API

Для автоматичного моніторингу після деплою використовуйте API:

PSI_KEY="YOUR_GOOGLE_API_KEY"
URL="https://mysite.ru/"

curl -s "https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=${URL}&key=${PSI_KEY}&strategy=mobile" | \
jq '{
  lcp: .lighthouseResult.audits["largest-contentful-paint"].displayValue,
  tbt: .lighthouseResult.audits["total-blocking-time"].displayValue,
  cls: .lighthouseResult.audits["cumulative-layout-shift"].displayValue,
  score: .lighthouseResult.categories.performance.score
}'

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

• Детальний звіт з оцінками за 4 категоріями Lighthouse (Performance, Accessibility, Best Practices, SEO);
• Пріоритизований список завдань з impact/effort (швидкі перемоги, середній рівень, серйозні рефакторинги);
• Конфігураційні файли (Lighthouse CLI, webpack) для самостійного моніторингу;
• Рекомендації з оптимізації Core Web Vitals з прикладами коду;
• Консультація та відповіді на запитання протягом 2 тижнів після здачі.

Орієнтовні терміни

Повний аудит (Lighthouse, DevTools трейс, аналіз бандла, CrUX дані, пріоритизований список завдань): 1–2 дні. Для великих сайтів з декількома типами сторінок (головна, каталог, товар, checkout) — 2–3 дні. Вартість розраховується індивідуально. Отримайте консультацію — зв'яжіться з нами по контактах на сайті. Ми гарантуємо, що після виконання рекомендацій ваш сайт пройде аудит Lighthouse на 90+ балів, а LCP, TBT та CLS увійдуть в зелену зону. Замовте аудит, щоб не гадати — ми покажемо, що і як виправити.

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