Core Web Vitals 2026: чек-лист, который мы прогоняем на каждом проекте

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

Что такое Core Web Vitals и зачем они бизнесу

Core Web Vitals — это подмножество более широкого набора сигналов page experience, которые Google отбирает по одному принципу: они отражают то, что пользователь реально чувствует на странице. Не абстрактный «балл скорости», а конкретные моменты боли — долгое ожидание контента, задержка после клика, скачок вёрстки под пальцем. Для бизнеса это прямо конвертируется в процент отказов и недополученные заявки, поэтому мы относимся к этим метрикам не как к галочке для SEO, а как к части юзабилити.

Три метрики простыми словами

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

Почему Google сделал их частью ранжирования

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

Ориентиры, на которые мы равняемся

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

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

Как мы вытягиваем LCP

LCP почти всегда упирается в одно из трёх: медленный ответ сервера, тяжёлое главное изображение или ресурсы, блокирующие отрисовку. Начинаем со времени до первого байта: дешёвый хостинг и отсутствие кеширования дают 600–900 мс ещё до того, как браузер что-то нарисовал. Дальше беремся за главное изображение — сжимаем, отдаём в современном формате, задаём размеры и подгружаем его с приоритетом, а всё, что ниже сгиба, наоборот откладываем. Отдельно выносим рендер-блокирующие стили и шрифты. На одном из наших магазинов такая связка — кеш, сжатие картинок и preload баннера — сняла LCP с 4,1 до 2,2 секунды без переписывания шаблона. Эти работы мы ведём в рамках оптимизации скорости.

Как мы держим INP в норме

В марте 2024 года INP официально заменил старую метрику FID — и это не косметика, а более серьёзная планка. FID измерял только задержку первого взаимодействия, а INP смотрит на отзывчивость на протяжении всего визита: каждый клик, тап и ввод. Главный виновник плохого INP — тяжёлый JavaScript, который надолго блокирует основной поток. Мы ищем «длинные задачи», разбиваем их на части, убираем лишние сторонние скрипты (чаты, виджеты, аналитику, тянущую сотни килобайт) и откладываем то, без чего первый экран обходится. Правильно собранный фронтенд тут решает больше любого плагина — поэтому код мы пишем с прицелом на это с самого начала, а не латаем потом, как описано в материале о техническом качестве кода.

Откуда берётся сдвиг макета

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

Лабораторные и полевые данные — почему они расходятся

Чаще всего путаница в том, что PageSpeed Insights показывает два блока. Сверху — полевые данные (реальные визиты, тот самый 75-й перцентиль за 28 дней), по которым Google и судит страницу. Снизу — лабораторный тест Lighthouse: один синтетический прогон на эмулированном устройстве. Они почти никогда не совпадают, и это нормально: лаборатория полезна для диагностики «что именно тормозит», а решение о состоянии страницы принимают полевые данные. Динамику по сайту удобно видеть в отчёте Core Web Vitals в Search Console — как его читать вместе с аналитикой, мы разбирали в материале об отчётах GA4 и Search Console. Если новой страницы ещё нет в поле, ориентируйтесь на лабораторию, но не принимайте её за приговор.

Чем мы измеряем

Для диагностики берём PageSpeed Insights, который показывает полевые и лабораторные данные рядом, и панель Performance в Chrome DevTools, чтобы видеть, какие именно скрипты блокируют основной поток. Для динамики по сайту — отчёт Core Web Vitals в Search Console: он группирует страницы по типам и сразу показывает, что сползло в «плохо». А для постоянного контроля на боевом трафике подключаем сбор реальных метрик через библиотеку web-vitals — так мы ловим просадку ещё до того, как её увидит Google, и не ждём, пока она осядет в поле за 28 дней.

Ошибки, которые мы видим чаще всего

На аудитах одни и те же промахи повторяются из проекта в проект. Вот те, что стоят дороже всего:

1. Оптимизируют лабораторный балл вместо полевого: гоняют Lighthouse до 100, пока реальные пользователи на мобильном видят «плохо».
2. Чинят главную, а деньги приносят карточки товара и категории — и именно они остаются медленными.
3. Вешают на сайт пять сторонних скриптов и удивляются плохому INP, хотя половина из них вообще не нужна.
4. Забывают про мобильные: меряют на десктопе с кабельным интернетом, а Google судит по 4G на среднем телефоне.
5. Гонятся за идеальными цифрами там, где метрика уже «хорошая», вместо того чтобы вытащить страницы из зоны «плохо».
6. Делают разовую оптимизацию перед запуском и больше не мониторят — за полгода новые баннеры и плагины тихо всё портят.

Как мы встраиваем Core Web Vitals в работу над сайтом

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

Вывод

Скорость — не самоцель, а способ не терять пользователей и заявки на технических мелочах.

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

Михаил Уманенко

Project Manager · сооснователь heleum.studio

Соучредитель и Project Manager heleum.studio. 8+ лет управляет SEO- и веб-проектами: отвечает за стратегию, сроки и результат, лично ведет ключевых клиентов.