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

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

Со временем это предположение перестало соответствовать тому, что я видел на практике.

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

В этот момент Lighthouse перестал восприниматься как инструмент оптимизации и начал восприниматься как диагностический сигнал для архитектурных решений.

Что на самом деле измеряет Lighthouse

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

Как быстро появляется значимый контент.

Сколько JavaScript блокирует основной поток.

Насколько стабильным остается макет во время загрузки.

Насколько доступной и сканируемой является структура документа.

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

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

JavaScript как основной источник отклонений

Во всех аудитах, которые я проводил, и проектах, над которыми я работал, выполнение JavaScript является наиболее распространенным источником ухудшения показателей Lighthouse.

Это не потому, что код низкого качества. Это потому, что JavaScript конкурирует за однопоточную среду выполнения во время загрузки страницы.

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

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

Статический вывод снижает неопределенность

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

Нет затрат на рендеринг на стороне сервера во время запроса.

Нет необходимости в клиентской начальной загрузке для появления контента.

Браузер получает предсказуемый, полный HTML.

С точки зрения Lighthouse, это улучшает такие метрики, как TTFB, LCP и CLS, без необходимости целенаправленной работы по оптимизации. Статическая генерация не гарантирует идеальных оценок, но значительно сужает диапазон режимов отказа.

Практический пример

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

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

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

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

Компромиссы имеют значение

Этот подход не является универсально лучшим.

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

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

Почему показатели Lighthouse, как правило, стабильны или хрупки

То, что выявляет Lighthouse, — это не усилия, а энтропия.

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

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

Заключительные мысли

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

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

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