Що насправді означає рейтинг Lighthouse: вибір архітектури визначає стабільність

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

Обсяг роботи браузера визначає продуктивність

Lighthouse вимірює не переваги фреймворків, а реальні результати.

• Швидкість відображення контенту (TTFB, LCP)
• Час зайнятий JavaScript на головному потоці
• Стабільність макету під час завантаження (CLS)
• Доступність структури та можливість сканування

Ці метрики визначаються рішеннями, прийнятими на рівні оптимізаційного шару. Особливо — безпосередньо залежать від обчислювального навантаження, яке виконується у браузері під час роботи.

Якщо сайт залежить від великих клієнтських бандлів для функціональності, низький бал неминучий. Навпаки, якщо базується на статичному HTML і мінімальній обробці на клієнті, продуктивність стає більш передбачуваною та стабільною.

Виконання JavaScript — головний чинник обмеження

Багато аудитів і проектів показують, що виконання JavaScript — найпоширеніша причина зниження балу Lighthouse. Це не проблема якості коду, а архітектурний вибір.

JavaScript виконується у однопоточному середовищі. Обробка фреймворків, гідрація, аналіз залежностей, ініціалізація стану — все це займає час, поки сторінка не стане інтерактивною. Навіть для невеликих функцій часто потрібен надмірно великий бандл.

Архітектура, орієнтована на JavaScript за замовчуванням, вимагає постійних зусиль для підтримки стабільної продуктивності. В той час як архітектура з явним опціоном на JavaScript зазвичай дає більш стабільні результати.

Зменшення невизначеності за рахунок статичного виводу

Згенерований заздалегідь HTML усуває кілька змінних у формулі продуктивності:

• Відсутність витрат на серверний рендеринг під час запиту
• Не потрібен клієнтський стартовий скрипт
• Браузер отримує цілісний і передбачуваний HTML

З точки зору Lighthouse, це покращує показники TTFB, LCP, CLS без додаткового налаштування. Статична генерація не гарантує ідеальний бал, але значно зменшує ризики провалів.

Приклад реалізації: міграція з React

При реконструкції особистого блогу я розглядав кілька підходів, включно з гідрацією на базі React. Вони були гнучкими і функціональними, але вимагали постійного моніторингу для збереження продуктивності. З кожним новим функціоналом доводилося переосмислювати стратегію рендерингу, отримання даних і розмір бандлів.

Інший підхід — базування на статичному HTML і використання JavaScript як виняткової опції. Вибір зупинився на Astro, оскільки його обмеження відповідали гіпотезі, яку я хотів перевірити.

Значущим було не початкове підвищення балу, а те, наскільки менше він знижується з часом. Новий контент не спричиняє падінь, додавання невеликих інтерактивних елементів не викликає ланцюгових попереджень. Це архітектурна стабільність, коли базовий рівень залишається цілісним.

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

Цей підхід не універсальний. Статичний перший архітектурний підхід не підходить для високодинамічних, складних систем з управління станом. Аутентифікація, реальні оновлення у реальному часі, складне управління станом — це сценарії, де цей підхід буде обмеженням.

Фреймворки, орієнтовані на клієнтський рендеринг, більш гнучкі у таких випадках, але вимагають більшої складності під час виконання. Важливо розуміти, що жоден підхід не є універсальним, і його вибір безпосередньо відображається у показниках Lighthouse.

Причини стабільності та вразливості балу

Lighthouse відкриває не результат зусиль, а накопичену складність.

Системи, що залежать від часу виконання, зростають у складності з додаванням функцій. Системи, що концентрують обробку на етапі збірки, за замовчуванням контролюють цю складність. Це пояснює, чому деякі сайти вимагають постійних робіт з оптимізації, тоді як інші залишаються стабільними з мінімальним втручанням.

Висновок: стабільність — архітектурна характеристика

Високий бал Lighthouse зазвичай не є результатом активної настройки, а природним наслідком архітектури, що мінімізує роботу браузера під час початкового завантаження.

Інструменти змінюються з часом, але принципи залишаються незмінними. Якщо продуктивність — не ціль, а обмеження при проектуванні, Lighthouse стає індикатором, а не метою. Це вимагає свідомого вибору місць для прийняття складності, а не просто вибору правильного фреймворка.