Что Google на самом деле измеряет
Core Web Vitals - это три метрики, которые Google выделил из десятков показателей скорости и удобства как наиболее близкие к тому, что чувствует живой человек. До 2020 года SEO-специалисты спорили, какая метрика важнее - время загрузки, время до интерактивности, индекс скорости. Google закрыл этот спор, выбрав три конкретных числа и объявив, что именно по ним будет оценивать страницы.
Первая метрика - Largest Contentful Paint (LCP): сколько времени проходит до появления на экране самого крупного видимого блока, обычно это картинка, видео или заголовок. Вторая - Interaction to Next Paint (INP): сколько страница обрабатывает клик, тап или нажатие клавиши, прежде чем на экране произойдет видимый отклик. Третья - Cumulative Layout Shift (CLS): насколько сильно элементы страницы «прыгают» во время загрузки, пока не подгрузились шрифты, картинки или реклама.
В марте 2024 года Google заменил метрику First Input Delay (FID) на INP. Разница принципиальная: FID измерял только задержку до начала обработки первого клика, а INP оценивает отклик на любое взаимодействие за все время жизни страницы, включая долгие клики в конце сессии - на каталоге с фильтрами или на калькуляторе это меняет картину сильнее, чем кажется.
LCP: что успевает загрузиться первым
LCP чаще всего ломают четыре вещи: тяжелая и несжатая картинка в шапке или на первом экране, шрифты, которые блокируют отрисовку текста, рендер-блокирующие CSS и JavaScript в head страницы и медленный ответ сервера - именно он определяет, когда браузер вообще начинает получать содержимое.
Отсюда типичная ошибка: чинить LCP оптимизацией картинок, когда сервер отвечает секунду и больше. Это два разных слоя ответственности, и путать их - значит чинить не ту половину проблемы.
- сжать и перевести в современный формат (WebP, AVIF) изображение, которое становится LCP-элементом
- подключить preload для главного изображения и ключевого шрифта
- вынести некритичный CSS и JavaScript из head или загрузить их асинхронно
- включить font-display: swap, чтобы текст не ждал загрузки шрифта
- использовать CDN для статики, если аудитория географически разбросана
Ответ сервера входит в LCP как первая ступень, но это уже не вопрос верстки, а вопрос инфраструктуры - что проверить и как измерить его отдельно, я разбирала в статье про хостинг и SEO .
INP: почему это самая сложная метрика
INP - самая частая причина, по которой сайт не проходит Core Web Vitals: LCP и CLS обычно правятся точечно, а плохой INP означает, что на странице слишком много JavaScript выполняется одновременно с действиями пользователя.
Главный источник долгого отклика - тяжелые сторонние скрипты: виджеты чата, счетчики аналитики, рекламные теги, которые занимают основной поток браузера в момент клика. На карточках товаров и в каталогах с фильтрами есть вторая причина: сами фильтры и сортировки написаны так, что каждое нажатие пересчитывает и перерисовывает весь список товаров вместо одного блока.
Сложность еще и в том, что INP нельзя измерить одним симулированным запуском: метрика считается по худшему из зафиксированных взаимодействий за визит, а не по среднему. Страница может выглядеть быстрой в Lighthouse и при этом проваливать эту метрику у реальных посетителей, если проблема проявляется только на конкретном действии - например, на открытии фильтра уже после того, как догрузились вся реклама и аналитика.
- разбить длинные задачи JavaScript на части короче 50 миллисекунд
- отложить загрузку виджетов чата и второстепенной аналитики до первого действия пользователя
- убрать лишние сторонние скрипты - каждый добавляет свой поток задач
- проверить, не пересчитывает ли фильтр каталога весь список при каждом клике
Для каталога с сотнями фильтров и товаров это не абстрактная метрика, а реальная причина, по которой посетитель уходит, не дождавшись отклика - в SEO-продвижении интернет-магазина эту работу я веду вместе с разработчиком, а не отдельно от него.
CLS: откуда берутся скачки верстки
CLS - самая дешевая в исправлении метрика, если знать, где искать: почти всегда все сводится к одному, браузер не знает заранее, сколько места займет элемент, и сдвигает уже отрисованный контент, когда узнает это позже.
Классические источники сдвига - картинки и видео без атрибутов width и height, реклама и баннеры, которые подгружаются позже основного контента и не имеют зарезервированного места, шрифты, при подключении которых меняется межстрочный интервал, и баннер cookie-согласия, который появляется поверх контента и сдвигает его при закрытии.
- указать width и height у всех изображений и видео на странице
- зарезервировать место под баннеры, рекламу и виджеты заранее
- подключить font-display: swap и заранее задать похожие метрики шрифта
- использовать transform вместо изменения top и left в анимациях
Дешевле всего такие сдвиги устранять не постфактум, а на этапе верстки, когда место под баннеры и виджеты закладывается заранее - это часть SEO-проектирования сайта , а не доработка уже готового сайта.
Как проверить свои показатели
Есть два разных источника данных, и путать их - частая ошибка. Лабораторные данные (Lighthouse, вкладка «Диагностика» в PageSpeed Insights) получены за один симулированный заход и показывают потенциал страницы в контролируемых условиях. Полевые данные (Chrome User Experience Report, CrUX) собраны у реальных посетителей на Chrome за последние 28 дней и показывают, что происходит на самом деле.
Google Search Console использует именно полевые данные: отчет «Основные интернет-показатели» группирует страницы сайта по шаблонам URL и показывает, сколько из них проходят, сколько требуют доработки и сколько проваливают каждую метрику. Если у сайта недостаточно трафика для накопления полевых данных, PageSpeed Insights покажет только лабораторный прогноз - это нормально для новых и небольших сайтов, но означает, что доверять нужно именно лабораторным цифрам, а не ждать полевых.
Разовая проверка PageSpeed Insights не заменяет полную диагностику - список из 26 проверок, которые стоит сделать самому, я собрала в чек-листе SEO-аудита .
Какие значения считаются хорошими
Google делит каждую метрику на три зоны, и цель - попасть в зеленую сразу по всем трем, а не по одной. Страница может отлично загружаться (хороший LCP) и при этом дергаться от рекламы (плохой CLS) - для отчета в Search Console это все равно провал по Core Web Vitals, потому что оценка складывается по 75-му процентилю посетителей и по худшей из трех метрик.
Что с этим в Яндексе
У Яндекса нет официально объявленного аналога Core Web Vitals, и это не значит, что скорость не имеет значения - значит, что нет единого публичного порога, к которому можно апеллировать. Яндекс Вебмастер показывает собственный отчет о скорости сайта на основе данных Яндекс Метрики, частично пересекающийся с теми же LCP и CLS, но без объявленного веса в ранжировании.
На практике для Яндекса скорость работает через поведенческие факторы: если страница долго грузится или прыгает при загрузке, часть посетителей возвращается обратно в выдачу, не дождавшись ответа на запрос, а это уже прямой сигнал качества, который Яндекс использует давно и открыто. Отчет о скорости сайта в Вебмастере построен на данных реальных визитов из Яндекс Метрики, а не на разовом тестовом заходе - в этом он ближе к полевым данным Google, чем к лабораторным, хотя и не называется Core Web Vitals.
Поэтому оптимизировать эти метрики имеет смысл для обеих систем сразу - методы совпадания, различается только то, как каждый поисковик превращает скорость в позиции: Google - через официальный, пусть и некрупный, ранжирующий сигнал, Яндекс - через поведение живых посетителей на странице.
Порядок исправления, если проваливаются все три
Когда все три метрики красные, есть соблазн чинить их параллельно, но по опыту это только путает картину: правки накладываются друг на друга, и непонятно, какая из них сработала. Порядок, который дает предсказуемый результат: сначала CLS, потом LCP, INP - последним.
Причина именно в такой последовательности простая: CLS обычно правится в CSS и разметке, не затрагивая логику страницы, поэтому регрессии от таких правок редки. LCP требует тронуть изображения, шрифты и порядок загрузки - риск выше, но изменения все еще локальны. INP же часто упирается в сторонние скрипты и бизнес-логику интерфейса, а иногда требует пересмотра архитектуры конкретного узла - здесь риск что-то сломать самый высокий, и разумно подходить к этому, только разобравшись с первыми двумя метриками.
Если непонятно, какая из трех метрик проваливается и почему, дальше не гадать, а смотреть отчеты и логи вместе - для этого нужен SEO-аудит сайта .
Пример из практики
На одном интернет-магазине автотоваров LCP на карточке товара доходил до 4,8 секунды, а INP - до 640 миллисекунд. Причина LCP была в баннере акции: несжатое изображение весом 3,2 мегабайта загружалось раньше основной фотографии товара. Причина INP - в скрипте сравнения товаров, который при каждом клике пересчитывал состояние для всех карточек на странице, а не только для выбранной.
После сжатия баннера, добавления preload для фото товара и переписывания логики сравнения на точечное обновление одной карточки LCP снизился до 2,1 секунды, а INP - до 180 миллисекунд. Обе метрики попали в зеленую зону Search Console в течение месяца, а заодно на 12% снизилась доля отказов на карточках товаров.
Похожую техническую проверку скорости и стабильности верстки каталога я вела в кейсе SEO интернет-магазина сантехники - там тоже начинали с технической доступности и скорости страниц и только потом переходили к содержанию.
Что в итоге
Core Web Vitals - это не разовая галочка, а три метрики, которые нужно держать зелеными постоянно: новый баннер, обновление CMS или добавленный виджет чата способны обрушить любую из них за один релиз. Проверяйте отчет в Search Console не реже раза в месяц, а после заметных изменений на сайте - сразу.
Если решаете, с чего начать: измерьте LCP, INP и CLS по полевым данным сегодня, а не после того, как трафик начнет падать. Это тридцать минут работы, которые показывают, стоит ли вообще открывать более глубокую техническую диагностику.