# Lighthouse ## Що це таке Lighthouse, яку часто називають Google Lighthouse, — програма з відкритим кодом від команди Chrome, яка завантажує одну вебсторінку в контрольованих умовах, записує, що робив браузер, і оцінює результат від 0 до 100 у чотирьох категоріях: продуктивність, доступність, найкращі практики й SEO. Вона працює на будь-якій сторінці, до якої може дістатися, публічній чи закритій входом, а кожна перевірка у звіті посилається на короткий документ про те, навіщо ця перевірка існує і як її пройти. Той самий рушій працює в чотирьох місцях: - у Chrome DevTools, з панелі Lighthouse; - у командному рядку, як `lighthouse ` після глобального встановлення через npm; - як модуль Node у власному скрипті; - за PageSpeed Insights, сервісом Google, який запускає її на машинах Google. Оцінка продуктивності складається лише з метрик, виміряних під час завантаження: First Contentful Paint, Speed Index, Largest Contentful Paint, Total Blocking Time і Cumulative Layout Shift. Кожну метрику розміщують на кривій, побудованій за даними реальних сайтів з HTTP Archive, а оцінка категорії — це зважене середнє цих п'яти. У Lighthouse 10 вага Total Blocking Time становить 30%, Largest Contentful Paint і Cumulative Layout Shift — по 25%, а двох інших — по 10%. Ваги змінювалися між версіями, бо команда постійно досліджує, що найбільше впливає на те, наскільки швидкою здається сторінка. Крива має дві опорні точки. Значення метрики на рівні 25-го процентиля архіву дає 50 балів, а на рівні 8-го — 90. Для всіх п'яти метрик менше означає краще, тож сторінка з 50 балами за однією з них уже випереджає три чверті виміряних сайтів; 50 — це не середній результат. Угорі крива вирівнюється: щоб піднятися з 99 до 100, потрібно приблизно стільки ж покращення, скільки для переходу з 90 до 94. Три інші категорії натомість оцінюються за аудитами. У доступності кожен аудит або пройдено, або ні, без балів за часткове проходження; вагу кожного визначає оцінка рушія правил axe щодо того, наскільки сильно збій б'є по користувачах, а перевірки, яким потрібна людина, не входять до оцінки й виносяться в окремий список для ручного перегляду. ## Чому це важливо Рішення, якому служить Lighthouse, стосується того, чи зміна зробила сторінку повільнішою, менш зручною чи важчою для пошуку і чи має це зупинити випуск. Відповідь приходить у формі, з якою може працювати машина: число, ті самі аудити щоразу й звіт, який може прочитати скрипт. Тому її досить дешево запускати на кожній зміні, а не раз перед запуском продукту. Число — це лабораторне вимірювання: один профіль пристрою, одна імітована мережа, одне завантаження. PageSpeed Insights показує різницю, ставлячи поруч два види даних. Лабораторна частина — це прогін Lighthouse. Польова частина походить із Chrome UX Report: те, що реальні користувачі Chrome отримали за попередні 28 днів, на рівні 75-го процентиля, щоб число описувало більшість відвідувачів, а не найщасливіших. Для сторінки, у якої замало власних відвідувань, показують дані всього її джерела (origin). Документація попереджає, що ці дві частини можуть розходитися. Від цього поділу залежить, для чого придатна кожна з них. Польові дані кажуть, чи є в користувачів проблема, але надходять через тижні після зміни й нічого не кажуть про гілку, яку ще не випущено. Лабораторні дані можна зібрати до випуску й так часто, як треба, і саме тому вони годяться як запобіжник, але описують лише один імітований візит. Друга межа — шум. Посібник з оцінювання пропонує сприймати продуктивність як розподіл оцінок, а не одне число, і перелічує причини поза самою сторінкою: A/B-тести й змінну рекламу, зміни маршрутизації в інтернеті, потужний настільний комп'ютер проти слабкого ноутбука, розширення браузера й антивіруси. Поріг, перевірений на одному прогоні, падатиме випадково. Посібник проєкту про варіативність дає цьому рішенню число: медіана п'яти прогонів удвічі стабільніша за один прогін. Lighthouse CI перетворює це на правило. Він запускає Lighthouse кілька разів для кожної адреси, за замовчуванням тричі, поєднує прогони й перевіряє результат за твердженнями (assertions) для цілої категорії або одного аудиту. Твердження рівня `warn` лише повідомляє, а рівня `error` валить збірку. Порогом слугує мінімальна оцінка, максимальне значення метрики або максимальна кількість знайдених елементів: ```json { "ci": { "collect": { "numberOfRuns": 5 }, "assert": { "assertions": { "categories:accessibility": ["error", { "minScore": 1 }], "largest-contentful-paint": [ "error", { "maxNumericValue": 2500, "aggregationMethod": "median" } ] } } } } ``` ## Як це виглядає на практиці [Сторінка подяк](/uk/credits/) цього сайту називає Lighthouse серед інструментів, які сайт запускає проти себе на тій самій машині, де його пишуть, і дає йому одне завдання: стежити за бюджетами продуктивності. Бюджет — це межа, погоджена заздалегідь, щоб сторінка, яка стала повільнішою, провалювала перевірку, а не відкривала суперечку про те, чи важать кілька сотень мілісекунд. Пізніший розділ тієї ж сторінки посилається на PageSpeed Insights серед перевірок, які читач може запустити сам, і каже, що цей сервіс запускає Lighthouse з машин Google, а не з машин сайту, а там, де відвідувачів достатньо, додає дані реальних користувачів. Сторінка навмисно тримає ці два розділи окремо. Перший — це сайт, що сам собі виставляє оцінки; другий віддає ті самі питання інструментам, які сайтові не належать і не вірять йому на слово. Звичку, через яку бюджет варто тримати, видно й у роботі тут, що не має стосунку до жодних оцінок. Розповідь про те, як [пакунок стилів скоротили з 87 КБ до 31](/uk/portfolio/cut-the-stylesheet-bundle-from-87kb-to-31kb-139/), починає опис дій словами «Спершу — вимірювання». Дві третини найбільшої таблиці стилів виявилися одним шрифтом, закодованим у base64; третій варіант насиченості шрифту додали до попереднього завантаження лише тоді, коли дані реального використання показали, що саме він завершує найдовший критичний ланцюжок; а сучасний формат зображень для фірмового знака виміряли й відхилили, бо файл вийшов більшим. За кожним рішенням там стоїть вимірювання, зокрема й за тим, що закінчилося відмовою. Підказкам Lighthouse потрібне те саме ставлення: кожна з них — гіпотеза, доки вимірювання не покаже, що вона допомогла. ## Де виникають проблеми Більшість помилок із Lighthouse походить від того, що число читають як щось більше, ніж воно є. **Один прогін сприймають як істину.** Один звіт показує 94, наступний — 87, і хтось шукає регресію, якої не було. Порівнюйте медіани кількох прогонів і свідомо обирайте спосіб агрегації в Lighthouse CI: твердження без параметрів бере з усіх прогонів значення, яке найімовірніше пройде, тож регресія прослизне, якщо її уникне хоча б один прогін. **Прогони збирають паралельно.** Коли десять адрес перевіряють одночасно на одній машині, вони змагаються за процесор, пам'ять і мережу, і посібник про варіативність прямо радить цього не робити. Запускайте їх по черзі або на кількох машинах; для Lighthouse кілька малих машин кращі за одну велику. **Лабораторну оцінку сприймають як досвід відвідувачів.** 98 на ноутбуці розробниці каже, що сторінка може бути швидкою; лише польові дані кажуть, чи була вона такою. Дивіться польову частину в PageSpeed Insights і зважайте, що для сторінки з малою кількістю відвідувань там будуть дані всього її джерела. **Підказки плутають з оцінкою.** Opportunities і Diagnostics не входять до оцінки продуктивності; вони впливають на неї лише через метрики, які покращують. Оберіть підказку, що має зрушити важливу для цієї сторінки метрику, внесіть зміну й виміряйте знову. **Ідеальна оцінка стає метою.** Посібник з оцінювання називає 100 надзвичайно складним результатом і каже, що його не очікують. Коли сторінка вже в зеленій зоні, останні бали коштують більше, ніж дають. **Повну оцінку доступності сприймають як доступну сторінку.** 100 там означає, що пройшли автоматичні аудити. Ручні перевірки стоять поряд з оцінкою й ніколи не враховуються, тож сторінка може мати 100 і все одно бути непридатною для роботи з клавіатури. ## Що почитати далі - [Introduction to Lighthouse](https://developer.chrome.com/docs/lighthouse/overview) — способи запуску, категорії звіту й де лежить документація до кожного аудиту. - [Lighthouse performance scoring](https://developer.chrome.com/docs/lighthouse/performance/performance-scoring) — ваги метрик за версіями, криві оцінювання й кольорові зони. - [Lighthouse accessibility score](https://developer.chrome.com/docs/lighthouse/accessibility/scoring) — як зважують аудити і чому ручні перевірки не входять до оцінки. - [Score Variability](https://github.com/GoogleChrome/lighthouse/blob/main/docs/variability.md) — джерела шуму, що зменшує кожне з них, і чому варто запускати кілька разів. - [About PageSpeed Insights](https://developers.google.com/speed/docs/insights/v5/about) — лабораторні й польові дані, 75-й процентиль і оцінка Core Web Vitals. - [Lighthouse CI configuration](https://github.com/GoogleChrome/lighthouse-ci/blob/main/docs/configuration.md) — кілька прогонів, написання тверджень і вибір способу поєднання прогонів.