Специфические рекомендации

Настройка и конфигурация

Lighthouse предоставляет гибкую систему конфигурации, позволяя точечно управлять аудитами и их параметрами. Основной способ настройки — передача объекта конфигурации при запуске:

const lighthouse = require('lighthouse');
const chromeLauncher = require('chrome-launcher');

(async () => {
  const chrome = await chromeLauncher.launch({chromeFlags: ['--headless']});
  const options = {port: chrome.port, output: 'json'};
  const config = {
    extends: 'lighthouse:default',
    settings: {
      onlyCategories: ['performance', 'accessibility']
    }
  };
  const result = await lighthouse('https://example.com', options, config);
  await chrome.kill();
})();

Ключевые моменты конфигурации:

  • extends: позволяет наследовать стандартные конфигурации Lighthouse (default, lighthouse:full).
  • settings.onlyCategories: ограничивает аудит определёнными категориями.
  • settings.emulatedFormFactor: задаёт эмуляцию устройства (desktop или mobile).
  • settings.throttlingMethod: выбирается между devtools и simulate, что влияет на точность измерений сетевых и вычислительных задержек.

Настройка аудитов под специфические сценарии

Для крупных проектов с высокой нагрузкой важно контролировать, какие аудиты выполняются. Излишние проверки увеличивают время отчёта, а в некоторых случаях могут искажать результаты. Например, отключение аудита сторонних скриптов:

const config = {
  extends: 'lighthouse:default',
  settings: {
    audits: [
      'uses-rel-preconnect',
      'unused-javascript'
    ]
  }
};

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

Управление сессиями Chrome

Запуск Lighthouse в headless-режиме позволяет интегрировать анализ в CI/CD, но требует грамотного управления экземплярами Chrome. Оптимальная стратегия:

  • Использовать chromeLauncher.launch() с флагами --headless, --no-sandbox.
  • Закрывать процесс через chrome.kill(), чтобы не оставлять зависшие процессы.
  • В сложных сценариях с множеством URL рекомендуется переиспользовать порт Chrome для последовательных проверок.

Анализ отчетов

Результат работы Lighthouse представлен в виде JSON-объекта с разделами:

  • categories: оценки по категориям (performance, accessibility, best-practices, seo, pwa).
  • audits: детализированные результаты конкретных проверок.
  • timing: временные метрики для диагностики медленных участков загрузки.

Пример анализа конкретного аудита:

const performanceScore = result.lhr.categories.performance.score * 100;
const firstContentfulPaint = result.lhr.audits['first-contentful-paint'].displayValue;

console.log(`Performance: ${performanceScore}`);
console.log(`FCP: ${firstContentfulPaint}`);

Использование кастомных аудитов

Lighthouse поддерживает добавление собственных аудитов. Структура кастомного аудита включает:

  • Метаданные (meta) с названием, описанием и категорией.
  • Метод audit(), который получает данные страницы через Puppeteer или DevTools Protocol и возвращает объект с score, displayValue и details.

Пример базового кастомного аудита:

class CustomAudit extends Audit {
  static get meta() {
    return {
      id: 'custom-audit',
      title: 'Проверка наличия определенного элемента',
      category: 'performance',
      description: 'Проверяет, что на странице присутствует элемент с id="target"'
    };
  }

  static async audit(artifacts) {
    const elementExists = await artifacts.Page.evaluate(() => !!document.querySelector('#target'));
    return {
      score: elementExists ? 1 : 0,
      displayValue: elementExists ? 'Элемент найден' : 'Элемент отсутствует'
    };
  }
}

Интеграция в процессы CI/CD

Для автоматического контроля качества страниц в проекте Lighthouse можно запускать через npm-скрипты или Node.js-скрипты, с последующей обработкой JSON-результатов. Важные рекомендации:

  • Парсить только необходимые метрики для ускорения анализа.
  • Хранить результаты в формате JSON для последующей визуализации и сравнения.
  • Использовать пороговые значения (score >= 0.9) для автоматического пропуска или остановки сборки.

Практики ускорения и оптимизации

  1. Параллельный запуск нескольких URL с контролем портов Chrome.
  2. Ограничение количества аудитов и категорий для быстрого тестирования изменений.
  3. Кэширование ресурсов страницы при повторных проверках для уменьшения времени анализа.
  4. Эмуляция устройств и сети строго по сценариям тестирования, чтобы результаты были сопоставимы между прогоном и прогоном.

Учет специфики страниц с динамическим контентом

Для SPA и страниц с динамическим контентом важно дождаться полной загрузки элементов перед запуском аудита. Для этого:

  • Использовать метод await page.waitForSelector() через Puppeteer.
  • Передавать готовую страницу в Lighthouse через artifacts.
  • Контролировать задержки загрузки через таймауты, чтобы не получать ложноположительные оценки по времени загрузки.

Эти рекомендации позволяют использовать Lighthouse не только для базового анализа, но и для глубокого, управляемого мониторинга качества веб-приложений с учётом особенностей производительности, доступности и SEO.

Оглавление