Core Web Vitals: что это и как влияет на SEO

Коротко. Core Web Vitals — три метрики Google, которые оценивают удобство страницы для реальных людей: LCP (скорость загрузки главного контента), INP (отклик интерфейса на действия) и CLS (стабильность вёрстки). Нормы — LCP до 2,5 с, INP до 200 мс, CLS до 0,1 по 75-му перцентилю реальных посетителей. Это фактор ранжирования, но вторичный к релевантности: он решает, когда страницы конкурентов одинаково полезны.

Google задаёт для Core Web Vitals конкретные пороги: по документации Search Central, главный контент страницы должен загружаться за 2,5 секунды, отклик на действия — укладываться в 200 миллисекунд, а сдвиги вёрстки — не превышать 0,1. С 12 марта 2024 года метрика INP официально заменила старую FID, и требования к отзывчивости сайтов стали заметно строже. А кейс Vodafone показывает, почему это не только про SEO: ускорение LCP на 31% в A/B-тесте дало +8% продаж.

При этом вокруг Core Web Vitals много мифов. Одни считают, что зелёный балл PageSpeed автоматически поднимет сайт в топ, другие — что скорость вообще ничего не значит, если контент хороший. Истина посередине, и в этой статье мы разберём её без преувеличений: что именно измеряют LCP, INP и CLS, как Google официально описывает их роль в ранжировании, чем полевые данные отличаются от лабораторных и почему они так часто расходятся.

Материал будет полезен владельцам сайтов, маркетологам и разработчикам, которые получили письмо из Search Console о «плохих URL» и хотят понять, что с этим делать. Мы закладываем хорошие показатели ещё на этапе архитектуры и вёрстки, когда занимаемся созданием сайтов под ключ, — исправлять производительность готового проекта всегда дороже, чем не допустить проблем на старте.

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

Core Web Vitals (в русском интерфейсе Google Search Console — «Основные интернет-показатели») — это набор из трёх метрик, по которым Google оценивает, насколько удобно реальным людям пользоваться страницей: как быстро она показывает главное, как быстро реагирует на действия и не «прыгает» ли контент во время загрузки. Метрики измеряются не в лаборатории, а в браузерах настоящих посетителей, поэтому отражают реальный пользовательский опыт, а не идеальные условия на компьютере разработчика.

Инициатива Web Vitals появилась у Google как попытка дать вебу единый понятный язык для разговора о качестве сайтов. До неё существовали десятки метрик производительности — Time to First Byte, First Contentful Paint, Speed Index, DOMContentLoaded, onload, — и разные команды оптимизировали разные числа, часто не связанные с тем, что чувствует пользователь. Core Web Vitals — это сжатое ядро: три показателя, которые Google считает самыми важными для любой страницы в интернете.

Место Core Web Vitals в page experience

Core Web Vitals — часть более широкой концепции page experience, или «удобство страницы». В описании page experience Google перечисляет и другие аспекты удобства:

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

Из всего этого набора только Core Web Vitals выражены в конкретных цифрах с порогами. Поэтому именно они стали главным объектом внимания SEO-специалистов: их можно измерить, сравнить с нормой, поставить задачу разработчику и проверить результат.

Почему именно эти три метрики

Каждая метрика отвечает на один вопрос, который пользователь неосознанно задаёт любой странице:

«Оно загружается?» — на этот вопрос отвечает LCP: появился ли на экране главный контент, ради которого человек пришёл.
«Оно реагирует?» — INP: откликается ли интерфейс, когда человек нажимает кнопку, открывает меню или вводит текст.
«Оно стабильно?» — CLS: не прыгают ли блоки, пока человек читает или пытается попасть пальцем по ссылке.

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

Какие метрики входят в Core Web Vitals: LCP, INP и CLS

В Core Web Vitals на 2026 год входят три метрики: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) и Cumulative Layout Shift (CLS). Каждая измеряет свой аспект пользовательского опыта, имеет собственные пороги и собственные типичные причины проблем. Разберём их по очереди.

LCP — скорость загрузки главного контента

Largest Contentful Paint (LCP) — это время от начала загрузки страницы до момента, когда в видимой области экрана отрисован самый крупный блок контента. Именно этот блок пользователь обычно воспринимает как «главное»: заголовок статьи, большую обложку, фото товара, первый экран лендинга. Пока он не появился, человеку кажется, что страница ещё не загрузилась, сколько бы мелких элементов ни было уже на экране.

LCP-элементом могут стать:

изображения <img>, в том числе внутри <picture>;
изображения внутри SVG-элемента <image>;
постер видео (атрибут poster) или первый кадр видео;
фоновое изображение, подключённое через CSS url();
блочные элементы с текстом — например, крупный абзац или заголовок.

Браузер переопределяет LCP-кандидата по ходу загрузки: сначала самым большим может оказаться заголовок, затем — подгрузившаяся обложка. Финальным считается последний кандидат до первого взаимодействия пользователя со страницей. Это важно для диагностики: оптимизировать нужно именно тот элемент, который браузер в итоге выбрал, а не тот, который кажется главным дизайнеру.

Хороший LCP — до 2,5 секунды. От 2,5 до 4 секунд — «требует улучшения». Больше 4 секунд — плохо.

INP — отзывчивость интерфейса

Interaction to Next Paint (INP) — это метрика отзывчивости, которая показывает, сколько времени проходит от действия пользователя (клик, касание, нажатие клавиши) до момента, когда браузер отрисует следующий кадр с визуальным откликом. Проще говоря, INP отвечает на вопрос: как долго человек ждёт, пока интерфейс «отреагирует» на его действие.

Ключевое отличие INP — он учитывает все взаимодействия за визит, а не только первое. Если пользователь провёл на странице пять минут, открывал фильтры, раскрывал аккордеоны и вводил текст в форму, то в расчёт попадут все эти действия. Итоговое значение близко к самому медленному взаимодействию: для страниц с очень большим числом взаимодействий браузер отбрасывает единичные выбросы, чтобы одна случайная задержка не испортила оценку.

Задержка взаимодействия складывается из трёх частей:

Input delay — время, пока главный поток браузера занят другой работой и не может начать обработку события.
Processing time — время выполнения самих обработчиков события (ваш JavaScript).
Presentation delay — время на пересчёт стилей, раскладку и отрисовку следующего кадра.

Хороший INP — до 200 миллисекунд. От 200 до 500 мс — «требует улучшения». Больше 500 мс — плохо. Для пользователя 500 мс — это уже ощутимая пауза: человек успевает подумать, что нажатие не сработало, и нажимает повторно.

CLS — визуальная стабильность

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

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

Типичные источники сдвигов:

изображения и видео без заданных размеров (width и height);
рекламные блоки, баннеры и встраиваемые виджеты, которые подгружаются позже основного контента;
динамически вставленный контент — плашки cookie, промо-полосы, уведомления над уже показанным текстом;
веб-шрифты, при загрузке которых меняются размеры текста (FOIT/FOUT);
анимации, которые меняют свойства раскладки (top, height, margin) вместо transform.

Хороший CLS — до 0,1. От 0,1 до 0,25 — «требует улучшения». Больше 0,25 — плохо.

Смещение элементов страницы при загрузке на смартфоне

Сводная таблица метрик и норм

Все пороги взяты из документации web.dev и применяются к 75-му перцентилю загрузок страницы — отдельно для мобильных устройств и десктопа.

Метрика	Что измеряет	Хорошо	Требует улучшения	Плохо	Частые причины проблем
LCP (Largest Contentful Paint)	Когда отрисован самый крупный элемент первого экрана	≤ 2,5 с	2,5–4 с	> 4 с	Тяжёлая обложка, медленный сервер (TTFB), блокирующие CSS/JS, ленивая загрузка hero
INP (Interaction to Next Paint)	Задержка от действия пользователя до визуального отклика по всем взаимодействиям визита	≤ 200 мс	200–500 мс	> 500 мс	Длинные задачи JavaScript, сторонние скрипты, тяжёлые обработчики, большой DOM
CLS (Cumulative Layout Shift)	Неожиданные сдвиги видимых элементов	≤ 0,1	0,1–0,25	> 0,25	Медиа без размеров, баннеры и виджеты, вставки над контентом, веб-шрифты

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

Чем INP отличается от FID и почему Google его заменил

INP — это метрика, которая 12 марта 2024 года заменила First Input Delay (FID) в составе Core Web Vitals. Официальное объявление вышло в блоге web.dev, а FID после этого был выведен из отчётов и инструментов Google. Если вы видите FID в старых статьях или чек-листах — эти материалы устарели.

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

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

Параметр	FID (до марта 2024)	INP (с 12 марта 2024)
Какие взаимодействия учитывает	Только первое	Все клики, касания и нажатия клавиш за визит
Что измеряет	Только задержку до начала обработки (input delay)	Полное время: задержка + выполнение обработчиков + отрисовка следующего кадра
Порог «хорошо»	≤ 100 мс	≤ 200 мс
Насколько строгая оценка	Мягкая: большинство сайтов проходили	Строгая: выявляет «тормоза» на протяжении всего визита
Что чаще всего ломает метрику	Тяжёлый JS во время загрузки	Тяжёлый JS в любой момент: загрузка, фильтры, формы, SPA-переходы
Статус в 2026 году	Устарел, в отчётах Google не используется	Действующая метрика Core Web Vitals

Порог у INP формально выше (200 мс против 100 мс), но это не послабление: INP меряет гораздо больше работы. Сайтам с тяжёлыми SPA-фреймворками, большим количеством сторонних скриптов и сложными интерфейсами (интернет-магазины, личные кабинеты, сервисы бронирования) после замены пришлось заниматься отзывчивостью всерьёз.

Как Core Web Vitals влияют на позиции сайта в Google

Core Web Vitals влияют на позиции сайта в Google напрямую как один из сигналов ранжирования и косвенно — через поведение пользователей и конверсию. Но вес этого сигнала ограничен, и Google сам открыто об этом говорит. Разберём, что сказано в официальной документации, а что — домыслы.

Что официально говорит Google

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

Но в материале про page experience Google сразу расставляет приоритеты:

Google всегда стремится показать самый релевантный контент, даже если удобство страницы низкое.
Хорошие результаты в отчёте Core Web Vitals в Search Console не гарантируют, что страница окажется в топе.
Когда есть много одинаково полезных и релевантных страниц, хороший page experience может помочь добиться успеха в поиске.

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

Косвенное влияние: поведение и конверсия

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

Самый показательный публичный пример — кейс Vodafone, опубликованный на web.dev. Компания провела A/B-тест лендинга: в версии с LCP, улучшенным на 31%, общие продажи выросли на 8%, отношение лидов к визитам — на 15%, а отношение добавлений в корзину к визитам — на 11%. Это был не SEO-эксперимент: обе версии получали одинаковый трафик, а различалась только скорость — и разница сразу сказалась на деньгах.

Если вы хотите понять, где именно пользователи спотыкаются на вашем сайте, полезно совместить анализ Core Web Vitals с UX-аудитом сайта: метрики показывают, что страница медленная, а UX-аудит — где это мешает людям совершить целевое действие.

А что с Яндексом

Яндекс официально не заявлял, что использует метрики Core Web Vitals (LCP, INP, CLS) как фактор ранжирования, и не публикует для них порогов. Утверждения «Яндекс понижает сайты с плохим LCP» — домыслы. При этом Яндекс учитывает поведение пользователей, а медленный сайт хуже удерживает аудиторию. Поэтому быстрый и стабильный сайт выигрывает и в Яндексе — но косвенно, через пользовательский опыт, а не через метрики Google напрямую.

Когда Core Web Vitals реально решают, а когда — нет

Метрики заметно влияют на результат, если:

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

Метрики почти не повлияют на позиции, если:

контент страницы слабее, чем у конкурентов, и не отвечает на запрос — здесь скорость не спасёт;
показатели уже в зелёной зоне, и вы пытаетесь улучшить LCP с 1,8 до 1,2 секунды ради SEO;
у страницы нет ссылок, авторитета и поведенческих сигналов, а конкуренты — признанные лидеры ниши;
проблема в индексации, каннибализации или технических ошибках, а не в скорости.

Что важнее для ранжирования — контент или скорость

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

Однако «контент важнее» не значит «скорость не важна». Удобно думать о Core Web Vitals как о минимальных санитарных нормах. Ресторан с прекрасной кухней всё равно потеряет гостей, если в зале грязно, — но вылизанный зал не сделает плохую еду вкусной. Так же и с сайтом: сначала страница должна быть лучшим ответом на запрос, а затем — не мешать пользователю этот ответ получить.

Отдельно стоит помнить, что архитектура сайта и производительность связаны. Перегруженные шаблоны, десятки блоков «на всякий случай», тяжёлые слайдеры на первом экране — это одновременно проблема и контента (размытый фокус страницы), и скорости. Часто лучшая оптимизация Core Web Vitals — убрать с первого экрана то, что не помогает пользователю.

Как расставить приоритеты в зависимости от ситуации:

Ситуация	Что делать в первую очередь	Роль Core Web Vitals
Контент слабее конкурентов, метрики хорошие	Усиливать контент: полнота, экспертиза, структура, ответы на вопросы	Не узкое место, держать на текущем уровне
Контент на уровне конкурентов, метрики «Плохо»	Исправлять Core Web Vitals по самым посещаемым шаблонам	Высокая: может быть тем самым тай-брейкером
Контент слабый, метрики «Плохо»	Начать с контента ключевых страниц, параллельно убрать грубые проблемы скорости	Средняя: без контента рост не начнётся
Контент сильный, метрики «Требует улучшения»	Точечные правки с наибольшим эффектом (обложки, шрифты, сторонние скрипты)	Средняя: доводка до зелёной зоны
Коммерческий сайт с мобильным трафиком	Мобильный LCP и INP карточек и каталога — в приоритете вместе с контентом	Высокая: влияет и на позиции, и на конверсию
Метрики уже «Хорошо» на всех шаблонах	Ссылки, контент, поведенческие факторы, мониторинг регрессий скорости	Низкая: дальнейшее ускорение мало что даст для SEO

Полевые и лабораторные данные: в чём разница

Полевые данные (field data) — это измерения Core Web Vitals в браузерах реальных посетителей, а лабораторные данные (lab data) — измерения в контролируемых синтетических условиях, когда инструмент сам загружает страницу на заданном устройстве и сети. Для ранжирования и для отчёта в Search Console Google опирается на полевые данные. Лабораторные нужны, чтобы найти причину проблемы и проверить исправление.

Как устроены полевые данные

Главный источник полевых данных — Chrome User Experience Report (CrUX), публичный набор данных Google. Его наполняют браузеры Chrome пользователей, которые согласились на отправку статистики. Ключевые свойства CrUX:

Скользящее окно 28 дней. Данные агрегируются за последние четыре недели, поэтому любое изменение на сайте проявляется в отчётах постепенно.
75-й перцентиль. Для оценки берётся значение, лучше которого 75% загрузок. Это защищает от выбросов, но заставляет учитывать медленные устройства.
Раздельно для мобильных и десктопа. Один и тот же URL может быть «зелёным» на компьютерах и «красным» на смартфонах.
Порог по трафику. Если у страницы мало посещений, данных по отдельному URL не будет — только по группе похожих страниц или по всему сайту (origin).

Как устроены лабораторные данные

Основной лабораторный инструмент — Lighthouse: он встроен в Chrome DevTools и используется в PageSpeed Insights для блока «Диагностика». Lighthouse загружает страницу на эмулированном устройстве с заданной скоростью сети и процессора и выдаёт балл от 0 до 100 и список рекомендаций.

Важная деталь: в лаборатории невозможно измерить INP, ведь INP складывается из реальных взаимодействий пользователя. Поэтому Lighthouse использует Total Blocking Time (TBT) как замену — суммарное время, пока главный поток был заблокирован длинными задачами во время загрузки. TBT хорошо коррелирует с проблемами отзывчивости, но не равен INP: он не видит «тормоза», которые возникают позже, при работе с фильтрами или формами.

Почему Lighthouse 100 не означает, что Core Web Vitals пройдены

Это самый частый источник путаницы. Балл Lighthouse — лабораторная оценка одного синтетического прогона, а статус в Search Console — оценка тысяч реальных визитов. Они расходятся, потому что:

реальные пользователи приходят с устройств слабее эмулированного и по сетям хуже тестовых;
в лаборатории нет cookies, авторизации, персонализации, A/B-тестов и рекламы, которые есть у реальных посетителей;
Lighthouse не видит INP, а только TBT во время загрузки;
CLS в лаборатории считается только при загрузке, а в поле — за всё время жизни страницы, включая прокрутку;
CDN, кэши и география: тестовый сервер может находиться рядом с вашим, а пользователь — в другом регионе.

Тип данных	Источник	Что показывает	Когда использовать
Полевые (field)	CrUX, Search Console, PageSpeed Insights (блок реальных пользователей), собственный RUM	Реальный опыт посетителей за 28 дней по 75-му перцентилю, включая INP	Оценить, есть ли проблема, какие шаблоны страдают, подтвердить результат оптимизации
Лабораторные (lab)	Lighthouse, PageSpeed Insights (диагностика), Chrome DevTools Performance	Один синтетический прогон: LCP, TBT, CLS, балл, конкретные причины	Найти причину, отладить исправление, проверить изменения до выкладки
Собственный RUM	JavaScript-библиотека web-vitals + ваша аналитика	Полевые метрики по каждому визиту с привязкой к странице, устройству и элементу	Мало трафика для CrUX, нужна детализация или быстрая обратная связь без ожидания 28 дней

Правильная последовательность работы: полевые данные отвечают на вопрос «есть ли проблема и где», лабораторные — «почему и как исправить», затем снова полевые — «помогло ли».

Как проверить Core Web Vitals сайта: инструменты

Проверить Core Web Vitals можно бесплатными инструментами Google: PageSpeed Insights и отчётом «Основные интернет-показатели» в Search Console — для полевой оценки, Lighthouse и Chrome DevTools — для лабораторной диагностики. Для глубокого мониторинга добавляют данные CrUX и сбор метрик реальных пользователей на собственном сайте. Ниже — сравнение основных инструментов.

Инструмент	Тип данных	Что умеет	Для чего лучше всего
PageSpeed Insights	Полевые + лабораторные	Показывает данные CrUX для URL и всего сайта, плюс отчёт Lighthouse с рекомендациями	Быстрая проверка отдельной страницы
Search Console → «Основные интернет-показатели»	Полевые	Группирует URL с похожими проблемами, показывает статусы для мобильных и десктопа, запускает проверку исправления	Масштаб проблемы по всему сайту, контроль результата
CrUX (CrUX Vis, API, BigQuery)	Полевые	История метрик сайта по месяцам, распределения, сравнение с конкурентами	Динамика, бенчмарк конкурентов, аналитика
Lighthouse (в Chrome DevTools)	Лабораторные	Балл, LCP, TBT, CLS, подробный список проблем и потенциальной экономии	Диагностика и проверка правок до выкладки
Chrome DevTools → Performance	Лабораторные + локальные полевые	Трассировка главного потока, длинные задачи, LCP-элемент, источники сдвигов, замер INP при ваших кликах	Глубокая отладка INP и CLS
Библиотека web-vitals (RUM)	Полевые (свои)	Сбор LCP, INP, CLS с каждого визита с атрибуцией элемента и отправка в аналитику	Детальный мониторинг, сайты без данных CrUX

Как читать отчёт PageSpeed Insights

Отчёт PageSpeed Insights состоит из двух принципиально разных частей, и их нельзя путать.

Верхний блок — данные реальных пользователей. Здесь показаны полевые данные CrUX за последние 28 дней: LCP, INP, CLS и вспомогательные метрики (FCP, TTFB). Над метриками — итоговый вердикт: пройдена ли оценка Core Web Vitals. Есть переключатель «Этот URL / Весь источник»: если по конкретной странице данных недостаточно, смотрите данные по всему сайту. Именно этот блок ближе всего к тому, что видит Google.

Нижний блок — диагностика. Это результат одного прогона Lighthouse с баллом от 0 до 100. Здесь же список возможностей для оптимизации: «Уменьшите неиспользуемый JavaScript», «Правильно задавайте размеры изображений», «Устраните ресурсы, блокирующие отображение» и т. д. Балл нестабилен — при повторном запуске он может отличаться на несколько пунктов, и ориентироваться стоит на конкретные метрики и рекомендации, а не на цифру в круге.

Не забывайте переключать вкладки «Мобильный» и «Компьютер». Начинайте анализ с мобильной версии: там проблемы проявляются чаще и сильнее.

Как читать отчёт в Search Console

Отчёт «Основные интернет-показатели» в Google Search Console показывает не отдельные страницы, а группы URL с похожим пользовательским опытом. Если у вас 2 000 карточек товаров на одном шаблоне, они, скорее всего, попадут в одну группу с общей проблемой — например, «Проблема с LCP: более 2,5 с (мобильные)». Это удобно: исправляя шаблон, вы исправляете сразу всю группу.

Каждая группа получает статус «Хорошо», «Требует улучшения» или «Плохо». Статус определяется по худшей из трёх метрик: если LCP и CLS хорошие, а INP плохой, группа будет «Плохо». После исправления нажмите «Проверить исправление» — Google начнёт отслеживать группу в течение 28 дней и сообщит результат.

Как собрать собственные полевые данные

Собственные полевые данные (RUM, Real User Monitoring) — это метрики Core Web Vitals, которые ваш сайт сам собирает в браузерах посетителей и отправляет в вашу аналитику. Они нужны, когда у страниц мало трафика для CrUX, когда хочется видеть эффект правок через несколько дней, а не через месяц, или когда важно понять, какой именно элемент стал LCP и какое взаимодействие испортило INP.

Проще всего подключить открытую JavaScript-библиотеку web-vitals от команды Chrome. Она измеряет метрики так же, как Chrome для CrUX, и отдаёт значения в колбэк, откуда их можно отправить в любую систему аналитики:

import {onLCP, onINP, onCLS} from 'web-vitals';

function send(metric) {
  navigator.sendBeacon('/rum', JSON.stringify({
    name: metric.name, value: metric.value, page: location.pathname
  }));
}

onLCP(send);
onINP(send);
onCLS(send);

Собранные значения стоит смотреть так же, как Google: по 75-му перцентилю, отдельно для мобильных и десктопа и в разрезе шаблонов страниц. Тогда собственный мониторинг будет предсказывать, что через несколько недель покажет Search Console.

Почему у сайта плохие Core Web Vitals: основные причины

Плохие Core Web Vitals почти всегда вызваны небольшим набором повторяющихся причин: тяжёлыми ресурсами на первом экране, медленным сервером, избытком JavaScript и неучтёнными размерами элементов. Разложим их по метрикам — так проще понять, куда смотреть в первую очередь.

Причины плохого LCP:

Тяжёлое hero-изображение. Обложка в несколько мегабайт в PNG или JPEG без сжатия и без адаптивных размеров.
Обложка без приоритета. Браузер узнаёт о главной картинке поздно — например, она задана фоном в CSS или подгружается скриптом слайдера.
Ленивая загрузка первого экрана. Атрибут loading="lazy" на LCP-изображении заставляет браузер откладывать его загрузку.
Медленный ответ сервера (TTFB). Пока сервер не отдал HTML, ничего не начинает загружаться. Причины — слабый хостинг, отсутствие кэширования, тяжёлые запросы к базе, сервер далеко от пользователей.
Блокирующие CSS и JS. Большие файлы стилей и синхронные скрипты в <head> задерживают первую отрисовку.
Клиентский рендеринг. Если контент собирается JavaScript-фреймворком в браузере, LCP ждёт загрузки и выполнения всего бандла.

Причины плохого INP:

Длинные задачи JavaScript. Любая задача дольше 50 мс блокирует главный поток, и клик пользователя ждёт её окончания.
Сторонние скрипты. Онлайн-чаты, пиксели рекламных систем, виджеты отзывов, A/B-платформы, системы аналитики — каждый добавляет работу в главный поток.
Тяжёлые обработчики событий. Перерисовка всего списка товаров на каждый клик по фильтру, синхронные вычисления, лишние запросы.
Огромный DOM. Тысячи элементов на странице замедляют пересчёт стилей и раскладку после каждого изменения.
Гидратация в SPA. Пока фреймворк «оживляет» серверную разметку, интерфейс выглядит готовым, но не реагирует.

Причины плохого CLS:

Картинки, видео и iframe без размеров. Браузер не знает, сколько места оставить, и сдвигает контент, когда медиа загрузится.
Рекламные места и баннеры без резерва. Блок появляется позже и толкает текст вниз.
Динамические вставки. Плашки cookie, промо-полосы, уведомления, которые вставляются над уже показанным контентом.
Веб-шрифты. Подмена системного шрифта на загруженный меняет ширину и высоту строк.
Анимации свойств раскладки. Изменение height, top, margin вместо transform.

Серверная сторона — TTFB, кэширование, CDN — заслуживает отдельного разговора. Подробно о том, как работают браузерный, серверный и CDN-кэш и как их настроить, мы рассказали в статье про кэширование в веб-разработке. А общие техники ускорения фронтенда и бэкенда собраны в материале о том, как ускорить веб-приложение.

Как улучшить LCP, INP и CLS

Улучшить Core Web Vitals можно, если работать с каждой метрикой отдельно: для LCP — ускорить доставку главного элемента первого экрана, для INP — разгрузить главный поток браузера, для CLS — заранее зарезервировать место под всё, что появляется на странице. Ниже — проверенные приёмы, которые дают основной эффект на большинстве сайтов. Если нужен системный подход с аудитом, приоритизацией и контролем результата, эту работу логично вести в рамках технического SEO-продвижения — тогда оптимизация скорости связана с индексацией, структурой и контентом, а не живёт сама по себе.

Как улучшить LCP

Определите LCP-элемент. Посмотрите его в PageSpeed Insights («Элемент Largest Contentful Paint») или в DevTools. Без этого оптимизация идёт вслепую.
Дайте ему высокий приоритет. Для hero-изображения добавьте fetchpriority="high"; если картинка задана в CSS или подставляется скриптом — добавьте <link rel="preload" as="image">.
Не используйте ленивую загрузку на первом экране. loading="lazy" — только для изображений ниже сгиба.
Сожмите и адаптируйте изображение. Используйте WebP или AVIF, атрибуты srcset и sizes, чтобы смартфон не скачивал картинку для широкого монитора.
Сократите TTFB. Кэшируйте HTML, подключите CDN, оптимизируйте медленные запросы к базе, проверьте тариф хостинга.
Уберите блокирующие ресурсы. Встраивайте критический CSS, остальное подгружайте асинхронно; скрипты подключайте с defer.
Рендерите главный контент на сервере. Для SPA — SSR или статическая генерация ключевых страниц.

Пример правильной разметки hero-изображения:

<img src="/img/hero-1200.webp"
     srcset="/img/hero-800.webp 800w, /img/hero-1200.webp 1200w"
     sizes="(max-width: 900px) 100vw, 1200px"
     width="1200" height="630"
     fetchpriority="high"
     alt="Описание главного изображения">

Как улучшить INP

Разбивайте длинные задачи. Задача дольше 50 мс — кандидат на разбиение. Отдавайте управление браузеру между частями работы (через setTimeout, requestAnimationFrame или scheduler.yield() там, где он поддерживается), чтобы клик пользователя мог обработаться раньше.
Сначала отклик, потом работа. В обработчике события сначала покажите визуальную реакцию (состояние кнопки, лоадер), а тяжёлые вычисления и отправку аналитики отложите.
Наведите порядок в сторонних скриптах. Проведите инвентаризацию: какие пиксели, чаты и виджеты действительно нужны. Остальное — удалить, нужное — загружать отложенно, после первого взаимодействия или по требованию.
Уменьшите объём JavaScript. Разделение кода (code splitting), удаление неиспользуемых библиотек, отказ от тяжёлых полифиллов для современных браузеров.
Упростите DOM и перерисовки. Виртуализация длинных списков, мемоизация компонентов, отказ от синхронного чтения размеров элементов сразу после их изменения.
Тяжёлые вычисления — в Web Worker. Сортировка, фильтрация больших массивов и парсинг данных не должны занимать главный поток.

Как улучшить CLS

Задайте размеры медиа. У каждого <img>, <video> и <iframe> — атрибуты width и height или CSS-свойство aspect-ratio.
Резервируйте место под динамические блоки. Рекламным местам, баннерам и виджетам — фиксированный min-height, даже если блок может не загрузиться.
Не вставляйте контент над существующим. Плашки cookie и уведомления — поверх контента (фиксированное позиционирование) или внизу экрана, а не сверху с раздвиганием страницы.
Укротите шрифты. Используйте font-display: swap или optional, предзагружайте ключевые шрифты и подбирайте метрики запасного шрифта (size-adjust), чтобы подмена не меняла размеры строк.
Анимируйте через transform. Для движения и масштабирования используйте transform и opacity — они не вызывают пересчёт раскладки.

Пример предзагрузки шрифта:

<link rel="preload" href="/fonts/main-cyrillic.woff2"
      as="font" type="font/woff2" crossorigin>

Таблица приоритетов исправлений

Чтобы не распыляться, оценивайте каждую правку по эффекту и сложности. Ниже — типовая матрица, которой мы пользуемся при аудите. Конкретные значения на вашем сайте могут отличаться, но порядок обычно сохраняется.

Правка	Метрика	Эффект	Сложность	Приоритет
Убрать lazy-load с hero, добавить fetchpriority="high"	LCP	Высокий	Низкая	1
Задать width/height всем изображениям и iframe	CLS	Высокий	Низкая	1
Перевести изображения в WebP/AVIF с srcset	LCP	Высокий	Низкая–средняя	1
Отложить или удалить лишние сторонние скрипты	INP, LCP	Высокий	Средняя	2
Предзагрузка шрифтов, font-display	CLS, LCP	Средний	Низкая	2
Резерв места под баннеры, виджеты, плашки	CLS	Средний	Низкая	2
Кэширование HTML, CDN, сокращение TTFB	LCP	Высокий	Средняя–высокая	2
Критический CSS, defer для скриптов	LCP	Средний	Средняя	3
Разбиение длинных задач, оптимизация обработчиков	INP	Высокий	Высокая	3
SSR / статическая генерация для SPA	LCP, INP	Высокий	Высокая	4

Как оптимизировать Core Web Vitals пошагово

Оптимизация Core Web Vitals — это цикл из шести шагов: замер полевых данных, лабораторная диагностика, приоритизация, внедрение правок, контрольный замер и ожидание обновления полевых данных. Сроки ниже — ориентиры для сайта среднего размера; на крупных проектах этапы внедрения и проверки занимают больше времени.

Снимите полевые данные (1 день). Откройте отчёт «Основные интернет-показатели» в Search Console и данные CrUX в PageSpeed Insights. Выпишите группы URL и шаблоны со статусами «Плохо» и «Требует улучшения» — отдельно для мобильных и десктопа. Определите, какая метрика проседает: LCP, INP или CLS.
Проведите лабораторную диагностику (1–2 дня). Возьмите 2–3 типовые страницы каждого проблемного шаблона и прогоните их через Lighthouse и панель Performance в Chrome DevTools. Найдите LCP-элемент, длинные задачи, источники сдвигов вёрстки, тяжёлые ресурсы и сторонние скрипты.
Расставьте приоритеты (полдня). Отсортируйте проблемы по доле трафика шаблона, ожидаемому эффекту и сложности. Исправление шаблона карточки товара, через который идёт 60% органического трафика, важнее идеальной главной страницы.
Внедрите правки (от 1 до 4 недель). Двигайтесь от простого к сложному: сначала изображения и шрифты, затем JavaScript и сторонние скрипты, затем серверная часть — TTFB, кэширование, CDN. Выкатывайте изменения частями, чтобы видеть эффект каждой группы правок.
Сделайте контрольный замер (1 день). Повторите лабораторные тесты на тех же страницах и в тех же условиях. Убедитесь, что LCP, TBT и CLS улучшились, а функциональность не сломалась — особенно формы, корзина и аналитика.
Дождитесь обновления полевых данных (около 28 дней). Нажмите «Проверить исправление» в Search Console. Полевые данные CrUX обновляются скользящим окном, поэтому результат проявится постепенно. Если у вас настроен собственный сбор метрик через web-vitals, эффект будет виден уже через несколько дней.

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

Core Web Vitals для мобильной версии

Core Web Vitals для мобильной версии — главный приоритет, потому что Google использует mobile-first индексацию: для ранжирования он ориентируется прежде всего на мобильную версию страниц. При этом метрики оцениваются отдельно для мобильных устройств и десктопа, и на мобильных они почти всегда хуже.

Причины понятны: смартфоны в среднем слабее компьютеров по производительности процессора, а мобильный интернет медленнее и нестабильнее проводного. То, что на ноутбуке разработчика выполняется за 30 мс, на бюджетном Android-смартфоне может занимать в несколько раз больше — и превращаться в длинную задачу, которая бьёт по INP. А 75-й перцентиль означает, что именно эти слабые устройства определяют итоговую оценку.

На что смотреть в первую очередь на мобильных:

Размер изображений. Смартфон не должен скачивать картинку шириной 2 400 пикселей. Атрибуты srcset и sizes решают это без изменения дизайна.
Объём JavaScript. Разбор и выполнение скриптов на мобильном процессоре — главная причина плохого INP.
Мобильные баннеры и плашки. Всплывающие окна, sticky-панели, баннеры приложений и cookie-уведомления — частые источники CLS именно на мобильных.
Мобильное меню и фильтры. Открытие меню и фильтров каталога — самые частые взаимодействия, и они должны откликаться мгновенно.
Тестирование на реальном устройстве. Эмуляция в DevTools полезна, но проверка на недорогом реальном смартфоне честнее.

Подробнее о том, как мобильная версия влияет на поисковое продвижение в целом, мы писали в статье «Мобильная разработка и SEO».

Частые ошибки при работе с Core Web Vitals

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

Гонка за баллом Lighthouse. Команда неделями добивается 100 в PageSpeed, а полевые данные в Search Console остаются «Плохо». Балл — лабораторная оценка, а Google ориентируется на реальных пользователей. Цель — зелёный статус полевых метрик, а не круглая цифра.
Ленивая загрузка главного изображения. Плагин оптимизации включает loading="lazy" для всех картинок подряд, включая обложку первого экрана. LCP от этого только ухудшается.
Оптимизация только главной страницы. Главную вылизывают до идеала, а органический трафик идёт на карточки товаров, статьи блога и категории — на другие шаблоны с другими проблемами. Работайте с шаблонами по доле трафика.
Новые виджеты без замера. Маркетинг подключает онлайн-чат, квиз, виджет отзывов и ещё один пиксель — и через месяц INP в красной зоне. Любой сторонний скрипт должен проходить проверку влияния на метрики до выкладки.
Разовый аудит без мониторинга. Оптимизацию провели, показатели позеленели, а через полгода обновление темы или CMS всё вернуло. Нужен регулярный контроль: Search Console, CrUX и собственный сбор метрик.
Ожидание мгновенного роста позиций. Полевые данные обновляются около 28 дней, а сам по себе зелёный статус не гарантирует топа. Core Web Vitals — фактор при прочих равных, поэтому оценивать эффект нужно в связке с контентом и ссылками, и на горизонте месяцев.

Core Web Vitals и AI-поиск

Core Web Vitals и AI-поиск связаны косвенно: прямых заявлений Google о том, что метрики LCP, INP и CLS учитываются при выборе источников для AI Overviews и других генеративных ответов, нет. Утверждения вида «плохой LCP исключает сайт из AI-ответов» на 2026 год не подтверждены официальными источниками, и строить на них стратегию не стоит.

При этом базовая логика работает и здесь. Быстрые, технически чистые страницы с главным контентом в серверном HTML проще сканировать и обрабатывать любым системам — и поисковым роботам, и AI-краулерам. Страница, контент которой появляется только после выполнения тяжёлого JavaScript, рискует быть прочитанной не полностью. А если пользователь всё же перешёл из AI-ответа на сайт, медленная загрузка точно так же снижает шанс, что он останется и совершит целевое действие. Поэтому оптимизация Core Web Vitals — разумная гигиена и для AI-поиска, но не волшебный рычаг видимости в нём.

Частые вопросы (FAQ)

Является ли Core Web Vitals фактором ранжирования Google?

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

Какие нормы LCP, INP и CLS считаются хорошими?

Хорошими считаются LCP не более 2,5 секунды, INP не более 200 миллисекунд и CLS не более 0,1. Плохими — LCP больше 4 секунд, INP больше 500 миллисекунд и CLS больше 0,25. Значения между ними требуют улучшения. Оценка идёт по 75-му перцентилю загрузок отдельно для мобильных и десктопа.

Почему PageSpeed показывает 90+, а Search Console — «Требует улучшения»?

Балл PageSpeed Insights — это лабораторная оценка Lighthouse в одном синтетическом прогоне. Search Console показывает полевые данные реальных пользователей Chrome за 28 дней по 75-му перцентилю. Реальные устройства, сети и взаимодействия медленнее тестовых условий, а INP лабораторно вообще не измеряется, поэтому оценки расходятся.

Через сколько обновятся данные после исправлений?

Лабораторный замер покажет эффект сразу после выкладки. Полевые данные CrUX считаются за скользящие 28 дней, поэтому в PageSpeed Insights и Search Console улучшение проявится постепенно и полностью — примерно через месяц. Проверка исправления в Search Console тоже длится около 28 дней.

Нужен ли Core Web Vitals для ранжирования в Яндексе?

Яндекс официально не заявлял, что использует метрики Core Web Vitals в ранжировании. При этом медленный и нестабильный сайт хуже удерживает посетителей и хуже конвертирует, а поведение пользователей Яндекс учитывает. Поэтому оптимизация скорости полезна и для Яндекса, хотя прямой связи с метриками Google нет.

Что делать, если у страницы нет данных CrUX?

У малопосещаемых страниц может не хватать трафика для полевых данных. Тогда смотрите данные по всему источнику (origin) в PageSpeed Insights, группы похожих URL в Search Console, лабораторные замеры Lighthouse и собственный мониторинг реальных пользователей через JavaScript-библиотеку web-vitals.

Можно ли пройти Core Web Vitals на WordPress, Битрикс или Tilda?

Да, платформа сама по себе не запрещает хорошие показатели. Решают тема или шаблон, количество плагинов и модулей, вес изображений, сторонние скрипты и хостинг. На WordPress и Битрикс доступна глубокая оптимизация кода и сервера, на конструкторах вроде Tilda контроль ограничен: основной резерв — изображения, шрифты и число подключённых виджетов.

Core Web Vitals: что это и как влияет на позиции сайта