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

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

Что показывают метрики производительности

Lighthouse измеряет не рейтинг инструментов или фреймворков. Он оценивает реальные показатели:

• Скорость, с которой пользователь видит значимый контент
• Время, в течение которого JavaScript занимает основной поток
• Насколько стабильно при загрузке сохраняется макет
• Доступность и индексируемость структуры документа

Эти метрики (TTFB, LCP, CLS) — цепная реакция принятых решений на этапе реализации. Особенно это напрямую влияет на вычислительную нагрузку, которую браузер обрабатывает во время выполнения.

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

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

Во многих проектах-аудитах встречается одна и та же проблема — выполнение JavaScript.

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

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

В противоположность этому, архитектура, явно делая JavaScript опциональным, как правило, дает более стабильные результаты. Именно эта философия ярко отражается на баллах Lighthouse.

Предварительная обработка исключает неопределенность

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

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

В результате показатели TTFB, LCP, CLS улучшаются сами собой. Это не гарантирует идеальный балл, но значительно снижает риск ошибок.

Изучая на практике

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

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

Самое удивительное — не начальный балл, а стабильность производительности со временем:

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

В этой архитектуре баллы Lighthouse перестают быть целью — они становятся естественным следствием.

Реальность компромиссов

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

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

Главное — не то, какой подход лучше, а то, что выбор архитектуры напрямую влияет на метрики Lighthouse.

Почему баллы стабилизируются, а иногда падают

Lighthouse показывает не результат оптимизации, а сложность системы.

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

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

Суть выбора

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

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

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