Аудит производительности сайта (Lighthouse/PageSpeed)

Аудит производительности сайта (Lighthouse/PageSpeed)

Lighthouse — автоматизированный инструмент аудита от Google. Запускается в Chrome DevTools, CLI или через PageSpeed Insights API. Производит синтетические замеры и выдаёт score 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 (critical CSS inline)
• Замена тяжёлых библиотек на легковесные альтернативы

Сроки аудита

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