Оцінка 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 з мети у інструмент спостереження за здоров’ям системи. Головне — не обрати правильний фреймворк, а визначити, де допустима складність.