Как читать отчёт Lighthouse и исправлять найденные проблемы
Практика4 минРедакция Innovialabs
Коротко
Lighthouse — лабораторный тест, который оценивает производительность, доступность, лучшие практики и SEO; смотрите на метрики и проваленные аудиты, а не на одну цифру, запускайте тест в чистых условиях несколько раз и начинайте с картинок, JavaScript и блокирующих ресурсов.
Что на самом деле показывает отчёт Lighthouse
Lighthouse — автоматический аудит, встроенный в Chrome DevTools. Он загружает страницу в симулированной среде и ставит оценки в четырёх категориях: Performance, Accessibility, Best Practices и SEO. У каждой категории есть балл от 0 до 100, но ценность — ниже: метрики и список проваленных аудитов с конкретными элементами и файлами.
Главное, что нужно помнить: Lighthouse даёт лабораторные данные. Это одна загрузка, на одном симулированном устройстве, в один момент. Реальных пользователей измеряют полевые данные (например, Chrome UX Report в PageSpeed Insights). Lighthouse нужен, чтобы найти причины, а полевые данные — чтобы убедиться, что реальным людям стало быстрее.
Performance: какие метрики важны
Оценка Performance — взвешенная сумма нескольких метрик:
| Метрика | Что измеряет | Типичная причина плохого значения |
|---|---|---|
| LCP (Largest Contentful Paint) | Когда виден основной контент | Тяжёлая главная картинка, медленный сервер, блокирующий CSS |
| TBT (Total Blocking Time) | Сколько времени занят главный поток | Большие JS-бандлы, тяжёлые сторонние скрипты |
| CLS (Cumulative Layout Shift) | Насколько «прыгает» вёрстка | Картинки без размеров, поздние шрифты, вставляемые баннеры |
| FCP (First Contentful Paint) | Когда появляется хоть что-то | Блокирующие CSS/JS в head, медленный TTFB |
| Speed Index | Как быстро заполняется видимая область | То же, что у FCP и LCP |
Под метриками — блоки Opportunities (оценка возможной экономии) и Diagnostics (подробности). Самые частые аудиты:
- Properly size images / Serve images in next-gen formats — переведите картинки в WebP или AVIF и используйте
srcset. - Eliminate render-blocking resources — встройте критический CSS, добавьте скриптам
defer. - Reduce unused JavaScript — разделите код, уберите неиспользуемые библиотеки.
- Largest Contentful Paint image was lazily loaded — никогда не ставьте lazy-load на главную картинку.
- Avoid an excessive DOM size — упростите тяжёлые списки и лишние обёртки.
Accessibility, Best Practices и SEO
Эти категории — по сути чек-листы «прошёл/не прошёл», поэтому их проще довести почти до 100.
- Accessibility: низкий контраст, картинки без
alt, кнопки и ссылки без доступного имени, поля формы без label, нарушенный порядок заголовков. Автоматика ловит лишь часть проблем доступности — проверка с клавиатуры и скринридером всё равно нужна. - Best Practices: ошибки в консоли, смешанный HTTP/HTTPS-контент, устаревшие API, картинки с неверными пропорциями, библиотеки с известными уязвимостями.
- SEO: нет
titleили meta description, страница закрыта вrobots.txtилиnoindex, ссылки без понятного текста, слишком мелкие зоны нажатия, нет атрибутаlang.
Почему оценка меняется от запуска к запуску
Разные цифры на одной и той же странице — это нормально. Причины:
- Расширения браузера встраивают скрипты и замедляют страницу.
- Компьютер занят — другие вкладки, сборки, видеозвонки.
- Нестабильность сети и сервера — холодный кеш, маршрутизация CDN, A/B-тесты, реклама.
- Замедление симулируется, поэтому небольшие колебания времени усиливаются.
Как запускать правильно
- Откройте страницу в режиме инкогнито или в чистом профиле Chrome без расширений.
- Тестируйте продакшен-сборку, а не dev-сервер — режим разработки заведомо медленнее.
- Основная цель — Mobile: этот режим строже и ближе к большинству реальных посетителей.
- Запускайте 3-5 раз и смотрите на медиану, а не на лучший результат.
- В CI используйте Lighthouse CI с бюджетами производительности, чтобы ловить регрессии до релиза.
Какие исправления дают самый заметный эффект
Расставляйте приоритеты по влиянию на реальных пользователей, а не по размеру цифры «экономии»:
- Оптимизируйте LCP-элемент: сожмите главную картинку, отдавайте нужный размер, добавьте
fetchpriority="high"и preload, если браузер находит её поздно. - Сократите JavaScript: уберите лишние зависимости, загружайте сторонние виджеты (чаты, аналитику, карты) после взаимодействия или с
defer. - Резервируйте место под всё: задавайте
width/heightилиaspect-ratioкартинкам и встраиваемым блокам, используйтеfont-display: swapи похожие запасные шрифты. - Ускорьте ответ сервера: кеширование, CDN, меньше редиректов.
- Закройте аудиты доступности и SEO — обычно это быстрые победы, полностью под вашим контролем.
<img src="/hero-1200.webp"
srcset="/hero-600.webp 600w, /hero-1200.webp 1200w"
sizes="100vw" width="1200" height="600"
fetchpriority="high" alt="Панель управления продуктом">
Частые ошибки
- Гнаться за идеальными 100 вместо улучшения полевых метрик.
- Проверять только главную, хотя пользователи приходят на страницы товаров и статей.
- Ставить lazy-load на всё подряд, включая картинку на первом экране.
- Сравнивать оценки desktop и mobile, как будто это один и тот же тест.