Як читати звіт Lighthouse без паніки

Перше правило: ваш бал — це не ваш сайт

Коли ви вперше відкриваєте звіт Lighthouse, перед вами постає стіна чисел, кольорових блоків і попереджень про речі, про які ви ніколи не чули. Природна реакція — паніка. Бал червоний. Сімнадцять аудитів не пройдено. Невже сайт зламаний?

Найімовірніше, ні. Lighthouse — це діагностичний інструмент, а не табель оцінок. Бал — це синтетичний бенчмарк, запущений у лабораторних умовах, часто на уповільненому з’єднанні з імітацією телефона середнього класу з 2017 року. Він показує, як ваш сайт працює в цьому конкретному сценарії, а не те, як реальні користувачі сприймають його в реальних умовах.

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

Що читати спочатку: Core Web Vitals

Пропустіть загальний бал продуктивності. Прокрутіть до розділу Metrics і подивіться на три числа: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) та Interaction to Next Paint (INP). Це Core Web Vitals, і це єдині метрики продуктивності, які Google використовує як сигнал ранжування.

• LCP вимірює, скільки часу потрібно, щоб відрендерився найбільший видимий елемент. Ціль: менше 2,5 секунди. Якщо у вас понад 4 секунди, користувачі надто довго чекають, щоб побачити змістовний контент.
• CLS вимірює візуальну стабільність — наскільки сторінка «стрибає» під час завантаження. Ціль: менше 0,1. Якщо у вас понад 0,25, користувачі випадково натискають не те, бо кнопки зміщуються.
• INP вимірює чутливість — як швидко сторінка реагує на кліки, дотики та натискання клавіш. Ціль: менше 200 мс. Якщо у вас понад 500 мс, сайт відчувається повільним.

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

Opportunities і Diagnostics: знайте різницю

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

Починайте з Opportunities. Якщо Lighthouse каже, що «Усунення ресурсів, які блокують рендеринг» може заощадити 1,2 секунди, це конкретний виграш. Якщо він каже, що «Зменшення невикористаного JavaScript» може заощадити 0,1 секунди, це, ймовірно, не варте рефакторингу.

З Diagnostics складніше. «Уникайте надмірного розміру DOM» звучить погано, але якщо ваш CLS у нормі, а INP швидкий, великий DOM може нікому не шкодити. Diagnostics — це підказки, а не накази. Досліджуйте ті, що узгоджуються з вашими фактичними метриками.

Аудити, які зазвичай можна ігнорувати

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

• «Не використовує пасивні слухачі для покращення продуктивності прокручування» — Це мікрооптимізація, яка рідко суттєво впливає на результат. Якщо у вас немає доказів ривків під час прокручування, пропустіть її.
• «Елементи зображень не мають явних width і height» — Це важливо для CLS, але лише якщо зображення спричиняють зміщення макета. Якщо ваш CLS уже хороший, не робіть рефакторинг лише заради аудиту.
• «Подавайте зображення у форматах нового покоління» — Так, WebP і AVIF менші. Але якщо ваші зображення вже оптимізовані, а LCP швидкий, це приємне покращення, а не криза.
• «Уникайте величезних мережевих навантажень» — Lighthouse позначає все, що перевищує 1,6 MB. Але сторінка на 2 MB, яка швидко завантажується, краща за сторінку на 500 KB, яка блокує рендеринг. Зосередьтеся на тому, як доставляються байти, а не лише на їхній загальній кількості.

Що робити, коли все червоне

Якщо ваш бал Lighthouse нижчий за 50 і більшість аудитів провалено, ви, ймовірно, маєте справу з однією з трьох першопричин:

1. Неоптимізовані шрифти. Вебшрифти досі залишаються найпростішим виграшем у продуктивності на більшості сайтів. Перевірте, чи не завантажуєте ви шість насиченостей шрифту, коли використовуєте лише дві, або чи не відправляєте WOFF-файли замість WOFF2.
2. CSS і JavaScript, що блокують рендеринг. Якщо ваш First Contentful Paint (FCP) перевищує 3 секунди, щось заважає браузеру намалювати сторінку. Шукайте великі CSS-файли або синхронні скрипти в <head>.
3. Завеликі зображення. Якщо ваш елемент LCP — це зображення, і воно має 4 MB, ось ваша проблема. Стисніть його, застосуйте lazy-load до зображень нижче першого екрана та використовуйте синтаксис адаптивних зображень.

Виправте одне з цього й запустіть Lighthouse повторно. Часто ви побачите стрибок на 20–30 пунктів. Потім беріться за наступне.

Лабораторні дані проти польових: перевірка реальністю

Lighthouse працює в лабораторії. Він імітує повільне з’єднання та повільний пристрій, але не може імітувати реальну поведінку користувачів — як люди прокручують, на що натискають, чи сидять вони на нестабільному Wi-Fi.

Для перевірки реальністю порівняйте результати Lighthouse із польовими даними з Chrome User Experience Report (CrUX). CrUX показує, як реальні користувачі Chrome взаємодіяли з вашим сайтом за останні 28 днів. Якщо Lighthouse каже, що ваш LCP — 4 секунди, а CrUX показує 2 секунди, довіряйте CrUX. Якщо погано і там, і там, у вас справжня проблема.

Дані CrUX можна знайти в PageSpeed Insights (вебверсії Lighthouse) або в Google Search Console у розділі «Core Web Vitals». Якщо є розбіжність, з’ясуйте чому. Можливо, ваші реальні користувачі мають швидші мережі. Можливо, Lighthouse тестує неоптимізовану dev-збірку.

Коли запускати Lighthouse повторно

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

Щоб отримати стабільну базову лінію, запускайте Lighthouse у режимі інкогніто з вимкненими розширеннями або використовуйте CLI з прапорцем --preset=desktop для більш узгоджених результатів. Запустіть його тричі й усередніть бали. Якщо бачите різкі коливання (понад 10 пунктів), щось іще не так — можливо, сервер повільний або сторінка щоразу завантажує різні ресурси.

Запускайте Lighthouse повторно після кожної суттєвої зміни. Впровадили нову стратегію шрифтів? Перевірте LCP. Додали lazy-load для зображень? Перевірте CLS. Додали сторонній скрипт? Перевірте INP. Продуктивність — це не одноразове виправлення, а бюджет, який ви захищаєте.

Інструменти, які допомагають діяти за результатами Lighthouse

Lighthouse каже, що повільне. Він не завжди каже, як це виправити. Для цього потрібні додаткові інструменти:

• WebPageTest дає покадровий перегляд того, як завантажується сторінка. Це необхідно для діагностики проблем із LCP і CLS.
• Панель Chrome DevTools Performance точно показує, який JavaScript блокує головний потік. Використовуйте її, щоб знайти джерело поганого показника INP.
• Інструменти стиснення зображень дають змогу оптимізувати зображення безпосередньо в браузері — це швидше й приватніше, ніж завантажувати їх у сторонній сервіс. Клієнтська обробка зображень — це виграш для приватності, бо ваші зображення ніколи не залишають ваш пристрій.

Lighthouse — це відправна точка. Ці інструменти допомагають довести роботу до кінця.

Основні висновки

• Ваш бал Lighthouse — це лабораторний бенчмарк, а не вимір реального користувацького досвіду. Порівняйте його з польовими даними CrUX, перш ніж панікувати.
• Спочатку зосередьтеся на Core Web Vitals (LCP, CLS, INP). Саме ці метрики корелюють із фрустрацією користувачів і впливом на SEO.
• Пріоритизуйте Opportunities за оціненою економією часу. Ігноруйте Diagnostics, які не узгоджуються з вашими фактичними проблемами продуктивності.
• Деякі аудити — наприклад, пасивні слухачі або формати зображень нового покоління — це мікрооптимізації. Спочатку виправляйте великі речі.
• Запускайте Lighthouse тричі й усереднюйте результати. Продуктивність змінна, і один запуск може вводити в оману.

FAQ

П: Чому мій бал Lighthouse змінюється щоразу, коли я його запускаю?
В: Lighthouse вимірює продуктивність у змінних умовах: швидкість мережі, навантаження на CPU та евристики браузера впливають на результат. Запустіть його тричі в режимі інкогніто й усередніть бали, щоб отримати стабільнішу базову лінію.

П: Спочатку оптимізувати для mobile чи desktop?
В: Mobile. За замовчуванням Lighthouse використовує мобільну симуляцію, бо більшість вебтрафіку — мобільна, а мобільні пристрої повільніші. Якщо ваш mobile-бал хороший, desktop-бал зазвичай теж буде в нормі.

П: Мій бал Lighthouse — 95, але сайт усе одно здається повільним. Що не так?
В: Lighthouse вимірює завантаження сторінки, а не інтерактивність після завантаження. Перевірте показник INP і скористайтеся панеллю Chrome DevTools Performance, щоб профілювати, що відбувається, коли користувачі клікають або прокручують. Можливо, у вас проблема з JavaScript, яку Lighthouse не ловить.

П: Чи потрібен мені ідеальний бал 100?
В: Ні. Бал 90+ — чудовий. Погоня за 100 часто означає оптимізацію речей, які не важливі для користувачів. Зосередьтеся на реальних метриках — LCP, CLS, INP — і ігноруйте бал.

П: Чи можна довіряти Lighthouse, якщо я використовую багато сторонніх скриптів?
В: Lighthouse позначить сторонні скрипти як проблему, але не завжди може відрізнити необхідні від зайвих. Використовуйте аудити «Уникайте величезних мережевих навантажень» і «Зменште час виконання JavaScript», щоб визначити найбільших порушників, а потім вирішіть, чи варто їх залишати.

Джерела

• «Lighthouse performance scoring» — Google Developers
• «Core Web Vitals» — web.dev
• «Chrome User Experience Report» — Google Developers
• «WebPageTest Documentation» — WebPageTest.org