Как да прочетете отчет от Lighthouse без паника

Първото правило: оценката не е вашият сайт

Отваряте отчет от Lighthouse за първи път и срещу вас застава стена от числа, цветово кодирани полета и предупреждения за неща, за които никога не сте чували. Естествената реакция е паника. Оценката е червена. Има седемнадесет неуспешни одита. Сайтът със сигурност е счупен?

Вероятно не е. Lighthouse е диагностичен инструмент, а не бележник с оценки. Оценката е синтетичен benchmark, изпълнен в лабораторни условия — често с ограничена връзка, симулираща телефон от среден клас от 2017 г. Тя показва как се представя сайтът ви в този конкретен сценарий, а не как реалните потребители го преживяват в практиката.

Това е важно, защото повечето екипи се фиксират върху оценката и пропускат контекста. Оценка 65 може да е напълно приемлива за сложен web app с данни в реално време. Оценка 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 измерва отзивчивостта — колко бързо страницата реагира на кликове, докосвания и натискания на клавиши. Цел: под 200ms. Ако сте над 500ms, сайтът се усеща муден.

Тези три метрики корелират с реалното потребителско раздразнение. Поправете тях, преди да се тревожите за каквото и да било друго.

Opportunities срещу Diagnostics: знайте разликата

Lighthouse разделя констатациите си в две категории: Opportunities и Diagnostics. Opportunities са подредени според очакваната икономия на време. Diagnostics са допълнителен контекст — неща, които може да са проблеми, а може и да не са.

Започнете с Opportunities. Ако Lighthouse казва, че "Eliminate render-blocking resources" може да спести 1,2 секунди, това е конкретна печалба. Ако казва, че "Reduce unused JavaScript" може да спести 0,1 секунди, вероятно не си струва рефакторингът.

Diagnostics са по-сложни. "Avoid an excessive DOM size" звучи зле, но ако CLS е наред и INP е бърз, големият DOM може да не вреди на никого. Diagnostics са улики, не заповеди. Разследвайте тези, които съвпадат с реалните ви метрики.

Одитите, които обикновено можете да игнорирате

Някои предупреждения на Lighthouse са остатъчни или прекалено агресивни. Ето тези, които най-често предизвикват ненужна паника:

• "Does not use passive listeners to improve scrolling performance" — Това е микрооптимизация, която рядко променя съществено резултата. Освен ако нямате доказателства за накъсано скролване, пропуснете я.
• "Image elements do not have explicit width and height" — Това е важно за CLS, но само ако изображенията причиняват размествания на layout-а. Ако CLS вече е добър, не правете рефакторинг само заради одита.
• "Serve images in next-gen formats" — Да, WebP и AVIF са по-малки. Но ако изображенията ви вече са оптимизирани и LCP е бърз, това е приятно подобрение, не криза.
• "Avoid enormous network payloads" — Lighthouse маркира всичко над 1,6 MB. Но страница от 2 MB, която се зарежда бързо, е по-добра от страница от 500 KB, която блокира рендерирането. Фокусирайте се върху как се доставят байтовете, не само върху общия им размер.

Какво да правите, когато всичко е червено

Ако оценката ви в Lighthouse е под 50 и повечето одити се провалят, вероятно имате една от три основни причини:

1. Неоптимизирани шрифтове. Web fonts все още са най-лесната печалба за производителността на повечето сайтове. Проверете дали зареждате шест дебелини на шрифта, когато използвате само две, или изпращате WOFF файлове вместо WOFF2.
2. CSS и JavaScript, които блокират рендерирането. Ако First Contentful Paint (FCP) е над 3 секунди, нещо пречи на браузъра да рисува. Потърсете големи CSS файлове или синхронни скриптове в <head>.
3. Прекалено големи изображения. Ако LCP елементът е изображение и е 4 MB, това е проблемът. Компресирайте го, зареждайте лениво изображенията под видимата част и използвайте синтаксис за responsive images.

Поправете едно от тези неща и пуснете 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 е шумен. Пуснете го три пъти поред и ще получите три различни оценки, дори на една и съща страница. Причината е, че производителността е променлива — фонови процеси, мрежови колебания и браузърни heuristics влияят на резултата.

За да получите стабилна базова линия, пуснете Lighthouse в incognito mode с изключени всички разширения или използвайте CLI с флага --preset=desktop за по-последователни резултати. Пуснете го три пъти и осреднете оценките. Ако виждате резки колебания (повече от 10 точки), нещо друго не е наред — може би сървърът е бавен или страницата зарежда различни ресурси всеки път.

Пускайте Lighthouse отново след всяка съществена промяна. Въвели сте нова стратегия за шрифтове? Проверете LCP. Lazy-load на изображения? Проверете CLS. Добавили сте скрипт от трета страна? Проверете INP. Производителността не е еднократна поправка; тя е бюджет, който защитавате.

Инструментите, които помагат да действате по констатациите на Lighthouse

Lighthouse ви казва какво е бавно. Невинаги ви казва как да го поправите. За това ви трябват допълнителни инструменти:

• WebPageTest ви дава filmstrip изглед на това как се зарежда страницата, кадър по кадър. Незаменим за диагностициране на проблеми с LCP и CLS.
• Chrome DevTools Performance panel показва точно кой JavaScript блокира main thread. Използвайте го, за да откриете източника на лош INP резултат.
• Инструменти за компресиране на изображения ви позволяват да оптимизирате изображения директно в браузъра, което е по-бързо и по-поверително от качване към услуга на трета страна. Обработката на изображения от клиентската страна е печалба за поверителността, защото изображенията ви никога не напускат машината ви.

Lighthouse е отправната точка. Тези инструменти ви помагат да довършите работата.

Основни изводи

• Оценката ви в Lighthouse е лабораторен benchmark, а не мярка за реалното потребителско изживяване. Сравнете я с полеви данни от CrUX, преди да изпаднете в паника.
• Фокусирайте се първо върху Core Web Vitals (LCP, CLS, INP). Това са метриките, които корелират с потребителското раздразнение и SEO ефекта.
• Приоритизирайте Opportunities според очакваната икономия на време. Игнорирайте Diagnostics, които не съвпадат с реалните ви проблеми с производителността.
• Някои одити — като passive listeners или next-gen image formats — са микрооптимизации. Първо поправете големите неща.
• Пуснете Lighthouse три пъти и осреднете резултатите. Производителността е променлива и едно-единствено изпълнение може да бъде подвеждащо.

FAQ

Q: Защо оценката ми в Lighthouse се променя всеки път, когато го пусна?
A: Lighthouse измерва производителността при променливи условия — скоростта на мрежата, натоварването на CPU и browser heuristics влияят на резултата. Пуснете го три пъти в incognito mode и осреднете оценките за по-стабилна базова линия.

Q: Първо за mobile или за desktop да оптимизирам?
A: Mobile. Lighthouse по подразбиране използва mobile симулация, защото повечето уеб трафик е mobile, а mobile устройствата са по-бавни. Ако mobile оценката ви е добра, desktop оценката обикновено също ще е наред.

Q: Оценката ми в Lighthouse е 95, но сайтът все още се усеща бавен. Какво не е наред?
A: Lighthouse измерва зареждането на страницата, а не интерактивността след зареждане. Проверете INP резултата си и използвайте Chrome DevTools Performance panel, за да профилирате какво се случва, когато потребителите кликват или скролват. Може да имате JavaScript проблем, който Lighthouse не улавя.

Q: Трябва ли ми перфектна оценка 100?
A: Не. Оценка 90+ е отлична. Преследването на 100 често означава оптимизиране на неща, които нямат значение за потребителите. Фокусирайте се върху реални метрики — LCP, CLS, INP — и игнорирайте оценката.

Q: Мога ли да се доверя на Lighthouse, ако използвам много скриптове от трети страни?
A: Lighthouse ще маркира скриптовете от трети страни като проблем, но невинаги може да различи необходимите от ненужните. Използвайте одитите "Avoid enormous network payloads" и "Reduce JavaScript execution time", за да идентифицирате най-големите нарушители, след което решете дали си струва да ги запазите.

Sources

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