Основные веб-показатели сайта — что это такое и как их измерить

Анатолий Кузнецов

SEO-оптимизатор с 20-летним стажем. Автор блога hozyindachi.ru о продвижении и доработке сайтов.

Core Web Vitals — набор из трёх метрик, которыми Google измеряет, насколько сайтом комфортно пользоваться: быстро ли появляется основной контент, быстро ли страница отвечает на действия и не прыгает ли вёрстка под пальцем. Звучит абстрактно, пока не посмотришь на цифры: разница между страницей, которая показывает контент за 2 секунды, и страницей, которой нужно 5, — это десятки процентов отказов. В российских реалиях 2026 года у метрик двойственный статус: Яндекс не использует их как формальный фактор ранжирования в том виде, в каком это делает Google, но реагирует на последствия — поведение пользователей. Ниже разбираю, что означает каждая метрика, какие пороги считаются нормой, чем измерять и что конкретно чинить.

Что такое Core Web Vitals простыми словами

В наборе три метрики, и каждая отвечает за свой тип раздражения пользователя.

LCP (Largest Contentful Paint) — скорость отрисовки основного контента. Браузер засекает момент, когда на экране появился самый крупный видимый элемент: обычно это главная картинка, баннер или большой блок текста. Это ответ на вопрос «как быстро я увидел то, за чем пришёл».

INP (Interaction to Next Paint) — отзывчивость. Измеряет задержку между действием пользователя (клик, тап, нажатие клавиши) и визуальным откликом страницы. В отличие от старого FID, который учитывал только первое взаимодействие и только задержку до начала обработки, INP смотрит на все взаимодействия за сессию и берёт худшие. Метрика заменила FID в марте 2024 года и оказалась заметно строже: сайты, у которых FID был зелёным, на INP часто проваливаются.

CLS (Cumulative Layout Shift) — стабильность вёрстки. Считает, насколько сильно элементы страницы сдвигаются во время загрузки. Классическая ситуация: вы целитесь в кнопку, сверху догружается баннер, всё уезжает вниз, и палец попадает не туда. CLS — безразмерная величина, произведение доли сдвинувшейся площади экрана на расстояние сдвига.

Есть ещё вспомогательные метрики, которые формально в ядро не входят, но без них не диагностировать проблему: TTFB (время до первого байта — как быстро ответил сервер) и FCP (первая отрисовка чего угодно).

Пороговые значения: LCP, INP, CLS в цифрах

Пороги едины и не зависят от тематики сайта. Важнейшая деталь, о которой забывают: оценка берётся не по среднему, а по 75-му перцентилю — то есть у 75% посещений показатель должен укладываться в норму. Если у четверти пользователей всё плохо, страница уже не в зелёной зоне. Мобильные и десктопные данные считаются отдельно, и мобильные почти всегда хуже.

Страница считается прошедшей проверку, только если все три основные метрики в зелёной зоне одновременно. Два из трёх — это не «почти прошли», это не прошли.

Отдельно про LCP: в него входит и время ответа сервера, и загрузка ресурса, и задержка отрисовки. Поэтому LCP в 5 секунд может быть вызван как медленным хостингом, так и одной нессжатой картинкой на 4 мегабайта. Диагностика начинается с разложения LCP на составляющие.

Лабораторные и полевые данные: почему цифры расходятся

Самая частая причина непонимания — человек прогоняет страницу через тест, получает 92 балла и удивляется, почему в отчёте Search Console страница красная. Дело в том, что это два разных типа данных.

Лабораторные (синтетические) данные — результат одного прогона в контролируемых условиях: заданная скорость канала, заданное устройство, чистый кэш. Они воспроизводимы и удобны для отладки, но не отражают реальность ваших посетителей.

Полевые данные — то, что реально произошло у пользователей с их телефонами, их интернетом, их браузерами. Именно они учитываются при оценке страницы и именно их видно в Search Console. Собираются за скользящее окно в 28 дней, поэтому эффект от ваших правок появляется в отчётах не сразу, а через 3–4 недели.

Практический вывод: чинить надо по лабораторным данным (они дают быструю обратную связь), а оценивать успех — по полевым, через месяц.

Как чинить LCP

LCP — самая частая проблема и одновременно самая понятная. Порядок действий:

1. Найдите сам LCP-элемент. Инструменты его подсвечивают. Часто выясняется, что это не то, что вы думали: не главная картинка, а огромный заголовок или фоновое изображение.
2. Сократите время ответа сервера. TTFB выше 800 мс означает, что дальше оптимизировать фронтенд почти бесполезно. Лечится кэшированием страниц, ускорением запросов к базе, переездом на нормальный хостинг. На типовой CMS кэш страниц даёт самый большой прирост из всех возможных мер.
3. Оптимизируйте изображение. Форматы WebP или AVIF вместо JPEG и PNG, размеры под реальный контейнер (картинка 3000 px, показываемая в блоке 600 px, — прямая потеря секунд), атрибут srcset для разных экранов.
4. Не откладывайте загрузку главной картинки. Массовое ленивое подгружение всех изображений подряд — типичная ошибка: LCP-картинка тоже попадает под lazy-load и появляется позже. Первому экрану ставится fetchpriority="high", ленивая загрузка — только тому, что ниже сгиба.
5. Уберите блокирующие ресурсы. CSS и синхронные скрипты в шапке тормозят отрисовку. Критический CSS выносится инлайном, остальное грузится асинхронно.
6. Ускорьте шрифты. Свои шрифты в формате woff2, font-display: swap, предзагрузка используемых начертаний. Без этого текст ждёт шрифт и LCP растёт.
7. Включите современные протоколы и сжатие. HTTP/2 или HTTP/3, сжатие Brotli или gzip.

Как чинить INP

INP — метрика про JavaScript. Если страница долго думает после клика, значит, основной поток браузера занят.

• Уберите лишний JavaScript. Самое действенное. На типовом сайте на популярной CMS половина скриптов приходит от плагинов, которыми никто не пользуется. Аудит подключённых скриптов обычно даёт возможность выкинуть 30–50% кода.
• Разбейте длинные задачи. Любая непрерывная задача дольше 50 мс блокирует отклик. Тяжёлые вычисления делятся на части с передачей управления браузеру между ними.
• Отложите сторонние скрипты. Счётчики, чаты, виджеты отзывов, коллтрекинг, пиксели рекламных систем — главные виновники плохого INP. Их подключают с задержкой или по первому взаимодействию пользователя, а не в момент загрузки.
• Проверьте обработчики событий. Тяжёлая логика прямо в обработчике клика — прямая дорога к INP за 500 мс. Сначала визуальный отклик, потом вычисления.
• Следите за размером DOM. Страницы с десятками тысяч узлов пересчитывают стили медленно. Бесконечные ленты и мегаменю особенно опасны.
• Тестируйте на слабом устройстве. На флагманском телефоне INP всегда хороший. Включайте замедление процессора в 4–6 раз — это и будет опыт реального пользователя со средним смартфоном.

Как чинить CLS

Самая дешёвая в исправлении метрика: обычно правки занимают часы, а не недели.

• Задавайте размеры изображениям и видео. Атрибуты width и height или CSS-свойство aspect-ratio. Браузер заранее резервирует место, и вёрстка не прыгает.
• Резервируйте место под рекламу и виджеты. Блок фиксированной высоты под баннер решает проблему целиком. Пустое место лучше скачущего контента.
• Не вставляйте контент над уже отрисованным. Плашки согласия на cookie, уведомления, промо-полосы должны быть наложением, а не элементом потока, сдвигающим страницу.
• Предзагружайте шрифты. Подмена системного шрифта на фирменный меняет высоту строк и генерирует сдвиг. Предзагрузка и подбор запасного шрифта с похожими метриками убирают эффект.
• Анимируйте через transform. Анимации свойств, влияющих на геометрию (высота, отступы), считаются сдвигами. Анимация через transform и opacity — нет.

Яндекс и Google: разное отношение к скорости

Здесь надо быть точным, потому что вокруг темы много мифов.

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

Яндекс официально не оперирует набором LCP/INP/CLS. У него свои измерения скорости — в Вебмастере есть раздел с показателями загрузки, а в Метрике видно время ответа сервера и время загрузки страницы. Но ключевой момент в другом: Яндекс очень чувствителен к поведенческим факторам. Медленный сайт даёт больше отказов, короче визиты, чаще возвраты в выдачу. То есть влияние скорости на позиции в Яндексе реальное, просто оно опосредованное — не через метрику, а через поведение людей.

Отсюда практический вывод для российских проектов: не гонитесь за цифрой в отчёте, гонитесь за ощущением. Если страница на среднем телефоне при мобильном интернете открывается за 2 секунды и не прыгает — этого достаточно и для Яндекса, и для Google, и главное, для пользователя.

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

Когда за зелёной зоной гнаться не надо и типичные ошибки

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

• Не стоит начинать со скорости, если проблема в другом. Сайт без нормального контента и структуры не начнёт ранжироваться от того, что LCP снизился с 3 до 2 секунд. Скорость — усилитель, а не двигатель.
• Не гонитесь за 100 баллами PageSpeed. Балл — сводный индекс, а не Core Web Vitals. Разница между 85 и 98 баллами обычно незаметна пользователю, а стоит десятков часов работы.
• Не жертвуйте функциональностью. Отключить онлайн-чат ради INP, потеряв при этом четверть заявок, — плохая сделка. Считайте деньги, а не баллы.
• Не оптимизируйте главную вместо шаблонов. Трафик приходит на карточки товаров и статьи. Правки надо делать в шаблонах массовых страниц.
• Не ставьте плагин «ускорения» и не считайте задачу решённой. Агрессивная минификация и объединение файлов часто ломают вёрстку и формы. После любой такой настройки обязательно проверьте отправку заявки — это первое, что отваливается.
• Не проверяйте результат сразу. Полевые данные обновляются со скользящим окном в 28 дней. Судить об эффекте раньше чем через месяц бессмысленно.
• Не тестируйте только на своём компьютере. Ваш ноутбук с проводным интернетом — не аудитория. Смотрите разбивку по устройствам в Метрике и оптимизируйте под преобладающее.

Веб-показатели — часть технического здоровья сайта. Привожу их в норму в рамках доработки; посмотреть свои цифры и список проблем можно через бесплатную проверку.

Коротко

• Core Web Vitals — три метрики: LCP (появление главного контента), INP (отклик на действия, заменил FID в 2024 году), CLS (сдвиги вёрстки).
• Пороги «хорошо»: LCP до 2,5 с, INP до 200 мс, CLS до 0,1. Оценка берётся по 75-му перцентилю, мобайл и десктоп считаются отдельно, зачёт только при всех трёх зелёных.
• Лабораторные данные нужны для отладки, полевые — для оценки. Полевые обновляются окном в 28 дней, поэтому эффект правок виден через месяц.
• LCP чинится через ответ сервера, кэш, сжатие картинок в WebP/AVIF и снятие ленивой загрузки с первого экрана.
• INP чинится сокращением JavaScript и отложенной загрузкой сторонних виджетов — чатов, счётчиков, коллтрекинга.
• CLS чинится за пару часов: размеры у картинок, резерв места под баннеры, предзагрузка шрифтов, анимации через transform.
• Яндекс не использует LCP/INP/CLS напрямую, но реагирует на поведение пользователей, которое от скорости зависит напрямую. Google учитывает метрики как вспомогательный сигнал.
• 100 баллов PageSpeed — не цель. Цель — чтобы на среднем телефоне страница открывалась примерно за 2 секунды и не прыгала под пальцем.

Если нужно раскрутка сайта в Яндексе — помогу вывести сайт в топ Яндекса и удержать позиции.

Увеличьте позиции и продажи вашего сайта

Профессиональное SEO-продвижение с гарантией результата. Выберите подходящую услугу:

01 Бесплатный аудит сайта 02 SEO-продвижение 03 Создание сайтов 04 SEO-статьи для сайта

Получить консультацию

Остались вопросы по продвижению?

Меня зовут Анатолий Кузнецов, я SEO-оптимизатор с 20-летним стажем. Разберу ваш сайт, отвечу на вопросы и подскажу, что улучшить для роста позиций в Яндексе и Google.

Связаться со мной →