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

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

Lighthouse — автоматизований інструмент аудиту від Google. Запускається в Chrome DevTools, CLI або через PageSpeed Insights API. Виробляє синтетичні вимірювання та видає оцінку 0–100 по чотирьох категоріях: Performance, Accessibility, Best Practices, SEO. Аудит продуктивності — це не тільки отримати цифру, але й розібратися в пріоритетах поліпшень і відтворювати вимірювання стабільно.

Методологія вимірювання

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

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

# Lighthouse CLI — стабільніше за DevTools (немає інших вкладок)
npm install -g lighthouse

# 3 прогони, взяти медіану
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.

Структура аудиту

Етап 1 — Інвентаризація ресурсів

Lighthouse → Network → дивитися на waterfall:

• Render-blocking ресурси (червоні строки): CSS без media, JS без defer/async
• Час до First Byte (TTFB) — якщо > 600ms, проблема на сервері
• Розмір сторінки: HTML > 100KB, JS > 300KB (unparsed), зображення без WebP

Етап 2 — LCP-елемент

Lighthouse вказує конкретний DOM-елемент для 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="Hero">

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

<link rel="preload" as="image"
      href="/images/hero.webp"
      imagesrcset="/images/hero-400.webp 400w, /images/hero-800.webp 800w, /images/hero.webp 1200w"
      imagesizes="100vw">

Етап 3 — TBT та Long Tasks

Lighthouse → View Treemap → показує бандл за розміром
DevTools → Performance → Long Tasks (червоні смуги > 50ms)

Аналіз бандла:

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

Типові винуватці: moment.js (67KB), lodash без tree-shaking, повний import import * as Icons from 'react-icons'.

Етап 4 — CLS

Причини layout shift:

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

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

PageSpeed Insights 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
}'

PageSpeed Insights використовує дані CrUX (Chrome User Experience Report) якщо сторінка має достатній трафік — це дані з реальних користувачів, цінніше синтетики.

Пріоритизація завдань

Після аудиту список поліпшень ранжується за impact/effort:

Швидкі перемоги (1–2 години кожна):

• Додати width/height на всі <img> — видаляє CLS
• Додати defer на не-критичні скрипти — знижує TBT
• Включити gzip/brotli на сервері — зменшує transfer size
• Додати font-display: swap — знижує LCP якщо винуватець шрифт

Середній рівень (1–3 дні):

• Code splitting для JS-бандла — знижує TBT/FCP
• Конвертація зображень у WebP — зменшує transfer size 25–40%
• Lazy loading для off-screen зображень — зменшує initial load

Серйозні рефакторинги (1–2 тижні):

• Перенесення важких віджетів з SSR на динамічне завантаження
• Видалення render-blocking CSS (inline critical CSS)
• Заміна важких бібліотек на легковесні альтернативи

Терміни аудиту

Повний аудит (Lighthouse, DevTools трейс, аналіз бандла, дані CrUX, пріоритизований список завдань): 1–2 дні. Для великих сайтів з кількома типами сторінок (головна, каталог, товар, checkout) — 2–3 дні.