Оцінка 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 із мети у показник, що слід спостерігати.

Ця зміна зосереджена не на виборі фреймворку, а на тому, де дозволити складність.