Привет, я Максим, веб-разработчик. Google Lighthouse — бесплатный инструмент аудита сайта, который проверяет производительность, доступность, SEO и лучшие практики. Он встроен в Chrome DevTools и доступен каждому владельцу сайта. Но я регулярно вижу, как люди запускают Lighthouse, видят цифры — и не понимают, что с ними делать. Какие показатели критичны, какие можно отложить, за что браться в первую очередь — разбираю подробно.
Как правильно запустить Lighthouse
Базовый способ: открываете Chrome, переходите на нужную страницу, нажимаете F12 (DevTools), вкладка Lighthouse, выбираете категории для проверки, нажимаете «Generate report». Альтернатива — онлайн-версия на PageSpeed Insights (pagespeed.web.dev), которая дополнительно показывает данные реальных пользователей из CrUX (Chrome User Experience Report).
Но есть нюансы, которые влияют на результат. Первый: всегда запускайте в режиме инкогнито. Расширения браузера (особенно блокировщики рекламы и менеджеры паролей) искажают результаты — они добавляют свои скрипты, замедляют рендеринг. Второй: выбирайте мобильный пресет, а не десктопный. Большинство пользователей заходят на сайт с мобильных устройств, и именно мобильный опыт учитывается Яндексом и Google при ранжировании. Десктопные показатели почти всегда лучше — но это ложное спокойствие.
Третий нюанс, который многие упускают: Lighthouse эмулирует медленное мобильное устройство и ограниченную сеть. Ваш мощный MacBook покажет сайт за секунду, но Lighthouse имитирует средний Android-смартфон с 4G-подключением. Именно поэтому результаты могут выглядеть хуже, чем вы ожидаете, — и именно поэтому они ближе к реальности.
Четыре категории оценки
Lighthouse даёт оценку от нуля до ста по четырём категориям. Разберу каждую.
Performance (Производительность). Самая важная и самая сложная категория. Оценка 90–100 — отлично, ваш сайт загружается быстро. 50–89 — есть что оптимизировать, и пользователи это чувствуют. Ниже 50 — серьёзные проблемы, которые напрямую влияют на конверсию и ранжирование. Для коммерческого сайта я рекомендую целиться в 80 и выше на мобильных. Достичь 100 при наличии аналитики, виджетов чата и динамического контента — практически невозможно, и не нужно к этому стремиться.
Accessibility (Доступность). Проверяет, доступен ли сайт для людей с ограниченными возможностями: достаточный контраст текста и фона, наличие alt-атрибутов у изображений, семантическая HTML-разметка, работа с клавиатурой. Кажется второстепенным, но на практике многие из этих критериев совпадают с лучшими практиками SEO и UX. Цель — 90 и выше. Исправление доступности часто улучшает и другие показатели.
Best Practices (Лучшие практики). Проверяет наличие HTTPS, отсутствие ошибок в консоли браузера, корректные заголовки безопасности, использование современных API. Цель — 95 и выше. Обычно это самая «лёгкая» категория для улучшения: ошибки здесь — чаще всего технические недоработки, которые исправляются за час-два.
SEO. Проверяет мета-теги (title, description), адаптацию под мобильные, наличие robots.txt, canonical-тегов, правильную структуру заголовков. Цель — 95 и выше. Если Lighthouse показывает ниже 90 в SEO — значит, пропущены базовые вещи, которые нужно исправить немедленно.
Core Web Vitals: три метрики, на которые смотрят поисковики
Core Web Vitals — это набор из трёх метрик, которые Google официально использует как фактор ранжирования, и Яндекс тоже учитывает их (пусть и менее явно). Lighthouse измеряет все три.
LCP (Largest Contentful Paint) — время загрузки самого большого видимого элемента на первом экране. Обычно это hero-изображение, видео-обложка или крупный блок текста. Хорошо — до 2.5 секунд. Приемлемо — до 4 секунд. Плохо — больше 4 секунд. Как улучшить: оптимизировать главное изображение (перевести в WebP, подобрать правильный размер, не загружать картинку 3000 пикселей для блока шириной 600), использовать CDN для статики, добавить preload для критических ресурсов (шрифтов, hero-изображения), оптимизировать серверное время ответа (TTFB).
INP (Interaction to Next Paint) — отзывчивость сайта, то есть время от клика пользователя до визуального отклика интерфейса. Эта метрика заменила FID (First Input Delay) и является более комплексной — она учитывает все взаимодействия на странице, а не только первое. Хорошо — до 200 миллисекунд. Плохо — больше 500. На практике высокий INP означает, что сайт «тормозит» при клике: пользователь нажимает кнопку, а ничего не происходит секунду-две. Как улучшить: разбить длинные задачи JavaScript на короткие (yield to main thread), отложить загрузку некритичных скриптов (defer, async), минимизировать блокировку основного потока тяжёлыми вычислениями, оптимизировать обработчики событий.
CLS (Cumulative Layout Shift) — визуальная стабильность, то есть насколько элементы «прыгают» при загрузке страницы. Знакомая ситуация: вы начинаете читать текст, и вдруг он сдвигается вниз, потому что подгрузилась реклама или изображение. Хорошо — до 0.1. Плохо — больше 0.25. Как улучшить: всегда задавать атрибуты width и height для изображений и iframe (чтобы браузер зарезервировал место), использовать font-display: swap для веб-шрифтов, не вставлять контент динамически выше видимой области, зарезервировать место для рекламных блоков и виджетов через CSS.
Что исправлять в первую очередь: принцип максимального эффекта
Lighthouse показывает список рекомендаций с оценкой потенциального влияния (estimated savings). Мой подход — начинать с тех, где максимальный эффект при минимальных затратах времени.
Сжатие и оптимизация изображений — почти всегда первый приоритет. На большинстве сайтов именно изображения составляют 60–80% веса страницы. Конвертация в WebP, правильный подбор размеров, сжатие — часто даёт прирост +10–20 баллов Performance. Lazy loading для изображений ниже первого экрана — следующий шаг, который требует минимальных усилий (один атрибут loading="lazy").
Удаление неиспользуемого CSS и JavaScript. Lighthouse показывает, какой процент загруженного кода реально используется на странице. Если 60% CSS не применяется — это мёртвый вес, который замедляет загрузку. Инструменты типа PurgeCSS или анализ покрытия (Coverage в DevTools) помогают найти и удалить лишнее.
Настройка кеширования — бесплатное ускорение для повторных визитов. Заголовки Cache-Control для статических ресурсов (изображений, CSS, JS) со сроком жизни от 30 дней. Добавление alt-текстов к изображениям — улучшает и Accessibility, и SEO.
Типичные ошибки при работе с Lighthouse
Первая — гонка за сотней. Я встречал клиентов, которые требовали «100/100 в Lighthouse» как обязательное условие приёмки сайта. Для сайта с Яндекс Метрикой, чатом Jivo, виджетом обратного звонка и встроенной картой — это нереально. Каждый внешний скрипт отнимает баллы, и это нормально. 80–90 на мобильных — отличный результат для коммерческого сайта.
Вторая — замер один раз и навсегда. Оценка Lighthouse зависит от множества факторов: нагрузки на сервер, скорости вашего интернета, мощности компьютера. Один запуск может показать 72, а следующий — 81. Я рекомендую запускать три-пять раз и ориентироваться на медианное значение. Для серьёзного мониторинга — используйте web.dev/measure или настройте автоматические проверки через GitHub Actions с Lighthouse CI.
Третья — игнорирование мобильных результатов. Десктопный отчёт показывает 95, и клиент успокаивается. Но мобильный показывает 48. А 70% трафика — с мобильных. Ориентируйтесь всегда на мобильный пресет.
Как встроить Lighthouse в рабочий процесс
Я рекомендую запускать аудит Lighthouse минимум раз в месяц — после каждого обновления сайта и при публикации нового контента. Для разработчиков — идеально интегрировать Lighthouse CI в пайплайн деплоя: перед выкаткой каждой новой версии автоматически проверяются ключевые показатели, и если Performance упал ниже порога — деплой блокируется.
Для владельцев бизнеса — достаточно раз в месяц открыть PageSpeed Insights, вбить URL главной и двух-трёх ключевых страниц, и сверить показатели с предыдущим замером. Если что-то резко упало — это сигнал, что нужно разбираться: может быть, добавили тяжёлый виджет, загрузили неоптимизированные изображения или обновление CMS сломало что-то на фронтенде.
Lighthouse — ваш бесплатный консультант по качеству сайта. Он не идеален и не заменяет реальное тестирование на живых пользователях, но как инструмент систематической диагностики — незаменим.