Lighthouse

власний аудит Chrome щодо швидкості та якості розмітки

Що це таке

Lighthouse, яку часто називають Google Lighthouse, — програма з відкритим кодом від команди Chrome, яка завантажує одну вебсторінку в контрольованих умовах, записує, що робив браузер, і оцінює результат від 0 до 100 у чотирьох категоріях: продуктивність, доступність, найкращі практики й SEO. Вона працює на будь-якій сторінці, до якої може дістатися, публічній чи закритій входом, а кожна перевірка у звіті посилається на короткий документ про те, навіщо ця перевірка існує і як її пройти.

Той самий рушій працює в чотирьох місцях:

  • у Chrome DevTools, з панелі Lighthouse;
  • у командному рядку, як lighthouse <url> після глобального встановлення через 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 валить збірку. Порогом слугує мінімальна оцінка, максимальне значення метрики або максимальна кількість знайдених елементів:

{
    "ci": {
        "collect": { "numberOfRuns": 5 },
        "assert": {
            "assertions": {
                "categories:accessibility": ["error", { "minScore": 1 }],
                "largest-contentful-paint": [
                    "error",
                    { "maxNumericValue": 2500, "aggregationMethod": "median" }
                ]
            }
        }
    }
}

Як це виглядає на практиці

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

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

Звичку, через яку бюджет варто тримати, видно й у роботі тут, що не має стосунку до жодних оцінок. Розповідь про те, як пакунок стилів скоротили з 87 КБ до 31, починає опис дій словами «Спершу — вимірювання». Дві третини найбільшої таблиці стилів виявилися одним шрифтом, закодованим у base64; третій варіант насиченості шрифту додали до попереднього завантаження лише тоді, коли дані реального використання показали, що саме він завершує найдовший критичний ланцюжок; а сучасний формат зображень для фірмового знака виміряли й відхилили, бо файл вийшов більшим. За кожним рішенням там стоїть вимірювання, зокрема й за тим, що закінчилося відмовою. Підказкам Lighthouse потрібне те саме ставлення: кожна з них — гіпотеза, доки вимірювання не покаже, що вона допомогла.

Де виникають проблеми

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

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

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

Лабораторну оцінку сприймають як досвід відвідувачів. 98 на ноутбуці розробниці каже, що сторінка може бути швидкою; лише польові дані кажуть, чи була вона такою. Дивіться польову частину в PageSpeed Insights і зважайте, що для сторінки з малою кількістю відвідувань там будуть дані всього її джерела.

Підказки плутають з оцінкою. Opportunities і Diagnostics не входять до оцінки продуктивності; вони впливають на неї лише через метрики, які покращують. Оберіть підказку, що має зрушити важливу для цієї сторінки метрику, внесіть зміну й виміряйте знову.

Ідеальна оцінка стає метою. Посібник з оцінювання називає 100 надзвичайно складним результатом і каже, що його не очікують. Коли сторінка вже в зеленій зоні, останні бали коштують більше, ніж дають.

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

Що почитати далі

  • Introduction to Lighthouse — способи запуску, категорії звіту й де лежить документація до кожного аудиту.
  • Lighthouse performance scoring — ваги метрик за версіями, криві оцінювання й кольорові зони.
  • Lighthouse accessibility score — як зважують аудити і чому ручні перевірки не входять до оцінки.
  • Score Variability — джерела шуму, що зменшує кожне з них, і чому варто запускати кілька разів.
  • About PageSpeed Insights — лабораторні й польові дані, 75-й процентиль і оцінка Core Web Vitals.
  • Lighthouse CI configuration — кілька прогонів, написання тверджень і вибір способу поєднання прогонів.

Словник