Пошук уроків, статей та іншого контенту
Оцінимо продуктивність і якість сторінки в Lighthouse та складемо план виправлення проблем CSS.
Lighthouse — це інструмент аудиту вебсторінки, вбудований у Chrome DevTools. Він перевіряє сторінку в контрольованих умовах і формує звіт за кількома категоріями:
Performance — швидкість завантаження та відображення сторінки.
Accessibility — доступність інтерфейсу.
Best Practices — типові практики безпеки й якості.
SEO — базова готовність сторінки до пошукової індексації.
Окремої категорії «якість CSS» у Lighthouse немає. Інструмент оцінює не красу CSS-коду, а наслідки його використання:
чи блокує CSS перше відображення;
чи завантажується великий обсяг невикористаних стилів;
чи спричиняють стилі зміщення макета;
чи збільшується час обчислення стилів і відображення;
чи впливає CSS на ключові метрики продуктивності.
Тому Lighthouse — це не заміна code review або stylelint. Це спосіб визначити, які проблеми CSS реально впливають на користувача.
Перед запуском аудиту потрібно створити умови, максимально наближені до реального використання.
Запустіть сторінку у production-режимі.
Переконайтеся, що використовуються стиснені CSS і JavaScript.
Відкрийте сторінку в режимі інкогніто.
Вимкніть розширення браузера, які можуть змінювати сторінку.
Оберіть правильний тип пристрою:
Mobile — для повільнішої мережі та слабшого CPU;
Desktop — для перевірки широкого екрана.
Запустіть аудит кілька разів і порівнюйте результати в однакових умовах.
Lighthouse використовує емуляцію мережі та процесора. Тому його результати можуть відрізнятися від реального досвіду користувачів.
Відкрийте сторінку.
Відкрийте DevTools.
Перейдіть на вкладку Lighthouse.
Виберіть:
режим Navigation;
потрібний пристрій;
категорію Performance та, за потреби, інші категорії.
Натисніть Analyze page load.
Після завершення звіту потрібно переглянути не лише оцінку, а й окремі метрики, проблеми та рекомендації.
FCP показує, коли браузер уперше відобразив будь-який контент.
CSS впливає на FCP, якщо:
таблиця стилів велика;
CSS завантажується з повільного сервера;
кілька таблиць стилів блокують відображення;
браузер має завантажити багато залежностей перед побудовою першого екрана.
LCP показує, коли відобразився найбільший видимий елемент початкового екрана.
Цим елементом часто є:
заголовок;
блок із фоновим зображенням;
зображення героя;
великий текстовий або картковий блок.
CSS може погіршити LCP, якщо:
стилі для головного екрана завантажуються пізно;
головний елемент прихований до завершення завантаження стилів;
великі фонові зображення задаються через CSS;
складні ефекти збільшують час відтворення.
CLS вимірює несподівані зміщення елементів під час завантаження.
Типові CSS-причини високого CLS:
відсутній зарезервований розмір для зображення;
змінюється висота шрифту після його завантаження;
елемент спочатку має одну висоту, а потім отримує іншу;
панель або банер вставляється над уже відображеним контентом;
контент з’являється через зміну класу або стилю.
Для зображень потрібно задавати width і height або використовувати aspect-ratio.
TBT вимірює час, протягом якого головний потік заблокований довгими завданнями. Основний внесок часто робить JavaScript, але CSS також може впливати через:
складне обчислення стилів;
великі DOM-дерева;
надмірну кількість елементів;
дорогі ефекти під час прокручування або анімації.
Саме по собі велике CSS-правило не завжди створює високий TBT. Важливо оцінювати його разом із кількістю елементів і частотою перерахунку стилів.
Speed Index оцінює, наскільки швидко заповнюється видима частина сторінки.
CSS впливає на нього, якщо:
початковий екран довго залишається порожнім;
критичні стилі завантажуються після основного контенту;
надто багато стилів потрібно обчислити перед першим відображенням.
Таблиці стилів, підключені в <head> без спеціальних умов, зазвичай є ресурсами, що блокують перше відображення.
<link rel="stylesheet" href="/css/styles.css">Це не означає, що всі стилі потрібно прибрати з <head>. Браузер має отримати стилі, необхідні для коректного відображення першого екрана.
Під час аналізу потрібно розділити CSS на:
критичний CSS — правила для початкового екрана;
некритичний CSS — правила для нижньої частини сторінки, модальних вікон, рідкісних компонентів або окремих станів.
Поширена помилка — асинхронно завантажувати всю таблицю стилів і показувати неоформлену сторінку. Це може прискорити одну метрику, але створити мерехтіння та погіршити візуальне сприйняття.
Цей аудит вказує, що браузер завантажує правила, які не використовуються під час конкретного завантаження сторінки.
Причини:
одна глобальна таблиця стилів для всього сайту;
CSS усіх компонентів завантажується на кожній сторінці;
старі стилі залишилися після видалення компонентів;
стилі для прихованих або рідкісних станів включені до основного бандла;
невикористані бібліотеки чи шаблони потрапили в production-збірку.
Важливо: Lighthouse перевіряє конкретний сценарій і конкретний стан сторінки. Правило може бути невикористаним під час завантаження, але потрібним після відкриття меню або модального вікна.
Тому не можна автоматично видаляти всі правила, які Lighthouse позначив як unused.
Для додаткової перевірки використовуйте вкладку Coverage у DevTools:
Відкрийте командне меню DevTools.
Знайдіть команду Show Coverage.
Перезавантажте сторінку.
Перегляньте частку використаного CSS.
Взаємодійте зі сторінкою: відкрийте меню, вкладки, модальні вікна.
Перевірте Coverage повторно.
Це допомагає відрізнити:
справді мертвий CSS;
CSS для взаємодії, який просто не використовувався під час першого завантаження;
CSS для іншого маршруту або компонента.
Розглянемо сторінку, яка резервує місце для зображення і не змінює структуру після завантаження.
index.html<!doctype html>
<html lang="uk">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Профіль команди</title>
<link rel="stylesheet" href="styles.css">
</head>
<body>
<header class="site-header">
<a class="logo" href="/">Команда</a>
<nav class="navigation" aria-label="Основна навігація">
<a href="#about">Про нас</a>
<a href="#projects">Проєкти</a>
<a href="#contacts">Контакти</a>
</nav>
</header>
<main>
<section class="hero" id="about">
<div class="hero__content">
<p class="eyebrow">Веброзробка</p>
<h1>Створюємо швидкі цифрові продукти</h1>
<p class="hero__description">
Проєктуємо доступні інтерфейси та підтримувані CSS-системи.
</p>
<a class="button" href="#projects">Переглянути проєкти</a>
</div>
<div class="hero__media">
<img
src="team.webp"
width="640"
height="480"
alt="Команда розробників за роботою"
>
</div>
</section>
<section class="projects" id="projects">
<h2>Наші проєкти</h2>
<div class="project-grid">
<article class="card">
<h3>Портал клієнта</h3>
<p>Адаптивний інтерфейс для роботи з документами.</p>
</article>
<article class="card">
<h3>Система аналітики</h3>
<p>Дашборд із чіткою ієрархією даних і швидким рендерингом.</p>
</article>
</div>
</section>
</main>
</body>
</html>styles.css:root {
color-scheme: light;
font-family: system-ui, sans-serif;
color: #172033;
background: #ffffff;
}
*,
*::before,
*::after {
box-sizing: border-box;
}
body {
margin: 0;
line-height: 1.5;
}
.site-header {
display: flex;
align-items: center;
justify-content: space-between;
gap: 1rem;
min-height: 4rem;
padding: 0 5vw;
border-bottom: 1px solid #e5e7eb;
}
.logo {
color: inherit;
font-weight: 700;
text-decoration: none;
}
.navigation {
display: flex;
flex-wrap: wrap;
gap: 1rem;
}
.navigation a {
color: inherit;
text-decoration: none;
}
.hero {
display: grid;
grid-template-columns: minmax(0, 1fr) minmax(280px, 640px);
gap: clamp(2rem, 5vw, 5rem);
align-items: center;
max-width: 1280px;
margin: 0 auto;
padding: clamp(3rem, 8vw, 8rem) 5vw;
}
.hero__content {
max-width: 36rem;
}
.eyebrow {
margin: 0 0 0.75rem;
color: #5267c8;
font-weight: 700;
}
h1,
h2,
h3,
p {
margin-top: 0;
}
h1 {
margin-bottom: 1.25rem;
font-size: clamp(2.25rem, 5vw, 4.5rem);
line-height: 1.05;
}
.hero__description {
margin-bottom: 2rem;
font-size: 1.125rem;
}
.hero__media {
overflow: hidden;
aspect-ratio: 4 / 3;
border-radius: 1rem;
background: #eef1ff;
}
.hero__media img {
display: block;
width: 100%;
height: 100%;
object-fit: cover;
}
.button {
display: inline-block;
padding: 0.75rem 1rem;
border-radius: 0.5rem;
color: #ffffff;
background: #5267c8;
text-decoration: none;
}
.projects {
max-width: 1280px;
margin: 0 auto;
padding: 4rem 5vw;
}
.project-grid {
display: grid;
grid-template-columns: repeat(2, minmax(0, 1fr));
gap: 1rem;
}
.card {
padding: 1.5rem;
border: 1px solid #e5e7eb;
border-radius: 0.75rem;
}
@media (max-width: 760px) {
.site-header {
align-items: flex-start;
flex-direction: column;
padding-top: 1rem;
padding-bottom: 1rem;
}
.hero {
grid-template-columns: 1fr;
}
.project-grid {
grid-template-columns: 1fr;
}
}У цьому прикладі:
зображення має задані width і height;
контейнер зображення має aspect-ratio;
зображення не змінює висоту після завантаження;
головний контент не приховується до завершення завантаження CSS;
сітка має передбачувану структуру на вузькому екрані;
правила для мобільної версії обмежені @media-блоком.
Файл team.webp має існувати поруч із HTML-файлом. Для повного тесту сторінку краще відкривати через локальний HTTP-сервер, а не через file://.
Після завершення аудиту звіт потрібно читати в такому порядку.
Зверніть увагу на:
FCP;
LCP;
TBT;
CLS;
Speed Index.
Спочатку визначте, яка метрика має найбільшу проблему. Не варто одночасно переписувати весь CSS, якщо основна причина низької оцінки — одне велике зображення або JavaScript.
Розділ Opportunities містить потенційні способи скоротити час завантаження.
Для CSS найчастіше важливі:
ресурси, що блокують відображення;
невикористаний CSS;
надмірний обсяг переданих ресурсів;
проблеми з завантаженням шрифтів або інших ресурсів, які впливають на відображення.
Lighthouse часто показує приблизну економію часу. Це оцінка в умовах конкретного запуску, а не гарантований результат після виправлення.
Diagnostics дає технічні деталі:
які ресурси завантажувалися;
що довго блокувало відображення;
які елементи були найбільшими;
де виникали зміщення макета;
які елементи потребували значного часу на відображення.
У цьому розділі важливо співвіднести рекомендацію з конкретним CSS-файлом або компонентом, а не виправляти проблему абстрактно.
Виконані перевірки корисні як базова контрольна точка. Після змін потрібно переконатися, що нові оптимізації не зламали вже виконані умови.
Погано:
<img src="team.webp" alt="Команда">Браузер не знає, скільки місця потрібно зарезервувати до завантаження зображення.
Краще:
<img
src="team.webp"
width="640"
height="480"
alt="Команда"
>Або можна зафіксувати співвідношення сторін контейнера:
.media {
aspect-ratio: 4 / 3;
overflow: hidden;
}
.media img {
display: block;
width: 100%;
height: 100%;
object-fit: cover;
}Якщо банер, повідомлення або панель додається над основним контентом після завантаження, сторінка може отримати CLS.
Краще:
зарезервувати для нього місце;
показувати його до основного контенту;
не вставляти новий блок над уже видимим вмістом;
змінювати внутрішній стан блока, а не його позицію в документі.
Анімація width, height, top, left, margin або padding може спричиняти повторні обчислення макета.
Для простих анімацій зазвичай краще використовувати transform і opacity:
.menu {
transform: translateX(-100%);
opacity: 0;
transition:
transform 200ms ease,
opacity 200ms ease;
}
.menu.is-open {
transform: translateX(0);
opacity: 1;
}Цей приклад не вирішує всі проблеми продуктивності анімацій, але не змушує браузер постійно змінювати геометрію сусідніх елементів.
Результат аудиту потрібно перетворити на список конкретних дій.
Запишіть:
URL;
дату аудиту;
тип пристрою;
налаштування мережі;
значення FCP, LCP, TBT, CLS;
головні рекомендації Lighthouse;
розмір CSS-файлів.
Без базового стану неможливо об’єктивно оцінити ефект змін.
Пріоритет зазвичай мають проблеми, які:
впливають на LCP або FCP;
спричиняють CLS;
блокують відображення великого обсягу контенту;
повторюються на всіх сторінках;
легко перевіряються після виправлення.
Наприклад, відсутність розмірів у головного зображення часто важливіша за видалення кількох кілобайт невикористаного CSS.
Для кожної проблеми вкажіть:
файл;
компонент;
селектор або ресурс;
метрику, на яку він впливає;
очікуваний результат;
спосіб перевірки.
Приклад плану:
Додати розміри головному зображенню — перевірити CLS.
Винести стилі початкового екрана в критичний набір — перевірити FCP і LCP.
Видалити правила старих компонентів — перевірити розмір CSS і Coverage.
Розділити стилі рідкісних компонентів — перевірити повторний аудит після відкриття цих компонентів.
Повторити аудит на Mobile і Desktop.
Не варто одночасно:
змінювати структуру DOM;
міняти систему збірки;
переписувати всі селектори;
замінювати зображення;
змінювати завантаження шрифтів.
Якщо після цього показники покращаться або погіршаться, буде складно визначити причину.
Lighthouse перевіряє сторінку в певному сценарії. Після видалення CSS потрібно протестувати:
початковий стан;
відкриту навігацію;
відкриті модальні вікна;
стани помилок;
адаптивні брейкпоїнти;
фокус клавіатури;
hover- і focus-стани.
Оптимізація, яка ламає один із цих станів, не є успішною.
Lighthouse не відповідає на всі питання про підтримуваність CSS. Навіть сторінка з високою оцінкою може мати:
дубльовані правила;
надмірну специфічність;
неочевидні залежності між компонентами;
глобальні селектори, що випадково змінюють чужі елементи;
старі класи;
неоднорідні брейкпоїнти.
Тому після Lighthouse потрібно перевірити, чи виправлення не погіршило структуру стилів:
чи зрозуміло, кому належить кожне правило;
чи не з’явилися зайві !important;
чи не дублюються однакові значення;
чи не залежить компонент від випадкового порядку підключення CSS;
чи відповідає назва класу його ролі.
Це вже перевіряється code review, тестами інтерфейсу та статичним аналізом, а не лише Lighthouse.
Загальний бал — це агрегована оцінка, а не діагноз. Дві сторінки можуть мати однаковий бал, але зовсім різні проблеми.
Потрібно аналізувати конкретні метрики та аудити.
Lighthouse перевіряє лише поточний сценарій. Стиль може бути потрібний для:
відкритого меню;
модального вікна;
іншої вкладки;
стану помилки;
іншого маршруту.
Спочатку перевірте сторінку через Coverage та протестуйте інтерактивні стани.
Без критичних стилів користувач може побачити неоформлений HTML або мерехтіння сторінки. Оптимізувати потрібно не факт наявності CSS у <head>, а обсяг стилів, необхідних для першого екрана.
Результати залежать від навантаження системи, мережі та процесора. Виконуйте кілька запусків і порівнюйте середню тенденцію, а не одне число.
Видалення стилів або зміна початкових розмірів компонентів може створити зміщення макета. Після кожної зміни, що впливає на розміри або видимість, перевіряйте CLS.
Якщо Lighthouse показує високий TBT, причина може бути в довгих JavaScript-завданнях, а не в таблиці стилів. CSS слід оптимізувати лише тоді, коли профілювання та діагностика вказують на його внесок.
Запустіть Lighthouse у production-режимі.
Збережіть значення FCP, LCP, TBT, CLS і Speed Index.
Знайдіть ресурси, що блокують відображення.
Перевірте розмір і склад CSS-файлів.
Запустіть Coverage та взаємодійте зі сторінкою.
Перевірте розміри зображень і динамічних блоків.
Визначте одну-дві проблеми з найбільшим впливом.
Внесіть невеликі зміни.
Повторіть аудит в однакових умовах.
Перевірте мобільну, десктопну та інтерактивну версії сторінки.
Переконайтеся, що CSS залишився підтримуваним.
Lighthouse оцінює вплив CSS на продуктивність, але не замінює перевірку якості коду.
Найважливіші для CSS метрики — FCP, LCP, CLS, TBT і Speed Index.
Основні CSS-проблеми в Lighthouse — блокування відображення, невикористані стилі та нестабільна геометрія сторінки.
Для зменшення CLS потрібно резервувати місце для зображень і динамічних блоків.
Невикористаний CSS потрібно перевіряти через Coverage у різних станах сторінки.
Виправлення слід пріоритезувати за впливом на користувача, а не за кількістю попереджень.
Після кожної оптимізації потрібно повторювати аудит і перевіряти, що інтерактивні та адаптивні стани не зламані.