Частые ошибки запуска

Некорректная установка или версия Node.js Lighthouse требует современную версию Node.js для корректной работы. Использование устаревших версий часто вызывает ошибки вроде Cannot find module 'puppeteer' или SyntaxError: Unexpected token. Рекомендуется проверять текущую версию Node через команду node -v и обновлять её до последней стабильной версии. Кроме того, при глобальной установке Lighthouse (npm install -g lighthouse) важно убедиться, что PATH корректно настроен, иначе команда lighthouse может быть не найдена.

Ошибки при запуске через CLI Запуск Lighthouse из командной строки часто сопровождается следующими проблемами:

• Неверный URL: Lighthouse не обрабатывает некорректные или неполные URL. Например, отсутствие http:// или https:// приводит к ошибке URL is invalid. Всегда использовать полный адрес.
• Слишком длинное время ожидания: Если страница загружается медленно или сервер отвечает с задержкой, анализ может завершиться ошибкой Timeout exceeded. Для CLI можно увеличивать таймаут через флаг --max-wait-for-load или --emulated-form-factor для более точного контроля загрузки.
• Недоступные ресурсы: Скрипты или шрифты, блокируемые CORS, могут вызвать некорректное формирование отчета. В отчете будут предупреждения типа Failed to load resource. Эти ошибки не всегда критичны, но влияют на точность оценки.

Ошибки при использовании API Node.js При интеграции Lighthouse через Node.js API частыми ошибками являются:

• Неправильная структура опций: Объект конфигурации должен строго соответствовать документации. Например, использование chromeFlags вне блока chromeLauncher вызывает ошибку Unknown option.
• Отсутствие указания пути к Chrome: Если chromePath не указан, а система не находит стандартный исполняемый файл, Lighthouse выдаст ошибку запуска браузера. Решение — явно указать путь к Chrome или использовать пакет chrome-launcher для автоматического поиска.
• Несинхронная обработка промисов: Node.js API возвращает промис, который нужно корректно обрабатывать через await или .then(). Ошибки типа Cannot read property 'lhr' of undefined возникают при попытке доступа к результату до завершения анализа.

Конфликты с уже запущенными экземплярами Chrome Lighthouse использует отдельный экземпляр Chrome, но иногда система путается, если другой процесс Chrome работает с пользовательским профилем. Результатом могут быть ошибки вида Chrome failed to start. Лучшей практикой является:

• Использовать опцию --disable-device-emulation для упрощения запуска на проблемных системах.
• Очистка профиля пользователя или запуск с флагом --user-data-dir для отдельного временного профиля.

Ошибки при запуске в CI/CD Автоматизированные среды (Jenkins, GitHub Actions, GitLab CI) часто сталкиваются с:

• Отсутствием графического интерфейса (headless): Chrome должен запускаться в headless-режиме через --headless. Без этого анализ не стартует.
• Недоступностью портов или ограничениями сети: Если сервер CI блокирует доступ к интернет-ресурсам, многие проверки Lighthouse (например, на внешние скрипты) выдадут ошибку.
• Недостатком ресурсов: Анализ страниц с тяжелыми скриптами в контейнерах с низкой памятью может приводить к сбоям Chrome и остановке Lighthouse.

Неправильная работа с профилями и кэшированием

• Повторное использование старых профилей: Иногда старые данные кэша или куки вызывают искажение метрик. Использование --clear-storage помогает запускать анализ с «чистого листа».
• Кэширование HTTP-запросов: Lighthouse может учитывать кэш браузера, что искажает результаты. Для корректного аудита важно очищать кэш между запусками или запускать в режиме --disable-storage-reset false.

Ошибки при анализе SPA (Single Page Application) Lighthouse может не корректно оценивать динамически подгружаемый контент, если страницы рендерятся через Jav * aScript:

• Недостаточное время на рендеринг: Фреймворки вроде React, Vue или Angular требуют времени для инициализации. Использование флага --max-wait-for-load или --throttling-method позволяет компенсировать это.
• Асинхронная подгрузка ресурсов: Если скрипты или данные загружаются после события load, Lighthouse может считать их недоступными. Для SPA рекомендуется использовать Puppeteer скрипт для ожидания полного рендеринга перед вызовом lighthouse().

Эти ошибки — самые распространенные препятствия при запуске Lighthouse. Их понимание и корректная обработка позволяют обеспечить стабильный и точный анализ производительности, доступности и SEO веб-страниц.