Жизненный цикл аудита

Жизненный цикл аудита в Lighthouse начинается с подготовки окружения и конфигурации. На этом этапе формируется объект настроек, определяющий стратегию анализа:

  • тип устройства (mobile / desktop)
  • throttling (эмуляция сети и CPU)
  • список категорий и аудитов
  • режим запуска (navigation, timespan, snapshot)

Ключевым элементом является конфигурационный объект (Lighthouse config), который управляет всей дальнейшей цепочкой выполнения. Внутри него определяются:

  • passes — проходы по странице (например, загрузка, сбор trace)
  • audits — конкретные проверки
  • categories — группировка аудитов (Performance, SEO и др.)

Перед запуском также инициализируется соединение с браузером через Chrome DevTools Protocol (CDP). Обычно используется экземпляр Chromium, запущенный с флагом --remote-debugging-port.


Сбор данных (Gathering Phase)

Основная задача этапа — получение сырых данных о поведении страницы. Lighthouse выполняет серию проходов (passes), каждый из которых может включать:

  • навигацию к URL
  • запись trace (события выполнения)
  • сбор network logs
  • выполнение JavaScript в контексте страницы

Каждый проход описывается в конфигурации и может иметь собственные настройки.

Основные типы собираемых данных:

1. Trace (трассировка выполнения) Фиксирует события рендеринга, загрузки ресурсов, выполнение скриптов. Используется для анализа производительности.

2. DevTools Log (network log) Содержит информацию о сетевых запросах: тайминги, размеры, статус.

3. DOM snapshot Состояние DOM-дерева на момент завершения загрузки.

4. Artifacts (артефакты) Промежуточные структуры данных, создаваемые gatherers.


Gatherers

Gatherers — специальные модули, отвечающие за сбор конкретных типов данных. Каждый gatherer реализует интерфейс с методами жизненного цикла:

  • beforePass — выполняется перед началом прохода
  • pass — основной этап (часто используется редко)
  • afterPass — выполняется после завершения

Примеры gatherers:

  • сбор мета-тегов
  • анализ Service Worker
  • получение информации о viewport
  • извлечение данных о шрифтах

Результат работы gatherer — артефакт, который сохраняется в объекте artifacts.


Обработка артефактов

После завершения всех проходов начинается этап трансформации данных. На этом этапе:

  • нормализуются данные trace и network logs
  • формируются вычисляемые метрики (например, First Contentful Paint)
  • объединяются данные из разных источников

Артефакты становятся входными данными для аудитов.


Аудиты (Auditing Phase)

Аудиты — это изолированные проверки, каждая из которых анализирует артефакты и возвращает результат.

Каждый аудит реализует метод:

static audit(artifacts, context)

Структура результата аудита:

  • score — значение от 0 до 1
  • displayValue — человекочитаемый результат
  • details — дополнительные данные
  • numericValue — числовая метрика

Типы аудитов:

1. Performance audits Основаны на trace и network данных. Примеры:

  • Time to Interactive
  • Largest Contentful Paint

2. Accessibility audits Проверяют соответствие стандартам доступности (ARIA, контрастность).

3. Best Practices Анализируют безопасность и современные стандарты разработки.

4. SEO audits Проверяют мета-теги, индексацию, мобильную адаптацию.


Подсчёт метрик и скоринга

После выполнения всех аудитов начинается агрегирование результатов. Каждая категория имеет:

  • список аудитов
  • веса (weights) для каждого аудита

Пример расчёта:

Итоговый score категории вычисляется как взвешенная сумма:

score = Σ (audit_score × weight) / Σ weights

Для Performance используется более сложная модель, основанная на логарифмических кривых распределения (scoring curves).


Формирование отчёта (Reporting)

На основе результатов аудитов формируется финальный отчёт. Lighthouse поддерживает несколько форматов:

  • HTML
  • JSON
  • LHR (Lighthouse Result)

Основные блоки отчёта:

  • категории и их оценки
  • список аудитов
  • рекомендации по улучшению
  • diagnostics
  • passed audits

HTML-отчёт дополнительно включает визуализацию:

  • waterfall сетевых запросов
  • timeline загрузки
  • скриншоты этапов рендеринга

Рендеринг отчёта

HTML-отчёт генерируется с помощью шаблонов и включает:

  • интерактивные элементы
  • раскрывающиеся детали
  • фильтрацию аудитов

Отчёт можно встроить в CI/CD или использовать как standalone документ.


Завершение выполнения

После генерации отчёта происходит очистка:

  • закрытие соединения с браузером
  • завершение процессов Chromium
  • освобождение памяти

Если Lighthouse запускается программно, возвращается объект результата (LHR), который может быть использован для:

  • автоматической проверки качества
  • построения кастомных дашбордов
  • интеграции с системами мониторинга

Кастомизация жизненного цикла

Lighthouse предоставляет возможности для вмешательства в жизненный цикл:

1. Кастомные gatherers Добавление собственных источников данных.

2. Кастомные audits Создание специфичных проверок.

3. Переопределение конфигурации Изменение passes, throttling, категорий.

4. Плагины Расширение функциональности через plugin API.


Режимы выполнения

Жизненный цикл может отличаться в зависимости от режима:

Navigation mode Полный цикл: загрузка страницы + сбор всех метрик.

Snapshot mode Анализ уже загруженной страницы без навигации.

Timespan mode Сбор данных в течение пользовательского сценария (например, взаимодействие).

Каждый режим влияет на:

  • количество passes
  • тип собираемых данных
  • применяемые аудиты

Поток выполнения (Pipeline)

Общий pipeline Lighthouse выглядит следующим образом:

  1. Инициализация конфигурации
  2. Запуск браузера
  3. Выполнение passes
  4. Сбор артефактов
  5. Обработка данных
  6. Запуск аудитов
  7. Подсчёт скоринга
  8. Генерация отчёта
  9. Завершение работы

Взаимодействие с Chrome DevTools Protocol

На всех этапах жизненного цикла Lighthouse активно использует CDP:

  • управление навигацией
  • эмуляция условий сети и устройства
  • получение trace событий
  • доступ к DOM и runtime

Это позволяет Lighthouse работать на низком уровне и получать точные данные о поведении страницы.


Особенности асинхронности

Жизненный цикл построен на асинхронной модели:

  • gatherers работают с промисами
  • аудиты выполняются независимо
  • данные обрабатываются параллельно (где возможно)

Это обеспечивает:

  • масштабируемость
  • гибкость
  • возможность расширения

Обработка ошибок

На каждом этапе предусмотрена система обработки ошибок:

  • таймауты при загрузке страницы
  • ошибки выполнения gatherers
  • некорректные артефакты

Ошибки не прерывают весь процесс — Lighthouse старается вернуть максимально полный отчёт даже при частичных сбоях.


Кэширование и оптимизация

Для ускорения повторных запусков могут использоваться:

  • кэш сетевых запросов (опционально)
  • reuse браузерных процессов
  • оптимизация passes

Однако для точности результатов чаще используется чистая среда без кэша.


Влияние конфигурации на жизненный цикл

Каждое изменение конфигурации напрямую влияет на pipeline:

  • отключение trace → невозможность Performance аудитов
  • изменение throttling → другие метрики
  • исключение gatherers → отсутствие данных для аудитов

Таким образом, жизненный цикл Lighthouse — это гибкая, модульная система, в которой каждый этап тесно связан с конфигурацией и влияет на конечный результат анализа.