Ми часто бачимо сайти, які втрачають 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 Які метрики впливають на швидкість?
| Метрика | Вага в score | Що вимірює |
|---|---|---|
| LCP | 25% | Завантаження найбільшого елемента |
| TBT (Total Blocking Time) | 30% | Час блокування main thread |
| CLS | 25% | Зсуви макету |
| FCP | 10% | Перше відображення контенту |
| Speed Index | 10% | Швидкість візуального заповнення |
TBT має найбільшу вагу і корелює з INP у реальних умовах. Сайти з великим бандлом JS без code splitting завжди мають високий TBT. Синтетика Lighthouse хороша, але реальні дані CrUX (Chrome User Experience Report) ще цінніші — вони показують, що бачать користувачі.
Порівняння Lighthouse та CrUX
| Характеристика | Lighthouse | CrUX |
|---|---|---|
| Тип | Синтетичний | Реальні користувачі |
| Умови | Контрольовані (Moto G4) | Різні пристрої/мережі |
| Дані | Одиничний тест | Агрегат за 28 днів |
| Застосовність | Будь-який сайт | Вимагає трафіку > 1000 унікальних |
Комбінація обох джерел дає повну картину: 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 увійдуть в зелену зону. Замовте аудит, щоб не гадати — ми покажемо, що і як виправити.