Core Web Vitals: скрытая причина, почему ваш сайт не растёт в позициях

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

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

Три метрики и что они на самом деле измеряют

Набор называется основными веб-показателями и состоит из трёх независимых величин. Они не заменяют друг друга: сайт может мгновенно показывать содержимое и при этом быть непригодным для работы.

LCP — время отрисовки основного содержимого. Момент, когда в видимой области появляется самый крупный элемент: главное изображение, заголовок, блок текста. Это ответ на вопрос «когда человек увидел то, за чем пришёл». Зелёная зона — до 2,5 секунды, жёлтая — до 4, дальше красная.

INP — отзывчивость на действия. Задержка между нажатием и видимой реакцией страницы. Метрика пришла на смену более грубой FID и учитывает не первое взаимодействие, а худшие из всех за визит. Зелёная зона — до 200 миллисекунд, жёлтая — до 500.

CLS — смещение макета. Насколько содержимое прыгает во время загрузки: подгрузилась картинка без заданных размеров, вылез баннер, подменился шрифт. Считается в условных единицах, зелёная зона — до 0,1, жёлтая — до 0,25.

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

Как это связано с позициями

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

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

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

Тему разбирал отдельно: «Core Web Vitals 2026: почему дизайнерский сайт за 500 000 ₽ не попадает в ТОП-10».

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

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

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

Помогу с продвижением: продвижение бизнеса в Яндексе — вывожу сайты в топ Яндекса белыми методами.

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

Полевые данные — накопленная статистика реальных визитов за последние недели. Именно они используются при оценке сайта. Обновляются с задержкой, поэтому эффект от правок виден не сразу.

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

Источник данных	Что показывает	Когда использовать	Чему не верить
Раздел скорости в Яндекс Вебмастере	Полевые показатели по вашей аудитории, разбивка по типам страниц	Оценка реального состояния и приоритизация	Мгновенной реакции на правки — данные накапливаются неделями
Отчёт основных показателей в консоли Google	Полевые данные с группировкой похожих адресов	Поиск проблемных групп страниц, а не отдельных адресов	Малым выборкам — редкие страницы в отчёт не попадают
Лабораторный тест страницы	Разбор одного запуска: что грузится, сколько весит, что блокирует	Отладка конкретной причины	Общему баллу и его изменению между запусками
Панель разработчика в браузере	Раскладка загрузки по ресурсам, длинные задачи скриптов	Поиск источника задержек отклика и смещений	Показаниям на мощном компьютере с быстрым каналом

Почему LCP в красной зоне

Причины укладываются в короткий список, и порядок в нём соответствует частоте.

• Тяжёлое изображение в первом экране. Баннер на полтора мегабайта в устаревшем формате, отдаваемый в исходном разрешении на телефон. Самая частая причина и самая дешёвая в исправлении.
• Изображение первого экрана с отложенной загрузкой. Атрибут ленивой загрузки, поставленный на все картинки подряд, откладывает и главную — та, что должна появиться первой, ждёт своей очереди.
• Медленный ответ сервера. Если первый байт приходит через полторы секунды, дальше можно ничего не оптимизировать. Причина — отсутствие кэширования, тяжёлые запросы к базе, дешёвый общий хостинг.
• Блокирующие стили и шрифты. Браузер не рисует ничего, пока не загрузит все подключённые стилевые файлы. Пять внешних файлов стилей в шапке — гарантированная задержка.
• Веб-шрифты без запасного варианта. Текст не отображается, пока не приедет шрифт. Если это и есть крупнейший элемент, метрика ждёт вместе с ним.
• Сторонние скрипты в шапке. Чаты, счётчики, виджеты отзывов, карты — каждый добавляет запрос к чужому серверу, скорость которого вам неподконтрольна.

Почему INP в красной зоне

Отзывчивость страдает не от объёма загруженного, а от того, чем занят браузер. Пока он выполняет длинную задачу, он не реагирует ни на что.

Основные источники: избыточный код скриптов, загружаемый целиком вместо нужной части; обработчики событий, которые запускают тяжёлые вычисления при каждом нажатии; сторонние виджеты, инициализирующиеся при первом взаимодействии; конструкторы страниц, тянущие библиотеки под каждый блок; анимации, пересчитывающие размеры элементов.

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

Смежный материал по теме — «Почему сайт не растёт в Яндексе: 12 технических причин, которые тормозят позиции».

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

Почему CLS в красной зоне

Смещения макета — самая простая для исправления группа и самая раздражающая для посетителя. Причин четыре.

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

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

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

Порядок работ: что делать и в какой очерёдности

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

1. Снять исходные значения. Полевые данные из Вебмастера и консоли, отдельно по мобильным и настольным, отдельно по типам страниц: главная, категория, карточка, статья. Записать дату.
2. Выбрать одну группу страниц. Ту, что даёт основной трафик. Оптимизировать сайт целиком сразу — верный способ не понять, что сработало.
3. Изображения. Современные форматы, размеры под контейнер, размеры в разметке, отложенная загрузка для всего, кроме первого экрана.
4. Ответ сервера. Кэширование страниц, сжатие, актуальная версия языка программирования, проверка тяжёлых запросов. Без этого дальнейшие шаги дают немного.
5. Стили и шрифты. Собрать стили первого экрана и отдать их сразу, остальное отложить. Сократить набор начертаний шрифта до необходимых.
6. Скрипты. Убрать неиспользуемое, отложить всё, что не нужно для отрисовки, вынести сторонние виджеты за пределы первого экрана.
7. Смещения. Размеры изображений, резерв под подгружаемые блоки, поведение шрифта.
8. Проверить и подождать. Лабораторный тест сразу, полевые данные — через три-четыре недели. Только после этого браться за следующую группу страниц.

Каждый шаг проверяется отдельно: правка, тест, фиксация в журнале. Если сайт после правки сломался, вы знаете, какая именно правка виновата, и откат занимает минуты.

Чего делать не стоит

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

• Включать все переключатели плагина оптимизации разом. Объединение и сжатие скриптов, отложенная загрузка стилей, удаление неиспользуемого — каждый пункт способен сломать вёрстку или форму. Включать по одному с проверкой.
• Гнаться за сотней в лабораторном балле. Разница между 75 и 95 в балле часто не даёт разницы в полевых данных, а последние проценты покупаются отказом от функциональности.
• Убирать формы, чат и аналитику ради скорости. Сайт без формы быстрый и бесполезный. Правильный путь — отложенная загрузка, а не удаление.
• Ставить отложенную загрузку на изображение первого экрана. Прямо ухудшает основную метрику, а выглядит как оптимизация.
• Оценивать результат через три дня. Полевые данные накапливаются неделями. Ранние выводы приводят к откату правильных правок.
• Оптимизировать настольную версию. Оценка идёт в первую очередь по мобильной, и именно там находится вся проблема.

Как ставить задачу разработчику

Самая распространённая формулировка — «сделай, чтобы сайт быстро грузился». Она не выполнима и заканчивается спором о том, у кого что открывается. Задача ставится по-другому.

Если нужны детали, смотрите «Сайт есть, реклама крутится, а денег нет: настоящая причина, почему бизнес умирает в digital».

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

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

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

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

Частые вопросы

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

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

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

Что делать, если сайт на конструкторе и доступа к коду нет? Работают три вещи: облегчить изображения, сократить число блоков и сторонних виджетов на странице, отказаться от анимаций и слайдеров в первом экране. Остальное упирается в платформу.

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

Влияют ли эти метрики на мобильную выдачу сильнее? Да, и по двум причинам: оценка ведётся преимущественно по мобильным визитам, и именно на телефонах с обычным каналом проблемы проявляются в полную силу.

Коротко

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

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