Core Web Vitals в Яндексе: что Яндекс на самом деле взвешивает

Core Web Vitals (CWV) — это три метрики Google, измеряющие пользовательский опыт через объективные показатели браузера. С 2021 года они официально часть Google Page Experience и идут в ранжирование Google напрямую. У Яндекса аналогичной официальной механики нет, что не значит, что скорость сайта в Яндексе не важна — она важна, но работает иначе.

Что такое CWV в деталях

Три метрики, которые входят в Core Web Vitals.

LCP — Largest Contentful Paint. Время до отрисовки крупнейшего контентного элемента на странице (обычно — главного изображения или большого блока текста). Целевые значения Google: «хорошо» — меньше 2.5 секунды, «нужно улучшить» — от 2.5 до 4 секунд, «плохо» — больше 4 секунд. Что улучшает LCP: оптимизация изображений (WebP, AVIF, правильные размеры), preload главного ресурса, серверная отрисовка вместо клиентской, CDN для статических ресурсов.

INP — Interaction to Next Paint. Заменил FID в 2024 году. Меряет время от первого взаимодействия пользователя (клик, тап на ссылку или кнопку) до следующей отрисовки страницы. Показывает, насколько отзывчив сайт на действия пользователя. Целевые значения: «хорошо» — меньше 200 миллисекунд, «нужно улучшить» — 200-500, «плохо» — больше 500. Что улучшает INP: уменьшение общей JS-нагрузки, разбиение длинных задач на короткие, ленивое выполнение тяжёлых скриптов после основной загрузки.

CLS — Cumulative Layout Shift. Накопительный сдвиг вёрстки. Если у вас изображения «прыгают» при загрузке (из-за того, что у них не указаны размеры), или контент сверху страницы сдвигается, когда загружается реклама — это плохой CLS. Целевые значения: «хорошо» — меньше 0.1, «нужно улучшить» — 0.1-0.25, «плохо» — больше 0.25. Что улучшает CLS: явные размеры (width и height) для всех <img>, резервирование места под рекламные блоки заранее, отказ от динамических вставок контента сверху уже отрендеренной страницы.

Как Яндекс относится к скорости

Официально Яндекс не публиковал ранжирующий фактор «скорость сайта» по аналогии с Google Page Experience. В документации Вебмастера упоминается, что скорость важна, но без конкретных метрик и порогов.

Но скорость сайта в Яндексе влияет на ранжирование двумя путями.

Через поведенческие сигналы. Медленный сайт → пользователь не дождался загрузки → ушёл обратно в SERP → высокий отказ → плохие поведенческие → понижение в ранжировании. Этот путь работает прямо через ранжирование. Поведенческие — главный сигнал Яндекса, и скорость напрямую их формирует.

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

Где смотреть CWV

Замерять CWV можно двумя способами, и оба важны.

Лабораторные данные — синтетические замеры в изолированной среде. Lighthouse в Chrome DevTools — встроенный инструмент Chrome для синтетического замера. PageSpeed Insights — онлайн-инструмент Google, основанный на Lighthouse плюс полевые данные. Они полезны для отладки, но не показывают «реальную» картину поведения у ваших пользователей.

Полевые данные — замеры с реальных пользователей. CrUX Dashboard для Google — агрегированные данные с пользователей Chrome по всему миру. Метрика → Содержание → Скорость загрузки — данные пользователей именно вашего сайта. Это уникальный источник для русского сайта, недоступный в Google-инструментах. Web Vitals JS — собственный сбор через JS-библиотеку с отправкой в свою аналитику для тонкой настройки.

Полевые данные важнее лабораторных. Если Lighthouse показывает «99 баллов», а реальные пользователи на 75-м перцентиле получают LCP в 5 секунд — у вас проблема, даже если синтетика выглядит красиво.

Что улучшать в первую очередь

Для типичного сайта в Рунете порядок приоритетов оптимизации выглядит так.

Изображения — главная точка приложения усилий: на большинстве контентных сайтов они дают основной вес страницы. Что делать: сжатие, современные форматы (WebP и AVIF вместо JPEG/PNG), responsive через srcset для разных размеров экрана, ленивая загрузка через атрибут loading="lazy" для всех картинок, кроме той, что является LCP-кандидатом (её нужно грузить немедленно).

Серверная отрисовка или статическая генерация. Клиентская отрисовка через тяжёлые JS-фреймворки (React, Vue, Angular без SSR) — это медленно для пользователя и хуже для бота. SSR (Next.js, Nuxt, SvelteKit) или SSG (Astro, Hugo, Eleventy) — заметно быстрее.

Шрифты. Используйте font-display: swap (показать системный шрифт пока грузится кастомный), preload для критичных весов шрифтов, минимум весов (не подключайте все варианты, только нужные), кириллические подмножества вместо полных шрифтов.

JavaScript. Лениво грузить тяжёлое — аналитика, чаты, виджеты, баннеры — после основной загрузки. Не включать тонны JS в первый рендер.

CDN. Особенно для сайтов с пользователями в разных регионах России — Москва, Дальний Восток, Урал. Без CDN дальние регионы получают +200-500 мс к каждому запросу.

Для мобильной аудитории оптимизация важнее десктопной. Мобильные пользователи в среднем заметно хуже по LCP, чем десктопные. В Рунете 2026 мобильная аудитория — это большинство трафика для большинства проектов, и оптимизация мобильного существенно приоритетнее. Touch-устройства чувствительнее к CLS — каждый сдвиг вёрстки воспринимается раздражающе, потому что палец промахивается по двигающимся кнопкам.

Турбо-страницы как обходной путь

Турбо-страницы Яндекса — это альтернатива глубокой оптимизации скорости вашего сайта. Вместо того чтобы переделывать фронтенд, вы публикуете «теневую» версию страницы на CDN Яндекса, которая открывается мгновенно из выдачи.

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

Ограничения Турбо. Упрощённая вёрстка — часть интерактивности и стилей теряется на Турбо-версии. Метрика на Турбо работает в ограниченном режиме (Карта кликов и Вебвизор работают слабее). В современных версиях с 2024 года Турбо менее активно используется самим Яндексом — в SERP их меньше показывают, что снижает эффективность.

Что не делать

Не гонитесь за «99 баллов в Lighthouse» вместо реальной скорости у пользователей. Lighthouse — это синтетика на эталонном устройстве с эталонной сетью. Полевые данные с настоящих устройств важнее.

Не делайте Core Web Vitals приоритетом для Yandex-only проекта. Они важны через поведенческие, а не как прямой фактор ранжирования в Яндексе.

Не включайте все картинки в lazy-загрузку. Главное изображение страницы (LCP-кандидат) должно загружаться немедленно. Lazy на него только ухудшает LCP.

Не игнорируйте INP. Это новая метрика 2024 года, и многие сайты, которые были «зелёные» по старой FID, теперь «красные» по INP — потому что INP меряет более жёстко.

Не делайте сайт полностью на клиентском JS без SSR. Серверная отрисовка дешевле в работе и быстрее для пользователя.

Короче говоря

Core Web Vitals — официальный ранжирующий фактор у Google, у Яндекса нет. В Яндексе скорость влияет через поведенческие сигналы и краулинговый бюджет. Метрика → Скорость загрузки — лучший источник полевых данных для Рунета, недоступный в Google-инструментах. Изображения — главная точка оптимизации, на них приходится 60-80% веса страницы. SSR/SSG предпочтительнее CSR. Турбо-страницы — обходной путь для медленных сайтов в Яндексе, но с ограничениями. Мобильные пользователи важнее десктопных в Рунете 2026.

Дальше — Мобильная адаптация.