Lighthouse 100%: что реально влияет на оценку и какие инструменты помогут

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

Разберёмся, что именно считает Lighthouse, какие метрики весят больше всего и с чего начинать, чтобы усилия не уходили впустую.

Из чего складывается оценка

Lighthouse считает четыре независимые категории: Performance, Accessibility, Best Practices и SEO. Сотня в одной ничего не говорит о трёх остальных, чинят их по-разному.

Хороший пример: производительность вылизана до сотни, а Best Practices на семидесяти трёх. Категории независимы, и оптимизация скриптов не починит недостающий фавикон или ошибку в консоли.

Обратите внимание на предупреждение под кругами. Lighthouse честно сообщает, что данные в IndexedDB могли повлиять на замер, и советует прогонять аудит в режиме инкогнито. Это не мелочь. Кэш, расширения и уже сохранённые данные легко дают разброс в десяток баллов между прогонами.

Сложнее всего даётся Performance, потому что это не одна цифра, а взвешенная сумма пяти метрик:

Отсюда главный вывод, который экономит дни работы. TBT весит 30%, больше любой другой метрики. Улучшение TBT влияет на итоговый балл втрое сильнее, чем такое же улучшение FCP.

А TBT — это про JavaScript. Не про картинки, не про шрифты, не про CSS. Если у вас проседает Performance, первым делом смотрите на скрипты, а не на ассеты.

Performance: с чего начинать

1. Сначала JavaScript, потом всё остальное

TBT растёт, когда главный поток занят долгими задачами и не может ответить на действие пользователя. Виноваты обычно три вещи:

• сторонние скрипты: аналитика, чаты, пиксели рекламы. Часто это половина всего JS на странице;
• гидратация тяжёлых компонентов;
• работа в момент загрузки: парсинг больших JSON, инициализация библиотек.

Что делать по порядку:

<!-- Аналитика не нужна для первой отрисовки — выполнится после парсинга -->
<script src="/analytics.js" defer></script>

Важно не перепутать defer и async. Загрузкой парсинг не блокирует ни тот ни другой, но async выполняет скрипт сразу, как только тот скачался, прямо посреди разбора страницы. Для TBT это худший вариант, главный поток встаёт в непредсказуемый момент. defer откладывает выполнение до конца парсинга, и скрипты идут по порядку. Для стороннего кода почти всегда нужен defer.

Ещё эффективнее вообще не грузить сторонние скрипты до первого действия пользователя. Чат, который подключается по клику на иконку, а не при загрузке страницы, стоит ноль миллисекунд TBT.

2. Минифицируйте CSS и JavaScript

Lighthouse прямо ругается аудитами Minify CSS и Minify JavaScript. Обычно это делает сборщик, но если стили подключаются отдельным файлом или вы правите что-то руками, сжать код стоит.

Минификация убирает комментарии, переносы и пробелы, сокращает #ffffff до #fff, а 0px до 0. Файл худеет на 20–40%, и поверх этого лучше сжимается gzip: в минифицированном коде меньше повторяющегося «воздуха».

3. Картинки: вес и размеры

Картинки редко влияют на TBT, зато напрямую бьют по LCP, а это ещё 25%. Крупное изображение в первом экране почти всегда и есть тот самый Largest Contentful Paint.

Что с ними делать:

• Не грузите больше, чем нужно. Если картинка отображается 400px шириной, а весит 2400px, вы платите за пиксели, которых никто не увидит.
• Отдавайте современные форматы. WebP или AVIF вместо JPEG экономят 25–50% веса.
• Не откладывайте LCP-картинку. loading="lazy" на главном изображении первого экрана — классическая ошибка, вы своими руками замедляете метрику, которую пытаетесь ускорить. Lazy-загрузка нужна тому, что ниже сгиба.

Самый действенный однострочник здесь — fetchpriority="high". Браузер по умолчанию не знает, какая из картинок главная, и обнаруживает LCP-изображение поздно. Атрибут говорит ему: эту грузи первой.

<img
	src="hero.avif"
	width="1200"
	height="630"
	fetchpriority="high"
	alt="Заголовок статьи"
/>

Часто это даёт больше, чем пересжатие картинки: вы не уменьшаете вес, а просто перестаёте заставлять браузер угадывать.

Проверить реальные размеры и вес изображения, прежде чем класть его в проект:

Мелкие иконки и декоративные SVG выгоднее встроить прямо в CSS, это минус один сетевой запрос на каждую. Кодировать SVG в Base64 при этом не нужно: достаточно экранировать разметку, и строка выйдет короче, а правило останется читаемым.

4. CLS: зарезервируйте место заранее

CLS весит те же 25%, что и LCP, чинится куда проще, а игнорируют его почти всегда.

Вёрстка прыгает, когда браузер узнаёт размеры элемента уже после того, как нарисовал страницу. Лечится это одним принципом. Место под элемент должно быть известно заранее.

Главный фикс самый скучный. Проставьте картинке атрибуты width и height, именно этого требует аудит unsized-images. Браузер сам выведет из них пропорцию и зарезервирует место, при этом картинка останется резиновой.

<!-- Браузер знает пропорцию до загрузки и не сдвинет вёрстку -->
<img src="hero.avif" width="1200" height="630" alt="" />

img {
	width: 100%;
	height: auto; /* сохраняет пропорцию из атрибутов */
}

aspect-ratio в CSS нужен там, где реальных размеров нет заранее, скажем у контейнера под эмбед. Но не вешайте фиксированное соотношение на все картинки подряд: aspect-ratio: 16 / 9 раздавит любую, у которой пропорция другая. Если всё же ставите, добавляйте object-fit: cover.

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

Отдельная причина CLS — шрифты. Когда системный шрифт сменяется на фирменный, текст меняет метрики и строки перескакивают.

И здесь широко распространён вредный совет: «поставьте font-display: swap». На деле swap и есть причина сдвига. Он гарантирует, что подмена произойдёт, а значит произойдёт и скачок вёрстки.

Лечится это тем, что запасной шрифт подгоняют по метрикам под фирменный, и тогда подмена происходит без сдвига:

@font-face {
	font-family: 'Inter Fallback';
	src: local('Arial');
	size-adjust: 107%;
	ascent-override: 90%;
	descent-override: 22%;
}

body {
	font-family: 'Inter', 'Inter Fallback', sans-serif;
}

Есть и радикальный вариант, font-display: optional. Браузер подменит шрифт, только если тот успел загрузиться за ~100 мс, иначе просто останется на системном, и сдвига не будет вовсе.

Предзагрузка шрифта тоже полезна, но она лечит не CLS, а задержку отрисовки текста:

<link
	rel="preload"
	href="/fonts/inter.woff2"
	as="font"
	type="font/woff2"
	crossorigin
/>

Accessibility: контраст валит чаще всего

В категории доступности сотня достижима почти всегда, там нет метрик, есть конкретные проверки. И чаще всего проваливается проверка контраста текста и фона.

Порог по WCAG — 4.5:1 для обычного текста и 3:1 для крупного (от 24px или от 18.66px жирного). Ловушка в том, что контраст считается по яркости, а не по «разнице цветов на глаз». Жёлтый кажется ярким и заметным, но белый текст на жёлтом фоне почти нечитаем, потому что яркости слишком близки.

Чаще всего проваливают:

• плейсхолдеры в полях ввода, светло-серый на белом даёт классические 2.5:1;
• неактивные элементы, задизейбленную кнопку делают почти невидимой;
• текст поверх фотографий, где фон меняется от пикселя к пикселю;
• индикатор фокуса, которому нужны те же 3:1, иначе навигация с клавиатуры превращается в угадайку. Рисуется он псевдоклассом :focus-visible, разбор есть в статье про псевдоклассы и псевдоэлементы.

Проверить пару цветов и сразу увидеть вердикт по AA и AAA:

Остальное в этой категории — механика, которую стоит просто пройти по списку: alt у картинок, lang у <html>, подписи (label) у полей форм, осмысленный порядок заголовков без прыжков с h1 на h4.

Best Practices и SEO: быстрые сто процентов

Эти две категории самые дешёвые. Обычно до сотни не хватает мелочей.

Best Practices проверяет отсутствие ошибок в консоли, HTTPS, корректные размеры изображений и то, что вы не используете устаревшие API. Чаще всего балл роняет именно консоль, одна ошибка от стороннего скрипта, и категория уже не сотня.

Отдельно стоит сказать, чего Lighthouse больше не проверяет. Аудиты фавиконок и манифеста жили в категории PWA, а её удалили в Lighthouse 12, так что на оценку они не влияют вовсе. Иконки по-прежнему нужны браузеру, вкладке и экрану «Домой» на телефоне, но ради балла их делать бессмысленно:

SEO проверяет базу: <title>, <meta name="description">, доступность для индексации, осмысленные тексты ссылок. Длину заголовка и описания удобно проверить счётчиком символов. Google обрезает title примерно после 60 символов, а description после 160. Аудит читаемого размера шрифта, к слову, тоже удалён в Lighthouse 12. Open Graph Lighthouse не проверяет, зато его проверяют соцсети, и ломается там чаще всего именно превью ссылки:

100% в Lighthouse — не то же самое, что быстрый сайт

И это главное, что стоит понимать, прежде чем гнаться за цифрой.

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

Поэтому:

• TBT и INP — разные вещи. Lighthouse меряет TBT в лаборатории, а Google в поиске учитывает INP, отзывчивость на реальные действия реальных людей. Можно иметь 100% и медленный отклик на клик.
• Балл скачет. Один и тот же сайт даёт 92% и 100% в двух прогонах подряд, это нормально, метрики шумят.
• Поле важнее лаборатории. На ранжирование влияют данные CrUX (Core Web Vitals из Chrome), а не число в отчёте.

Сотня — хороший ориентир и отличный способ найти конкретные проблемы. Lighthouse честно показывает, какой скрипт блокирует поток и какой текст не читается. Но целью остаётся сайт, который быстро отвечает живому человеку с телефоном в метро, а не сама цифра.

Порядок действий, если коротко

1. Откройте вкладку Performance и посмотрите, что даёт TBT. Скорее всего, сторонние скрипты. Выносите их на defer, а не на async, или на первое действие пользователя.
2. Найдите LCP-элемент, Lighthouse его подсвечивает. Уберите с него lazy, отдайте в современном формате, не грузите лишние пиксели.
3. Зарезервируйте место под всё, что подгружается: width и height на картинки, min-height на эмбеды, метрики запасного шрифта вместо font-display: swap.
4. Прогоните контраст по всем текстовым парам, это самая частая ошибка доступности.
5. Закройте мелочи в Best Practices и SEO: иконки, мета-теги, консоль.

И только потом сжимайте CSS. Не наоборот.