Lighthouse — аудит качества сайта

1. Где запускается Lighthouse

• Chrome DevTools → вкладка Lighthouse (курс);
• CLI: npx lighthouse URL с опциями;
• PageSpeed Insights — онлайн-версия Google;
• CI — lighthouse-ci в пайплайне деплоя.

npm install -g lighthouse
lighthouse https://example.com --only-categories=performance --output=json --output-path=./lh.json
lighthouse https://example.com --view   # открыть отчёт в браузере

2. Категории оценок

Шкалы: 0–49 красный, 50–89 жёлтый, 90–100 зелёный.

3. Performance: ключевые метрики

• FCP (First Contentful Paint) — первый контент на экране;
• LCP (Largest Contentful Paint) — крупнейший элемент виден;
• CLS (Cumulative Layout Shift) — «прыжки» макета;
• INP (Interaction to Next Paint) — отзывчивость на клики;
• TBT (Total Blocking Time) — время блокировки главной нити.

4. Core Web Vitals

Три метрики, которые Google реально использует в ранжировании: LCP, INP, CLS. Целевые значения:

5. Причины плохого LCP

• сервер отдаёт HTML долго → «медленная» отдача контента;
• главное изображение загружается с большим весом и без priority;
• CSS рендер-блокирующий, шрифты блокируют текст;
• спустительный preload отсутствует для критичного ресурса.

<img src="hero.webp" width="1200" height="600"
     fetchpriority="high" decoding="async" alt="Герой" />

<link rel="preload" href="/fonts/inter.woff2" as="font" crossorigin />
<link rel="preload" href="/styles.css" as="style" />

6. Accessibility (доступность)

Аудит проверяет: контраст, альт-тексты, aria-роли, структуру заголовков и доступность с клавиатуры:

<button aria-label="Закрыть окно">×</button>
<img src="logo.svg" alt="Логотип компании" />
<input aria-describedby="hint" />
<p id="hint">От 6 до 20 символов</p>

7. Best Practices

Проверки безопасности и современности:

• HTTPS — обязателен, за это сразу снижается оценка;
• отсутствие опасных зависимостей и deprecated API;
• корректный код viewport, charset, небыстрый favicon;
• правило: никаких alert() и console.log в проде.

8. SEO

Базовые проверки SEO в Lighthouse:

<title>Название страницы</title>
<meta name="description" content="Короткое описание" />
<link rel="canonical" href="https://site.ru/page" />
<html lang="ru">

Также проверяются: роботики файлы robots.txt, структура заголовков h1–h6, отсутствие дублей с meta robots, правильные атрибуты alt.

9. Как улучшить Performance

1. смотри отчёт → жми самую низкую метрику → секцию с проблемой — Lighthouse объяснит каждую;
2. оптимизируй изображения: WebP/AVIF, srcset, размеры;
3. выноси CSS в критические inline-части, остальное — async;
4. лениво грузи картинки/iframe: loading="lazy";
5. сократи путь JS и разбей на чанки (курс Webpack, Vite);
6. обнови кэш-стратегии и шрифты (unicode-range).

// отложенная инициализация некритичного скрипта
<script defer src="analytics.js"></script>
<img src="photo.webp" loading="lazy" alt="Фото" />

10. Lighthouse в CI

Следи за метриками при каждом деплое:

npm install -D @lhci/cli

// lighthouserc.json
{
  "ci": {
    "collect": { "url": ["https://example.com"], "numberOfRuns": 3 },
    "assert": {
      "assertions": {
        "categories:performance": ["error", { "minScore": 0.9 }],
        "categories:accessibility": ["error", { "minScore": 0.95 }],
        "categories:seo": ["error", { "minScore": 0.95 }]
      }
    }
  }
}

npx lhci autorun

11. Устройства и эмуляция

Lighthouse по умолчанию прогоняет мобильную конфигурацию: эмуляция экрана, throttling CPU и сети. Для десктопа или реальной сети пресет меняется флагом:

lighthouse https://example.com --preset=desktop
lighthouse https://example.com --throttling-method=devtools

• simulate — математическая модель загрузки, быстро, но приближённо.
• devtools — реальное ограничение сети, точнее для латентных сценариев.
• provided — без троттлинга, замер на твоём канале.

12. Чтение отчёта: trace загрузки

Самый информативный раздел — View Trace: водопад запросов, где каждая полоска показывает время запроса, размер и длительность обработки. Ищи длинные «островки» работы главного потока и ресурсы, блокирующие рендер.

• Повторные запросы к тому же URL — потеря кэширования.
• Большой js/css до первого отрисовываемого контента — критический путь забит.
• Высокий TBT указывает на тяжёлые скрипты, которые двигаются вниз водопада.

13. Прогон из Node.js и Puppeteer

Библиотека lighthouse позволяет запускать аудит программно и встраивать в свои скрипты:

const lighthouse = require('lighthouse');
const { launch } = require('chrome-launcher');

(async () => {
  const chrome = await launch({ chromeFlags: ['--headless'] });
  const result = await lighthouse('https://example.com', {
    port: chrome.port, onlyCategories: ['performance']
  });
  console.log(result.lhr.categories.performance.score);
  await chrome.kill();
})();

Так можно аудитить целые списки страниц, сравнивать версии и сохранять историю показателей в базу.

14. Бюджеты производительности

Бюджеты фиксируют предельные метрики кода — превышение валит сборку. В Webpack они настраиваются декларативно:

performance: {
  budgets: [
    { resourceType: 'script', budget: 250000, resourceSizes: ['script'] },
    { resourceType: 'total', budget: 700000 }
  ]
}

Аналогично Lighthouse умеет брать бюджет из JSON-файла при прогоне (--budget-path=budget.json) и проверять, укладывается ли страница в лимиты по JS, CSS, изображениям и запросам.

15. SPA и клиентский рендеринг

Одностраничные приложения (React/Vue) аудируются иначе, чем статичные сайты: контент рендерится в браузере, и Lighthouse видит лишь то, что успело отобразиться:

npx lighthouse http://spa.example.com \
    --disable-storage-reset=false \
    --output=json --output-path=spa.json

• CSR-пустой #app до загрузки JS — пустые метрики, а не «быстро».
• Рендерись на сервере (SSR) или используй SSG: содержательный HTML приходит первым пакетом.
• Гидратация и lazy-чувствительность: разбивай bundle на маршруты и откладывай второстепенные библиотеки.

16. Field Data: реальные метрики в проде

Лабораторный прогон на их машине — это эталон, а не правда. Полевые данные (RUM) собирает браузер реальных пользователей — через web-vitals:

import { onLCP, onCLS, onINP } from "web-vitals";
onLCP(({ value }) => sendToAnalytics("lcp", value));

• web-vitals — официальная библиотека; точность лучше, чем ручные замеры.
• Сопоставляй полевые метрики с лабораторным профилем: RUM показывает «что реально», Lighthouse — «почему».
• Квартили важнее среднего: p75/p90 ловят медленных пользователей — на них и смотрят.

17. Мониторинг и алерты в проде

Производительность не останавливается после релиза. Регулярные прогоны и их сравнение держат метрики в бюджете, а не только на странице отчёта:

Алерты срабатывают по регрессу, а не по порогу: изменение LCP на 30% к базе — сигнал, даже если лимит не превышен.

18. Чек-лист аудита перед релизом

Перед выкаткой собери обзорную картину: это и финальный самоконтроль, и документ для команды, где «хорошо», а где дыры.

npx lighthouse https://staging.example.com --preset=desktop \
    --output=json --output-path=release/lh.json \
    --only-categories=performance,accessibility

• Прогони десктоп и мобильник: должные лимиты разные, а в бюджетах — обе структуры.
• Собери метрики до/после: если релиз улучшает LCP, зафиксируй это в отчёте PR.
• Проверь, что двойные условия alt, контрасты и семантика доступности не «раскраснелись» после рефакторинга.

19. JavaScript: Long Tasks и INP

Медианный LCP может быть зелёным, а сайт всё равно «тупит» при взаимодействии. Причина — тяжёлые Long Tasks, блокирующие главный поток.

new PerformanceObserver((list) => {
  for (const e of list.getEntries()) {
    console.log('Long Task', e.duration, e.startTime)
  }
}).observe({ type: 'longtask', buffered: true })

• Long Tasks длиннее 50 мс задерживают клики и сдвигают INP.
• Code-splitting и ленивая загрузка делят главный бандл на исполняемые куски.
• Тяжёлые анимации переносите на requestAnimationFrame, а херувимскую работу — в Web Worker.

20. Сторонние ресурсы

Метрики нередко падают не из-за сайта, а из-за тегов аналитики, чатов и consent-баннеров. Сторонний код надо включать в аудит.

• Каждый <script src> — потенциальная точка блокировки главного потока.
• Считайте реальную стоимость тега в trace: время до FCP и вклад в INP.
• Self-host аналитики (Plausible, Umami) убирает DNS, TLS и сдвиг по сторонним CDN.

web-vitals: check(INP, 200)

21. Сетевой слой: HTTP/2/3 и кэширование

Браузер сам не догадается, как качать ресурсы: политику кэша, приоритизацию и протоколы настраивает сервер.

• HTTP/2 мультиплексирует запросы, HTTP/3 добавляет устойчивость к потере пакетов.
• preconnect и dns-prefetch заранее резервируют соединения.
• Кэш: long-lived для хешированных ассетов, no-cache для HTML.

<link rel="preconnect" href="https://img.cdn.example.com">
<link rel="preload" as="image" href="hero.avif">

22. Стабильные прогоны и тренды

Lighthouse «прыгает» от прогона к прогону: фон процессов, сеть, кэш. Уберите шум и слушайте тенденцию, а не одиночный результат.

• Запускайте минимум пять прогонов и берите медиану, а не лучший или худший.
• Отключайте кэш только если тестируете первый визит; при замерах со стабильным кэшем держите его включённым.
• В CI используйте одно и то же эмулируемое окружение и метод троттлинга.

lighthouse https://site --preset=desktop --throttling-method=simulate

Что дальше

Оптимизируй реальную страницу: сначала аудит → затем исправления → повторный аудит. Разметку потренируешь в HTML и CSS, картинки и анимации — в JavaScript, стили — в Sass. Смотреть в деталях данные сети и загрузки поможет Chrome DevTools.

← Вернуться к курсам