Как Core Web Vitals влияют на позиции сайтов в Яндексе?

История и эволюция Core Web Vitals: от Google к Яндексу

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

Core Web Vitals — это набор технических метрик, которые измеряют скорость загрузки, интерактивность и визуальную стабильность страницы с точки зрения реального пользователя, а не синтетического теста.

Вы открываете PageSpeed Insights и видите три цветовых индикатора: зелёный, жёлтый, красный. Это и есть Core Web Vitals в действии. Но откуда взялась эта система — и почему она важна не только для Google?

Концепцию Core Web Vitals Google анонсировал в 2020 году как часть инициативы по стандартизации оценки пользовательского опыта (UX). До этого скорость сайта учитывалась в ранжировании фрагментарно: Google использовал время загрузки страницы как один из сигналов, но единой метрической системы не существовало. Разные инструменты давали несопоставимые результаты, и веб-разработчики не имели чёткого ориентира, что именно оптимизировать. Core Web Vitals закрыли этот пробел: три конкретных показателя с понятными порогами «хорошо / требует улучшения / плохо» стали отраслевым стандартом измерения производительности. Эти пороги и рекомендации описаны в документации Google Search Central — Core Web Vitals.

С мая 2021 года Google официально включил Core Web Vitals в алгоритм ранжирования как часть обновления Page Experience. Это означало, что страницы с плохими показателями могли терять позиции в Google даже при высоком качестве контента. Отрасль восприняла сигнал серьёзно: технические метрики UX перестали быть факультативной темой и вошли в стандартный чек-лист SEO-оптимизации.

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

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

Практически это означает: оптимизировать Core Web Vitals имеет смысл вне зависимости от того, в каком поисковике продвигается сайт. Разница в том, как измерять результат. Для Яндекса ориентир — не абстрактный «зелёный» в PageSpeed Insights, а динамика поведенческих метрик в Яндекс.Метрике: показатель отказов, время на сайте, глубина просмотра в разбивке по типам страниц и источникам трафика.

Как устроены Core Web Vitals: механика расчета LCP, INP и CLS

Три метрики Core Web Vitals измеряют разные аспекты взаимодействия пользователя со страницей — и каждая работает по собственному принципу расчёта на уровне браузера.

• LCP (Largest Contentful Paint) — скорость загрузки. Браузер фиксирует момент, когда в области видимости отрисовался самый крупный элемент: обычно это главное изображение, видео-обложка или крупный текстовый блок. Отсчёт идёт с момента начала навигации по странице. Если крупный элемент — изображение из внешнего CDN, которое загружается после основного HTML, LCP будет высоким, даже когда сама страница технически «загружена».
• INP (Interaction to Next Paint) — интерактивность. Браузер измеряет задержку между действием пользователя (клик, нажатие клавиши, тап) и следующей визуальной реакцией страницы. INP учитывает все взаимодействия за сессию и берёт значение, близкое к худшему — не среднее. Поэтому одна «тяжёлая» кнопка с медленным JS-обработчиком портит показатель всей страницы.
• CLS (Cumulative Layout Shift) — визуальная стабильность. Браузер отслеживает неожиданные смещения элементов в процессе загрузки: баннер, который «выталкивает» текст вниз, или изображение без заданных размеров, которое появляется и сдвигает кнопку. CLS — это не время, а безразмерная оценка суммы таких смещений.

Согласно справке Google Search Central по Core Web Vitals, удобство страницы оценивается именно по этим трём параметрам — скорости загрузки, интерактивности и визуальной стабильности. Google Search Central — Core Web Vitals и результаты поиска

На каждую метрику влияют разные слои стека. LCP зависит от времени ответа сервера, приоритизации ресурсов и наличия блокирующих рендеринг скриптов. INP — от объёма JavaScript на главном потоке браузера: длинные задачи (long tasks) не дают браузеру обработать ввод пользователя вовремя. CLS — от того, заданы ли размеры изображений и блоков в CSS до их загрузки, и от динамически вставляемого контента (рекламные блоки, всплывающие баннеры).

Принципиальное различие — между полевыми и лабораторными данными. Полевые данные (field data) собираются с реальных пользователей: браузер Chrome отправляет замеры в агрегированный отчёт Chrome User Experience Report (CrUX). Лабораторные данные (lab data) — это эмуляция в инструментах вроде PageSpeed Insights или Lighthouse: фиксированная скорость соединения, виртуальное устройство, один прогон. Лабораторные данные воспроизводимы и удобны для отладки, но не отражают реальный разброс устройств и каналов связи ваших пользователей. Сайт может показывать отличные результаты в лабораторном тесте и при этом иметь плохой CLS у пользователей на медленных соединениях — из-за рекламного блока, который подгружается асинхронно.

Для диагностики без недоступных в РФ инструментов Google используйте PageSpeed Insights напрямую через браузер (он работает без авторизации) или Screaming Frog с интеграцией PageSpeed API — он пакетно проверяет метрики по всем URL сайта и выгружает результаты в таблицу.

Core Web Vitals и Яндекс: какие метрики реально влияют на позиции

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

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

В Google ситуация иная: Core Web Vitals входят в алгоритм ранжирования как явный сигнал в рамках так называемого Page Experience Update, что зафиксировано в справке Google Search Central — Page Experience. Яндекс аналогичного механизма публично не объявлял. Это принципиальное различие: для Google плохой LCP — прямой минус в ранжировании, для Яндекса — только если он ухудшает поведение аудитории.

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

Исключение из общего правила — мобильная выдача. Яндекс открыто говорит о приоритете мобильного опыта, и здесь скоростные метрики влияют на поведение особенно сильно: мобильные пользователи менее терпеливы к медленным страницам, а доля мобильного трафика в Рунете стабильно высока. Это делает LCP и CLS критичными именно для мобильной версии сайта.

Полевые и лабораторные методы измерения: как и чем замерять Core Web Vitals без VPN

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

Лабораторные измерения (синтетические) — это запуск страницы в контролируемых условиях: фиксированная скорость сети, эмулированное устройство, один запуск. Инструмент сам загружает страницу, измеряет метрики и выдаёт результат. Никакого реального пользователя нет. Это удобно для диагностики: можно воспроизвести условие, сравнить до и после изменений, найти конкретный элемент, который тормозит LCP. Но лабораторный результат не отражает то, что видит ваша аудитория — с разными устройствами, разными провайдерами, разной нагрузкой на сервер в пиковые часы.

Полевые данные (реальные, RUM — Real User Monitoring) собираются с браузеров живых пользователей во время их визитов. Это агрегат тысяч реальных сессий — разные устройства, регионы, качество связи. Именно полевые данные учитывают поисковики при оценке скорости сайта, потому что они отражают реальный опыт. Лабораторный тест может показать хороший LCP, а полевые данные — что у половины мобильных пользователей страница грузится вдвое дольше из-за медленного 4G в регионах.

Теперь конкретно по инструментам — какие работают без ограничений доступа:

• PageSpeed Insights — главный инструмент для быстрой проверки. Показывает и лабораторные метрики (через Lighthouse), и полевые данные из Chrome UX Report. Открывается напрямую, без каких-либо ограничений. Введите URL страницы — получите разбивку по LCP, INP, CLS с цветовой индикацией и конкретными рекомендациями по элементам. Google PageSpeed Insights — документация
• Яндекс.Метрика — собирает реальные данные о скорости загрузки страниц от ваших пользователей. Раздел «Мониторинг» → «Время загрузки страниц» показывает распределение по устройствам и страницам. Это не Core Web Vitals в чистом виде, но реальные данные о производительности именно вашей аудитории — без каких-либо ограничений доступа. Яндекс.Метрика — справка по мониторингу
• Яндекс Вебмастер — в разделе «Качество сайта» фиксирует сигналы о скорости и удобстве страниц. Данные агрегированные, но позволяют увидеть системные проблемы с производительностью на уровне групп страниц.
• Screaming Frog SEO Spider — лабораторный инструмент. Интегрируется с PageSpeed Insights API и при обходе сайта собирает метрики по каждому URL. Удобно для массовой проверки: загрузили список страниц, получили таблицу с LCP, INP, CLS по каждой. Бесплатный режим ограничен по числу URL, платная версия снимает ограничение.
• web.dev/measure и Lighthouse в браузере Chrome (DevTools → вкладка Lighthouse) — лабораторные инструменты для разовой диагностики конкретной страницы. Запускаются локально, не требуют никаких аккаунтов.

Практическая схема работы: PageSpeed Insights даёт быстрый срез по конкретным URL с полевыми данными — начинайте с него. Если полевые данные недостаточны (мало трафика, новый сайт), переключайтесь на лабораторный режим того же инструмента. Screaming Frog подключайте для массового аудита, когда нужно проверить не одну страницу, а весь каталог или все посадочные. Яндекс.Метрику используйте для мониторинга динамики — изменилась ли скорость после правок на сервере или после обновления шаблона.

Типичные причины плохих значений Core Web Vitals и ошибки оптимизации

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

• Тяжёлые изображения без отложенной загрузки — главный враг LCP. Страница загружает hero-изображение в оригинальном размере, без сжатия и без атрибута loading="lazy" на некритичных картинках. В результате браузер тратит секунды на загрузку файла, который мог весить в несколько раз меньше. Типичная ошибка оптимизации — конвертировать изображения в WebP, но забыть про fetchpriority="high" на главном элементе: браузер не знает, что именно нужно загрузить первым, и тратит полосу пропускания на второстепенные ресурсы.
• Блокирующий рендеринг (render-blocking) CSS и JavaScript замедляет LCP и INP. Браузер не может отрисовать страницу, пока не загрузит и не выполнит все синхронные скрипты в <head>. Распространённая ошибка — добавлять сторонние скрипты аналитики, чатов и виджетов без атрибутов async или defer. Каждый такой скрипт добавляет задержку перед первой отрисовкой. На проектах с тремя-пятью сторонними виджетами суммарная задержка часто оказывается значительной — даже если каждый скрипт по отдельности весит немного.
• Медленный сервер и отсутствие кэширования увеличивают время до первого байта (TTFB). LCP не может быть хорошим, если сервер долго отвечает. Хостинг на дешёвом виртуальном сервере без CDN, без серверного кэша и с тяжёлыми запросами к базе данных — классическая комбинация. Ошибка оптимизации: улучшать только фронтенд (сжимать картинки, минифицировать CSS), игнорируя серверную часть. Если TTFB высокий, никакая клиентская оптимизация не вытянет LCP в приемлемые значения.
• Динамически подгружаемый контент вызывает сдвиги макета (CLS). Баннеры, рекламные блоки, шрифты и изображения без заданных размеров появляются после начальной отрисовки и сдвигают уже прочитанный текст. Частая ошибка — подключать веб-шрифты без font-display: swap или optional: браузер сначала рисует страницу системным шрифтом, потом заменяет его загруженным — и весь текстовый блок смещается. Аналогичная проблема с рекламными блоками без явно зарезервированного пространства.
• Тяжёлые обработчики событий и длинные задачи JavaScript ухудшают INP. Если на клик или ввод текста браузер выполняет объёмный JavaScript (пересчёт корзины, фильтрация каталога, анимации), пользователь видит задержку реакции. Ошибка — считать, что INP касается только мобильных устройств: на слабых десктопах и ноутбуках с перегретым процессором та же страница может реагировать заметно медленнее, чем на тестовом MacBook разработчика.

Отдельный класс ошибок — оптимизация «для инструмента», а не для пользователя. Команда улучшает показатель в Lighthouse, запуская его на пустой странице без сторонних скриптов, а реальные пользователи получают страницу с тремя виджетами, двумя пикселями ретаргетинга и чатом поддержки. Разрыв между лабораторным и полевым результатом в таких случаях бывает кратным. Диагностику начинайте с PageSpeed Insights по реальному URL в продакшне — именно там видны сторонние ресурсы, которые разработчик не учёл в локальном тесте.

Практические рекомендации: шаги для улучшения Core Web Vitals и роста видимости

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

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

1. Определите LCP-элемент. Откройте PageSpeed Insights, введите URL — в разделе диагностики увидите, какой именно элемент браузер считает самым крупным. Обычно это hero-изображение или крупный заголовок первого экрана.
2. Переведите изображения в формат WebP или AVIF. Современные браузеры поддерживают оба формата, а размер файла уменьшается в разы по сравнению с JPEG без потери визуального качества.
3. Добавьте атрибут fetchpriority="high" для LCP-изображения и уберите loading="lazy" с него. Браузер загрузит его в первую очередь, не дожидаясь остальных ресурсов.
4. Настройте CDN с точкой присутствия в России — это сокращает время ответа сервера для основной аудитории.
5. Включите кеширование статики на уровне сервера. Повторный визит пользователя не должен заново загружать изображения и CSS.

INP: реакция страницы на действия пользователя

1. Разбейте длинные задачи JavaScript на части. Браузер не может реагировать на клик пользователя, пока выполняет тяжёлый скрипт — задачи длиннее нескольких десятков миллисекунд блокируют основной поток. Используйте setTimeout или scheduler.yield() для разбивки.
2. Перенесите сторонние скрипты (чаты, виджеты, пиксели) на асинхронную загрузку. Синхронный сторонний скрипт в <head> — типичная причина высокого INP.
3. Проверьте обработчики событий. Слушатели на click и input не должны запускать тяжёлые вычисления синхронно — переносите их в Web Workers или откладывайте через requestIdleCallback.

CLS: устранение сдвигов верстки

1. Задайте явные размеры всем изображениям и видео через атрибуты width и height. Браузер резервирует место под элемент ещё до его загрузки — страница не прыгает.
2. Избегайте вставки контента над видимой областью после загрузки. Баннеры, всплывающие полосы согласия с cookie, динамически подгружаемые блоки — всё это сдвигает контент вниз и увеличивает CLS.
3. Для шрифтов используйте font-display: swap и предзагрузку через <link rel="preload">. Смена системного шрифта на кастомный в момент загрузки — ещё один источник сдвигов.

Мониторинг: Яндекс.Метрика и Яндекс Вебмастер

После внедрения изменений контролируйте динамику через Яндекс.Метрику: раздел «Скорость сайта» показывает время загрузки страниц в разбивке по устройствам на реальных пользователях. Это полевые данные — они точнее синтетических тестов. Параллельно проверяйте Яндекс Вебмастер → «Качество сайта» — здесь агрегируются сигналы о технических проблемах, которые влияют на ранжирование Яндекс Вебмастер — качество сайта.

Для технического аудита после правок запустите краулинг в Screaming Frog: он покажет страницы с отсутствующими атрибутами размеров изображений, блокирующими скриптами в <head> и цепочками редиректов, которые замедляют LCP. Это рабочий инструмент без ограничений доступа из РФ.

Исправления работают не изолированно: улучшение LCP снижает показатель отказов, а стабильная верстка (низкий CLS) увеличивает глубину просмотра — оба сигнала Яндекс учитывает при оценке качества страницы.

Реальные примеры: как оптимизация Core Web Vitals влияет на позиции в Яндексе

Покажем, как оптимизация скорости и стабильности страниц отражается на реальных проектах — с разбором механики, а не просто констатацией факта.

Интернет-магазин: снижение показателя отказов и рост позиций

Допустим, интернет-магазин бытовой техники с каталогом в несколько тысяч страниц. До оптимизации hero-изображения на карточках товаров загружались в оригинальном разрешении, без сжатия. Страница визуально «прыгала» при загрузке блока с ценой и кнопкой «Купить» — CLS был далёк от рекомендованных значений. Яндекс.Метрика фиксировала высокий показатель отказов на мобильных устройствах.

После конвертации изображений в WebP, настройки отложенной загрузки и резервирования блока под динамический контент картина изменилась: пользователи стали дольше оставаться на карточках, глубина просмотра выросла. Поведенческие сигналы — время на сайте, возвращаемость, доля отказов — улучшились. Именно эти метрики Яндекс учитывает при ранжировании Яндекс Вебмастер — факторы ранжирования. Позиции по коммерческим запросам подтянулись в течение нескольких недель после того, как поисковик переобошёл обновлённые страницы.

Информационный портал: скорость как конкурентное преимущество

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

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

Сводная таблица: типы сайтов и эффект оптимизации

Когда улучшения не дают роста позиций

Оптимизация Core Web Vitals срабатывает как рычаг роста не всегда. Три ситуации, где эффект минимален или отсутствует:

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

Заключение

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

На практике работа выглядит так: аудит через PageSpeed Insights → приоритизация по типу страниц (главная, категория, карточка) → исправление самых дорогих ошибок (тяжёлые изображения, блокирующие скрипты, смещение layout-блоков) → контроль динамики в Яндекс Вебмастере. Этот цикл повторяется после каждого крупного обновления сайта.