Веб-показатели сайта: как понять LCP, INP и CLS и что исправлять

Если владелец сайта открывает PageSpeed Insights и видит красные цифры, первая реакция понятна: «Сколько стоит сделать всё зелёным?» Но это немного похоже на просьбу автомеханику сделать зелёными все лампочки на приборной панели. Сначала полезнее понять, что именно плохо работает и замечает ли это клиент.

Под веб-показателями обычно имеют в виду Core Web Vitals — три метрики пользовательского опыта Google: LCP, INP и CLS. Они отвечают соответственно за появление основного контента, реакцию интерфейса и визуальную стабильность страницы. Текущие ориентиры Google: LCP ≤ 2,5 секунды, INP ≤ 200 мс и CLS ≤ 0,1 на 75-м процентиле посещений.

Три показателя — три совершенно разные проблемы

Представим обычный интернет-магазин мебели.

Покупатель открывает карточку дивана. Заголовок и меню появились, а большая фотография товара ещё несколько секунд пустая. Это проблема, которую способен показать LCP.

Фотография появилась, посетитель нажал «Добавить в корзину», но кнопка будто задумалась о смысле жизни и ответила с задержкой. Здесь уже интересен INP.

Наконец, человек собирался нажать кнопку, но сверху догрузился рекламный баннер, всё содержимое съехало вниз и палец попал в другую ссылку. Так выглядит плохой CLS.

Метрика	Что видит клиент	Хороший ориентир
LCP	основной крупный контент появляется достаточно быстро	≤ 2,5 с
INP	страница быстро отвечает на клики и нажатия	≤ 200 мс
CLS	элементы неожиданно не прыгают	≤ 0,1

Важно именно разделять эти ситуации. «Сайт медленный» — слишком общий диагноз. При хорошем LCP интерфейс может тормозить после клика, а при отличном INP страница способна раздражающе перестраиваться во время загрузки.

Влияют ли веб-показатели на SEO

Да, но здесь особенно легко продать владельцу сайта красивую легенду.

Google прямо пишет, что Core Web Vitals используются его системами ранжирования. Но в той же документации компания уточняет: хорошие результаты Core Web Vitals не гарантируют верхних позиций, а пытаться добиться идеальных оценок исключительно ради SEO может быть не лучшим использованием ресурсов.

То есть логика «было 78 баллов PageSpeed, сделали 98 — завтра будем в топ-3» официального подтверждения не имеет.

Более правильная схема такая:

техническая проблема → неудобство реального пользователя → исправление причины → повторное измерение → оценка общего результата сайта.

Core Web Vitals также не нужно путать с индексированием. Плохой CLS сам по себе не запрещает Google добавить страницу в индекс, а хороший LCP не исправит закрытый robots.txt, ошибочный noindex или неправильный canonical.

С производительностью сервера связь тоже требует аккуратности. Например, долгий ответ сервера способен ухудшать LCP, а постоянная нестабильность сервера уже имеет значение и для работы поискового робота. Но это не означает, что число LCP является «показателем краулинга».

Если проблема выглядит шире одной скорости — вместе проседают шаблоны страниц, индексирование, техническая доступность и органический трафик — разумнее рассматривать её как часть SEO-продвижения сайта, а не заказывать отдельную магическую услугу «сделать PageSpeed зелёным».

Почему PageSpeed и Search Console могут показывать разную картину

Это один из самых важных моментов для владельца бизнеса.

Search Console и данные CrUX показывают опыт реальных пользователей. Отчёт Core Web Vitals группирует похожие URL и оценивает их по LCP, INP и CLS. Причём страница может вообще отсутствовать в отчёте, если для неё или группы недостаточно данных.

PageSpeed Insights дополнительно запускает лабораторный Lighthouse-тест. Это уже контролируемая симуляция конкретной загрузки страницы. Она отлично подходит для поиска технической причины, но один такой запуск не равен месяцу реальной эксплуатации сайта.

Полевые данные PageSpeed Insights формируются из CrUX за скользящий 28-дневный период. Поэтому ситуация «мы вчера всё исправили, а старые плохие значения всё ещё видны» совершенно нормальна: реальные данные обновляются не мгновенно.

Проще говоря, лабораторный тест — это осмотр машины в сервисе. Полевые данные — статистика того, как эта машина ездила по реальным дорогам последние недели. Нужны оба источника.

Подробнее о типичных причинах можно посмотреть в материале почему сайт медленно загружается.

TBT: полезный показатель, но не четвёртый Core Web Vital

В Lighthouse можно встретить TBT — Total Blocking Time. Его иногда ошибочно ставят рядом с LCP, INP и CLS как ещё один основной веб-показатель.

Это неверно.

TBT считает суммарное время, когда основной поток браузера был занят длинными задачами и не мог быстро обработать ввод пользователя. Lighthouse считает блокирующей часть задачи сверх 50 мс.

Для владельца сайта можно представить это как единственного кассира, которому одновременно выдали распечатать накладную, пересчитать склад и ответить бухгалтерии. Формально магазин открыт, но обслужить покупателя прямо сейчас некому.

TBT особенно полезен в лабораторной диагностике JavaScript. Google также рекомендует его как лабораторный ориентир при поиске причин проблем с INP, поскольку сам полноценный INP требует реальных взаимодействий пользователя. Но TBT и INP измеряют разные вещи и не являются взаимозаменяемыми.

Исправлять нужно причину, а не название метрики

После диагностики задача обычно становится гораздо приземлённее.

При плохом LCP стоит искать, что задерживает основной элемент первого экрана: ответ сервера, hero-изображение, CSS, шрифты, JavaScript или неправильный приоритет загрузки. Если первым тормозит сервер, полезно отдельно проверить влияние хостинга и TTFB.

При плохом INP чаще приходится разбирать JavaScript, тяжёлые обработчики событий, сторонние виджеты и длинные задачи основного потока. Сайт может открыться быстро, а потом тормозить именно в тот момент, когда покупатель открывает меню, фильтр или корзину.

При плохом CLS ищут элементы, для которых заранее не зарезервировано место: изображения без размеров, рекламные блоки, embeds, поздно вставляемый контент или шрифты. Пользователь не должен играть с кнопкой в догонялки.

Главный принцип: сначала найти конкретный проблемный шаблон и конкретную причину, затем менять сайт. Иначе оптимизация превращается в коллекцию плагинов, каждый из которых обещает ускорить предыдущий.

Практический пример: интернет-магазин после запуска акции

Возьмём условный магазин, где после запуска рекламной кампании владельцу сообщили: «PageSpeed стал хуже».

На первый взгляд причина очевидна — новый баннер. Но проверка показывает сразу три разных проблемы.

Большая фотография товара на первом экране получила lazy loading и стала появляться поздно — пострадал LCP.

Акционный блок вставляется над карточкой товара уже после начала загрузки и сдвигает контент — растёт CLS.

Одновременно подключили новый чат и рекламный скрипт, которые выполняют много JavaScript на основном потоке — лабораторный TBT увеличился, а у части реальных пользователей ухудшился INP.

Решение здесь не «поставить ещё один оптимизатор». Hero-изображению возвращают нормальный приоритет загрузки, для акционного блока заранее резервируют место, а сторонние скрипты пересматривают по необходимости и моменту запуска.

После этого сначала повторяют лабораторный тест, чтобы убедиться, что причина устранена и ничего не сломалось. Затем следят за полевыми данными.

Именно поэтому полноценный технический аудит сайта полезнее списка из десяти советов «включите кэш и минификацию»: одинаковая красная метрика у двух сайтов может иметь совершенно разные причины.

Когда работу действительно можно считать законченной

Не тогда, когда исполнитель прислал скриншот с зелёным кружком.

Сначала должна исчезнуть причина: основной контент действительно появляется вовремя, интерфейс нормально отвечает на действия, элементы страницы не скачут. Затем это подтверждается повторным лабораторным тестом на важных шаблонах сайта.

После этого нужно смотреть полевые данные и динамику групп URL. Core Web Vitals оцениваются по реальным посещениям и 75-му процентилю, поэтому итоговая картина важнее рекорда одного тестового запуска.

Для бизнеса критерий ещё проще: не покупайте «баллы PageSpeed». Покупайте устранение конкретной причины, которая делает страницу медленной, тормозящей или нестабильной. Тогда техническая работа одновременно становится понятной пользователю, разработчику и владельцу сайта.