Аудит у Lighthouse

Запустіть застосунок у режимі розробки:

Після цього відкрийте сторінку за адресою:

Однак для реального аудиту краще використовувати production-збірку:

Чому важливий production-режим

Режим розробки Next.js має додаткові перевірки та службовий код. Через це результати Lighthouse можуть бути гіршими або не відповідати поведінці опублікованого застосунку.

Для більш реалістичного аудиту:

1. виконайте npm run build;

2. запустіть npm run start;

3. відкрийте сторінку на локальному сервері;

4. запустіть Lighthouse.

Запуск Lighthouse

1. Відкрийте потрібну сторінку в Google Chrome.

2. Відкрийте DevTools:

   • клавішею F12;

   • або через меню браузера.

3. Перейдіть на вкладку Lighthouse.

4. Виберіть категорію Performance.

5. Виберіть тип пристрою:

   • Mobile — перевірка для мобільного пристрою;

   • Desktop — перевірка для настільного комп’ютера.

6. Натисніть Analyze page load або кнопку запуску аудиту.

Під час перевірки Lighthouse може застосувати штучне обмеження швидкості мережі та процесора. Тому результати не обов’язково будуть такими самими, як під час звичайного перегляду сторінки на вашому комп’ютері.

Як читати оцінку Performance

Після завершення перевірки Lighthouse показує оцінку від 0 до 100:

• 90–100 — добре;

• 50–89 — є що покращити;

• 0–49 — значні проблеми з продуктивністю.

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

Тому не варто виправляти проблему лише для збільшення числа. Потрібно зрозуміти, яка саме частина взаємодії зі сторінкою є повільною.

Основні метрики

First Contentful Paint

FCP, або First Contentful Paint, — час до появи першого видимого вмісту сторінки.

Наприклад, таким вмістом може бути:

• заголовок;

• текст;

• кнопка;

• зображення.

Якщо FCP великий, користувач довго бачить порожню сторінку.

Largest Contentful Paint

LCP, або Largest Contentful Paint, — час до відображення найбільшого видимого елемента в області перегляду.

Найбільшим елементом може бути:

• великий заголовок;

• основне зображення;

• блок із текстом;

• банер.

Орієнтовні межі LCP:

• до 2.5 секунди — добре;

• від 2.5 до 4 секунд — потрібно покращення;

• понад 4 секунди — поганий результат.

Total Blocking Time

TBT, або Total Blocking Time, — час, протягом якого JavaScript-браузер не може нормально обробляти дії користувача.

Довгі JavaScript-завдання можуть блокувати:

• натискання кнопок;

• прокручування;

• введення тексту;

• відкриття меню.

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

Cumulative Layout Shift

CLS, або Cumulative Layout Shift, — показник несподіваних зміщень елементів на сторінці.

Наприклад:

1. користувач збирається натиснути кнопку;

2. завантажується зображення без зарезервованого місця;

3. вміст зміщується;

4. користувач натискає вже не ту кнопку.

Орієнтовні межі CLS:

• до 0.1 — добре;

• від 0.1 до 0.25 — потрібно покращення;

• понад 0.25 — поганий результат.

Interaction to Next Paint

INP, або Interaction to Next Paint, — показник швидкості реакції сторінки на взаємодію користувача.

Враховуються, наприклад:

• натискання;

• введення тексту;

• вибір елемента;

• відкриття або закриття компонента.

Орієнтовні межі INP:

• до 200 мс — добре;

• від 200 до 500 мс — потрібно покращення;

• понад 500 мс — поганий результат.

На відміну від TBT, INP належить до показників, які можуть описувати реальний досвід користувачів.

Розділи звіту Lighthouse

Opportunities

У розділі Opportunities Lighthouse показує можливості для покращення.

Для кожної рекомендації зазвичай вказано:

• проблему;

• можливий виграш у часі;

• ресурси або елементи, яких це стосується.

Наприклад, звіт може повідомити, що потрібно:

• оптимізувати зображення;

• зменшити JavaScript;

• видалити невикористаний код;

• скоротити час відповіді сервера.

Оцінка часу є приблизною. Якщо рекомендація обіцяє економію в 500 мс, це не означає, що оцінка Performance гарантовано збільшиться на певне число балів.

Diagnostics

У розділі Diagnostics наведено додаткову інформацію про сторінку.

Тут можуть бути дані про:

• розмір DOM;

• довгі завдання JavaScript;

• великі ресурси;

• кешування;

• непотрібні запити.

Diagnostics не завжди означає пряму помилку. Це підказки для пошуку причин повільної роботи.

Passed audits

У розділі Passed audits відображаються перевірки, які сторінка пройшла успішно.

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

Практичний алгоритм аудиту

Виконуйте аудит у такій послідовності:

1. Запустіть застосунок у production-режимі.

2. Відкрийте сторінку в Chrome.

3. Запустіть Lighthouse для мобільного пристрою.

4. Запишіть початкові значення:

   • Performance;

   • FCP;

   • LCP;

   • TBT;

   • CLS;

   • INP, якщо він доступний у звіті.

5. Перегляньте перші рекомендації в Opportunities.

6. Відкрийте відповідні діагностичні дані.

7. Змініть одну або кілька пов’язаних проблем.

8. Зберіть production-збірку повторно.

9. Запустіть аудит ще раз.

10. Порівняйте не лише загальний бал, а й окремі метрики.

Не робіть висновків за одним запуском. Результат може змінюватися через:

• навантаження на комп’ютер;

• стан локального сервера;

• мережеві умови;

• кеш браузера;

• випадкові коливання часу виконання.

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

Особливості аудиту Next.js

Перевіряйте потрібний маршрут

У Next.js різні маршрути можуть мати різну продуктивність. Наприклад:

• головна сторінка може бути статичною;

• сторінка каталогу може завантажувати багато даних;

• сторінка профілю може містити більше клієнтського JavaScript.

Тому Lighthouse потрібно запускати для кожного важливого маршруту окремо.

Враховуйте клієнтський JavaScript

Компоненти з 'use client' можуть додавати JavaScript, який потрібно завантажити та виконати в браузері.

Якщо сторінка не потребує стану або обробників подій у браузері, її частину можна залишити серверним компонентом. Це допомагає не передавати зайвий код клієнту.

Не потрібно автоматично робити всі компоненти клієнтськими. Спочатку подивіться, чи справді це необхідно для роботи компонента.

Перевіряйте production-збірку

Аудит запущеної через npm run dev сторінки корисний для швидкої перевірки, але він не показує точну поведінку production-версії.

Основний результат аналізуйте після:

Не плутайте локальний і реальний результат

Під час локального аудиту сервер може відповідати швидше або повільніше, ніж сервер у production.

Локальна перевірка допомагає знайти очевидні проблеми, але остаточну оцінку потрібно підтверджувати в умовах, близьких до реальних.

Як інтерпретувати рекомендації

Розглянемо приклад міркування:

LCP становить 4.2 секунди, а Lighthouse вказує на велике головне зображення.

Правильний висновок:

1. найбільший видимий елемент з’являється пізно;

2. потрібно перевірити його розмір і формат;

3. потрібно переконатися, що він не завантажується із зайвою затримкою;

4. після змін потрібно повторно перевірити LCP.

Неправильний висновок:

Потрібно виправити всі рекомендації Lighthouse, не перевіряючи їхній зв’язок із конкретною проблемою.

Рекомендації мають пріоритет. Спочатку виправляйте ті, що:

• впливають на LCP, TBT або INP;

• мають найбільшу потенційну економію;

• стосуються важливих елементів сторінки;

• повторюються на кількох маршрутах.

Lighthouse і реальний досвід користувачів

Lighthouse створює лабораторні дані. Це означає, що він перевіряє сторінку в контрольованих умовах.

Лабораторні дані корисні для:

• пошуку проблем під час розробки;

• порівняння змін;

• перевірки конкретного маршруту;

• швидкого отримання діагностики.

Але вони не описують усіх реальних користувачів. У різних людей можуть бути:

• різні пристрої;

• різна швидкість мережі;

• інші налаштування браузера;

• інші сценарії взаємодії зі сторінкою.

Тому Lighthouse — це інструмент для діагностики, а не єдине джерело оцінки продуктивності.

Типові помилки

Аудит у режимі розробки

Режим розробки Next.js додає службові витрати й може спотворити результат.

Як уникнути: перевіряйте production-збірку через npm run build і npm run start.

Орієнтація лише на загальний бал

Бал 85 сам по собі не пояснює проблему. Потрібно подивитися, яка метрика знизила результат.

Як уникнути: аналізуйте окремо LCP, CLS, TBT, FCP та INP.

Один запуск і остаточний висновок

Один запуск може дати випадково кращий або гірший результат.

Як уникнути: повторіть аудит кілька разів і порівнюйте середню картину.

Спроба виправити все одразу

Довгий список рекомендацій може відволікти від головної проблеми.

Як уникнути: починайте з рекомендацій, які мають найбільший вплив на ключові метрики.

Тестування лише на Desktop

Сторінка може бути швидкою на потужному комп’ютері, але повільною на мобільному пристрої.

Як уникнути: обов’язково запускайте аудит у режимі Mobile.

Плутанина між можливим і гарантованим виграшем

Час, вказаний у Opportunities, є оцінкою, а не гарантією.

Як уникнути: після кожної зміни повторно перевіряйте реальні метрики.

Ігнорування CLS

Сторінка може швидко показувати вміст, але зміщувати його під час завантаження.

Як уникнути: оцінюйте не лише швидкість появи контенту, а й стабільність макета.

Підсумок

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

• Для Next.js основний аудит потрібно виконувати на production-збірці.

• Запускайте перевірку в режимах Mobile і Desktop, якщо важливі обидва типи пристроїв.

• Аналізуйте не лише Performance Score, а й окремі метрики.

• FCP показує появу першого вмісту, LCP — найбільшого елемента, TBT — блокування JavaScript, CLS — зміщення макета, INP — швидкість реакції на взаємодії.

• Розділи Opportunities і Diagnostics допомагають знайти причини проблем.

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

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