Как читать отчет Lighthouse без паники

Первое правило: ваша оценка — это не ваш сайт

Когда вы впервые открываете отчет Lighthouse, перед вами появляется стена чисел, цветных блоков и предупреждений о вещах, о которых вы никогда не слышали. Естественная реакция — паника. Оценка красная. Семнадцать проверок провалены. Наверняка сайт сломан?

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

Это важно, потому что большинство команд зацикливаются на оценке и теряют контекст. Оценка 65 может быть нормальной для сложного веб-приложения с данными в реальном времени. Оценка 95 все равно может сопровождаться плохим опытом, если оптимизированы не те вещи. Оценка — отправная точка для исследования, а не метрика успеха.

Что читать сначала: Core Web Vitals

Пропустите общую оценку производительности. Прокрутите вниз до раздела Metrics и посмотрите на три числа: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) и Interaction to Next Paint (INP). Это Core Web Vitals, и это единственные метрики производительности, которые Google использует как сигнал ранжирования.

• LCP измеряет, сколько времени требуется для отрисовки самого крупного видимого элемента. Цель: меньше 2,5 секунды. Если у вас больше 4 секунд, пользователи слишком долго ждут появления содержательного контента.
• CLS измеряет визуальную стабильность — насколько сильно страница «прыгает» во время загрузки. Цель: меньше 0,1. Если у вас больше 0,25, пользователи случайно нажимают не туда, потому что кнопки сместились.
• INP измеряет отзывчивость — как быстро страница реагирует на клики, касания и нажатия клавиш. Цель: меньше 200 мс. Если у вас больше 500 мс, сайт ощущается медленным.

Эти три метрики связаны с реальным раздражением пользователей. Исправьте их, прежде чем переживать о чем-либо еще.

Opportunities и Diagnostics: понимайте разницу

Lighthouse делит свои выводы на две категории: Opportunities и Diagnostics. Opportunities ранжируются по расчетной экономии времени. Diagnostics дают дополнительный контекст — вещи, которые могут быть проблемами, а могут и не быть.

Начните с Opportunities. Если Lighthouse говорит, что «Устранение ресурсов, блокирующих рендеринг» может сэкономить 1,2 секунды, это конкретный выигрыш. Если он говорит, что «Сокращение неиспользуемого JavaScript» может сэкономить 0,1 секунды, вероятно, рефакторинг того не стоит.

С Diagnostics сложнее. «Избегайте чрезмерного размера DOM» звучит тревожно, но если CLS в порядке, а INP быстрый, большой DOM может никому не мешать. Diagnostics — это подсказки, а не предписания. Исследуйте те, которые связаны с вашими фактическими метриками.

Аудиты, которые обычно можно игнорировать

Некоторые предупреждения Lighthouse устарели или чрезмерно агрессивны. Вот те, которые чаще всего вызывают ненужную панику:

• «Не используются passive listeners для повышения производительности прокрутки» — Это микрооптимизация, которая редко заметно влияет на результат. Если у вас нет признаков дерганой прокрутки, пропустите ее.
• «У элементов image не указаны явные width и height» — Это важно для CLS, но только если изображения вызывают сдвиги макета. Если CLS уже хороший, не делайте рефакторинг только ради аудита.
• «Предоставляйте изображения в форматах следующего поколения» — Да, WebP и AVIF меньше. Но если ваши изображения уже оптимизированы, а LCP быстрый, это приятное улучшение, а не кризис.
• «Избегайте слишком больших сетевых payloads» — Lighthouse помечает все, что больше 1,6 МБ. Но страница на 2 МБ, которая загружается быстро, лучше страницы на 500 КБ, которая блокирует рендеринг. Сосредоточьтесь на том, как доставляются байты, а не только на их общем объеме.

Что делать, когда все красное

Если ваша оценка Lighthouse ниже 50 и большинство аудитов не пройдено, вы, скорее всего, имеете дело с одной из трех первопричин:

1. Неоптимизированные шрифты. Веб-шрифты все еще дают самый простой выигрыш в производительности на большинстве сайтов. Проверьте, не загружаете ли вы шесть начертаний шрифта, когда используете только два, и не отправляете ли WOFF вместо WOFF2.
2. CSS и JavaScript, блокирующие рендеринг. Если ваш First Contentful Paint (FCP) больше 3 секунд, что-то мешает браузеру начать отрисовку. Ищите большие CSS-файлы или синхронные скрипты в <head>.
3. Слишком большие изображения. Если ваш элемент LCP — изображение размером 4 МБ, проблема в нем. Сожмите его, включите lazy-load для изображений ниже первого экрана и используйте синтаксис адаптивных изображений.

Исправьте одну из этих проблем и запустите Lighthouse снова. Часто вы увидите скачок на 20–30 пунктов. Затем переходите к следующей.

Лабораторные данные и полевые данные: проверка реальностью

Lighthouse работает в лаборатории. Он имитирует медленное соединение и медленное устройство, но не может имитировать реальное поведение пользователей: как люди прокручивают страницу, куда нажимают, сидят ли они на нестабильном Wi-Fi.

Для проверки реальностью сравните результаты Lighthouse с полевыми данными из Chrome User Experience Report (CrUX). CrUX показывает, как реальные пользователи Chrome воспринимали ваш сайт за последние 28 дней. Если Lighthouse говорит, что ваш LCP равен 4 секундам, а CrUX показывает 2 секунды, доверяйте CrUX. Если оба результата плохие, у вас реальная проблема.

Данные CrUX можно найти в PageSpeed Insights (веб-версии Lighthouse) или в Google Search Console в разделе «Core Web Vitals». Если результаты расходятся, выясните почему. Возможно, реальные пользователи находятся в более быстрых сетях. Возможно, Lighthouse тестирует неоптимизированную dev-сборку.

Когда повторно запускать Lighthouse

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

Чтобы получить стабильную базовую линию, запускайте Lighthouse в режиме инкогнито со всеми отключенными расширениями или используйте CLI с флагом --preset=desktop для более стабильных результатов. Запустите его три раза и усредните оценки. Если вы видите сильные колебания (больше 10 пунктов), что-то еще не так: возможно, сервер медленный или страница каждый раз загружает разные ресурсы.

Повторно запускайте Lighthouse после каждого значимого изменения. Внедрили новую стратегию шрифтов? Проверьте LCP. Включили lazy-load изображений? Проверьте CLS. Добавили сторонний скрипт? Проверьте INP. Производительность — не разовое исправление; это бюджет, который нужно защищать.

Инструменты, которые помогают действовать по выводам Lighthouse

Lighthouse говорит, что работает медленно. Но он не всегда говорит, как это исправить. Для этого нужны дополнительные инструменты:

• WebPageTest дает покадровое представление загрузки страницы в виде filmstrip. Это важно для диагностики проблем LCP и CLS.
• Панель Performance в Chrome DevTools показывает, какой именно JavaScript блокирует главный поток. Используйте ее, чтобы найти источник плохой оценки INP.
• Инструменты сжатия изображений позволяют оптимизировать изображения прямо в браузере — это быстрее и приватнее, чем загрузка в сторонний сервис. Обработка изображений на стороне клиента полезна для приватности, потому что ваши изображения никогда не покидают ваш компьютер.

Lighthouse — отправная точка. Эти инструменты помогают довести работу до конца.

Ключевые выводы

• Ваша оценка Lighthouse — лабораторный бенчмарк, а не мера реального пользовательского опыта. Прежде чем паниковать, сравните ее с полевыми данными CrUX.
• Сначала сосредоточьтесь на Core Web Vitals (LCP, CLS, INP). Это метрики, которые связаны с раздражением пользователей и влиянием на SEO.
• Расставляйте приоритеты в Opportunities по расчетной экономии времени. Игнорируйте Diagnostics, которые не связаны с вашими фактическими проблемами производительности.
• Некоторые аудиты — например, passive listeners или форматы изображений следующего поколения — это микрооптимизации. Сначала исправляйте крупные проблемы.
• Запустите Lighthouse три раза и усредните результаты. Производительность изменчива, и один запуск может ввести в заблуждение.

FAQ

Q: Почему моя оценка Lighthouse меняется при каждом запуске?
A: Lighthouse измеряет производительность в изменчивых условиях: скорость сети, загрузка CPU и эвристики браузера влияют на результат. Запустите его три раза в режиме инкогнито и усредните оценки, чтобы получить более стабильную базовую линию.

Q: Сначала оптимизировать mobile или desktop?
A: Mobile. По умолчанию Lighthouse использует мобильную симуляцию, потому что большая часть веб-трафика приходит с мобильных устройств, а мобильные устройства медленнее. Если ваша mobile-оценка хорошая, desktop-оценка обычно тоже будет в порядке.

Q: Моя оценка Lighthouse — 95, но сайт все равно ощущается медленным. Что не так?
A: Lighthouse измеряет загрузку страницы, а не интерактивность после загрузки. Проверьте оценку INP и используйте панель Performance в Chrome DevTools, чтобы профилировать, что происходит, когда пользователи кликают или прокручивают страницу. Возможно, у вас проблема с JavaScript, которую Lighthouse не ловит.

Q: Нужна ли мне идеальная оценка 100?
A: Нет. Оценка 90+ — отличный результат. Погоня за 100 часто означает оптимизацию того, что не важно пользователям. Сосредоточьтесь на реальных метриках — LCP, CLS, INP — и не зацикливайтесь на оценке.

Q: Можно ли доверять Lighthouse, если я использую много сторонних скриптов?
A: Lighthouse отметит сторонние скрипты как проблему, но он не всегда может отличить необходимые от ненужных. Используйте аудиты «Избегайте слишком больших сетевых payloads» и «Сокращение времени выполнения JavaScript», чтобы определить худших нарушителей, а затем решите, стоит ли их оставлять.

Sources

• «Lighthouse performance scoring» — Google Developers
• «Core Web Vitals» — web.dev
• «Chrome User Experience Report» — Google Developers
• «WebPageTest Documentation» — WebPageTest.org