Оценка Lighthouse — это не инструмент настройки, а зеркало, отражающее здоровье архитектуры

Почему разница возникает на одном и том же сайте

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

Что действительно проверяет Lighthouse

Lighthouse — это не инструмент оценки качества фреймворков, а средство количественной оценки пользовательского опыта.

• Скорость отображения контента на экране
• Степень блокировки основного потока JavaScript
• Стабильность макета во время загрузки страницы
• Доступность и индексируемость структуры документа

Эти показатели показывают, как влияет начальный этап разработки. Страницы, сильно зависящие от крупного клиентского бандла, автоматически получают низкие оценки. В то время как страницы на статическом HTML становятся более предсказуемыми по производительности.

JavaScript и гидрация: главные виновники снижения производительности

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

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

Архитектура, предполагающая обязательное использование JavaScript по умолчанию, требует постоянной оптимизации для поддержания производительности. В то время как архитектура с явным опциональным использованием JavaScript дает более стабильные результаты.

Статическая генерация — гарантия стабильности

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

• Отсутствие задержек серверной рендеринга
• Не требуется запускать клиентский бандл для инициализации
• Браузер получает полностью предсказуемый HTML

В результате автоматически улучшаются такие метрики, как TTFB, LCP, CLS. Статическая генерация не гарантирует идеальные оценки, но значительно сокращает вероятность их провала.

Пример: что я узнал при реконструкции личного блога

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

Я решил попробовать другой подход: сделать HTML статическим по умолчанию, а JavaScript — исключением. Выбор Astro обусловлен тем, что его базовые ограничения совпадали с гипотезой, которую я хотел проверить.

Меня поразило, что важнее не начальный высокий балл, а минимальные усилия для его поддержания со временем. Публикация нового контента не приводила к падениям, небольшие интерактивные элементы не вызывали лишних предупреждений. Базовая структура оставалась практически неповрежденной.

Нет универсального решения

Этот подход не всегда оптимален. В приложениях с аутентификацией, реальным временем обновлений или сложным управлением состоянием клиента статическая архитектура может оказаться недостаточной.

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

Что влияет на стабильность оценки Lighthouse

Lighthouse показывает не усилия, а энтропию.

Системы, зависящие от выполнения в рантайме, со временем накапливают сложность при добавлении новых функций. В то время как системы, переносящие обработку на этапе сборки, по умолчанию снижают эту сложность.

Это объясняет, почему одни сайты требуют постоянных усилий по оптимизации, а другие остаются стабильными при минимальных вмешательствах.

Вывод: оценка — это не цель, а наблюдение

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

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