Как проверить скорость сайта с помощью Lighthouse и Window Performance

Когда ищут способ проверить скорость сайта, обычно быстро скатываются в одну из двух крайностей. Первая: бесконечно гоняться за красивым баллом в Lighthouse. Вторая: открыть window.performance, увидеть несколько цифр и решить, что диагноз уже поставлен. На практике оба подхода неполные.

Lighthouse хорош как лабораторный инструмент. Он быстро показывает лишний JavaScript, тяжелые изображения, блокирующие рендер ресурсы и регрессии между релизами. А Window Performance API помогает понять, что реально происходит в браузере: какие файлы тормозят загрузку, когда пользователь видит первый полезный контент и не остается ли главный поток занятым даже после того, как страница вроде бы "открылась".

Эта связка особенно полезна для SEO. Медленный LCP, дерганый интерфейс и нестабильная верстка бьют не только по удобству. Они бьют по удержанию пользователя и по конверсии.

Почему одного инструмента недостаточно

Lighthouse отлично подходит для быстрой оценки URL. Но он не воспроизводит весь реальный контекст. Пользователи заходят не только с быстрых ноутбуков и стабильного Wi-Fi. Есть мобильные сети, средние по мощности телефоны, сторонние скрипты, баннеры согласия и куча мелочей, которые в лаборатории не всегда выглядят опасно.

С window.performance вы начинаете задавать более полезные вопросы:

• узкое место в серверном ответе или в стороннем ресурсе;
• медленный LCP вызван hero-изображением, шрифтами или блокировкой рендера;
• страница уже видна, но почему она все еще "тормозит" при взаимодействии.

Вот здесь и начинается нормальная диагностика, а не гадание по одному числу.

Как использовать Lighthouse с пользой

Проще всего работать через Chrome DevTools: открыть страницу, нажать F12, перейти во вкладку Lighthouse, выбрать Mobile или Desktop и запустить анализ. Если нужны сравнения между сборками или интеграция в CI, подключайте CLI.

До запуска DevTools можно прогнать URL через SEO Analyzer, чтобы быстро выделить страницы с явными проблемами производительности и мобильного UX.

Смотреть стоит не столько на общий балл, сколько на детали:

• неиспользуемый JavaScript;
• ресурсы, блокирующие рендер;
• слишком тяжелые изображения в первом экране;
• сторонние скрипты, раздувающие TBT.

Так отчет превращается из красивой оценки в список реальных приоритетов.

Какие метрики важнее читать в первую очередь

Не нужно запоминать весь словарь Lighthouse. Для практики я бы начал с этих показателей:

1. LCP: когда появляется главный видимый контент.
2. INP: насколько быстро страница реагирует на реальные действия пользователя.
3. CLS: насколько сильно "прыгает" макет во время загрузки.
4. FCP: когда экран перестает быть пустым.
5. TBT: сильный лабораторный индикатор блокировок главного потока.

В старых руководствах вы часто увидите TTI и FID. Знать их полезно, но для сегодняшней приоритизации LCP, INP, CLS и TBT обычно важнее.

Что Window Performance API показывает точнее

Здесь вы уже уходите глубже, чем позволяет общий балл.

performance.getEntriesByType('navigation') помогает читать навигационные тайминги. resource показывает медленные файлы. paint полезен, когда нужно понять, когда пользователь вообще увидел что-то осмысленное. А для LCP, CLS и long tasks логичнее использовать PerformanceObserver.

1const nav = performance.getEntriesByType('navigation')[0];
2const resources = performance.getEntriesByType('resource');
3
4console.log('DOMContentLoaded:', nav.domContentLoadedEventEnd);
5console.log('Load event:', nav.loadEventEnd);
6console.log(
7  'Top 5 slowest resources:',
8  resources.sort((a, b) => b.duration - a.duration).slice(0, 5)
9);

1const observer = new PerformanceObserver((list) => {
2  for (const entry of list.getEntries()) {
3    console.log(entry.entryType, entry.startTime, entry.duration || entry.value);
4  }
5});
6
7observer.observe({ type: 'largest-contentful-paint', buffered: true });
8observer.observe({ type: 'layout-shift', buffered: true });
9observer.observe({ type: 'longtask', buffered: true });

Если вам нужно корректно собирать INP в продакшене, лучше подключать это к RUM-слою или использовать реализацию уровня web-vitals, а не пытаться обойтись случайным скриптом.

Сравнение по нескольким сетевым профилям особенно полезно. Очень часто страница, которая выглядит "нормально" в хорошем Wi-Fi, разваливается уже на обычном мобильном соединении.

Рабочий процесс, который реально помогает

Не нужен сложный ритуал. Достаточно последовательности, которой можно доверять:

1. Запустите Lighthouse, чтобы найти проблемные страницы и расставить приоритеты.
2. С помощью window.performance разберите, какие ресурсы и какие этапы тормозят.
3. Сверьте вывод с полевыми данными или Search Console.
4. После правок тестируйте снова в тех же условиях, а не в более удобных.

Если основной проблемой оказались тяжелые ассеты, до публикации можно дополнительно почистить их через JavaScript Compressor, CSS Compressor и HTML Compressor.

Вывод

Хороший тест производительности не заканчивается фразой "у нас теперь 96 баллов". Он заканчивается понятным объяснением: почему страница медленная, какая часть стека виновата и какое исправление даст максимальный эффект.

Lighthouse поднимает флаг. Window Performance помогает довести дело до нормальной диагностики. Если хотите начать с широкого обзора, сначала прогоните URL через SeoSpeedup, а потом уже спускайтесь на уровень браузерных таймингов и наблюдения.