Core Web Vitals и INP в 2026: что всё ещё важно

Core Web Vitals пережили четыре года прогнозов, что Google вот-вот от них откажется. В 2026 они всё ещё здесь, всё ещё измеряются на реальных пользователях и всё ещё стоят внимания. Скажу прямо, что они меняют, чего не меняют и куда стоит направить усилия.

Что такое Core Web Vitals в 2026

Core Web Vitals — это три метрики, которыми Google описывает опыт загрузки и использования страницы:

• LCP (Largest Contentful Paint) — время до отрисовки основного контента. "Хорошо" — меньше 2,5 секунды.
• INP (Interaction to Next Paint) — насколько быстро страница отвечает на нажатия, клики и клавиши в течение всего визита. "Хорошо" — меньше 200 миллисекунд.
• CLS (Cumulative Layout Shift) — насколько макет неожиданно прыгает. "Хорошо" — меньше 0,1.

Главный сдвиг произошёл в марте 2024 года, когда INP заменил FID (First Input Delay). FID измерял лишь задержку до обработки первого взаимодействия. INP же учитывает полную задержку взаимодействий в течение сессии и сообщает о худших из них. Это гораздо сложнее подделать и намного ближе к тому, как страница ощущается на самом деле.

Все три порога оцениваются на 75-м перцентиле реальных пользователей и на мобильных, поскольку Google оценивает именно мобильный опыт. Если трое из четырёх посетителей получают "хорошо", вы проходите.

Честное влияние на ранжирование

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

Что это значит на практике:

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

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

Как измерять правильно

Самая частая ошибка, которую я вижу, — оптимизация лабораторных оценок при игнорировании полевых данных. Google ранжирует по полевым данным — реальным пользователям Chrome, агрегированным в Chrome UX Report (CrUX). Лабораторные инструменты воспроизводят проблемы, но не определяют ранжирование.

Используйте такой набор:

1. Search Console → отчёт Core Web Vitals. Ваша отправная точка. Он группирует реальные URL в "good", "needs improvement" и "poor" по данным CrUX, так что вы видите проблемы в масштабе.
2. PageSpeed Insights. Показывает и полевые данные (сверху), и лабораторный прогон (снизу) для одного URL. Всегда читайте сначала полевую часть.
3. Chrome DevTools + панель Performance. Для воспроизведения и диагностики конкретного медленного взаимодействия или сдвига макета.
4. JavaScript-библиотека web-vitals или мониторинг реальных пользователей (RUM). Самый надёжный подход в долгой перспективе: собирайте LCP, INP и CLS со своих пользователей и сегментируйте по типу страницы, устройству и стране.

Практическое правило: если CrUX говорит, что шаблон "poor", а лабораторная оценка зелёная, доверяйте CrUX и копайте в сегменты устройств и сетей. Реальные пользователи на среднебюджетных Android-телефонах говорят правду.

Типичные исправления, которые дают результат

Большинству сайтов не нужна экзотическая инженерия. Нужен короткий список дисциплинированных исправлений.

Улучшение LCP

• Отдавайте LCP-изображение в современном формате (AVIF или WebP), правильного размера, с fetchpriority="high".
• Уберите блокирующие рендер CSS и JavaScript из критического пути; встраивайте только CSS, нужный для первого экрана.
• Используйте CDN и разумное кеширование, чтобы сервер отвечал быстро (следите за TTFB).
• Делайте preload LCP-ресурса и хостите критические шрифты локально с font-display: swap.

Улучшение INP

• Разбивайте длинные JavaScript-задачи. Всё, что блокирует главный поток дольше 50 мс, вредит отзывчивости. Делите работу и возвращайте управление браузеру.
• Откладывайте или лениво загружайте сторонние скрипты — теги-менеджеры, чат-виджеты и аналитика часто виноваты.
• Выносите тяжёлые вычисления из главного потока в web workers, где это уместно.
• Избегайте больших синхронных обработчиков событий; показывайте визуальный отклик сразу, а дорогую работу откладывайте.

Улучшение CLS

• Задавайте явные width и height (или aspect-ratio) для изображений, видео и встраиваний.
• Резервируйте место под рекламу, баннеры и контент, добавляемый динамически.
• Делайте preload шрифтов, чтобы избежать поздних замен, которые переверстывают текст.
• Никогда не вставляйте контент над существующим, если это не инициировал пользователь.

Реалистичный план на 30 дней

Вы не исправите Core Web Vitals по всему сайту за ночь. Приоритизируйте по трафику и доходу.

1. Неделя 1 — Диагностика. Выгрузите отчёт Search Console. Ранжируйте не проходящие группы URL по трафику. Выберите два-три шаблона (а не отдельные страницы), ответственные за большинство плохого опыта.
2. Неделя 2 — Исправьте главный шаблон. Обычно это LCP и INP на денежных страницах: макетах товаров, категорий или статей.
3. Неделя 3 — Исправьте второй шаблон и займитесь проблемами CLS, которые часто являются быстрыми победами.
4. Неделя 4 — Проверьте по полевым данным. CrUX обновляется в 28-дневном скользящем окне, поэтому улучшения проявляются за недели. Убедитесь, что тренд движется, и переходите к следующему шаблону.

Настройте RUM-дашборд, чтобы не лететь вслепую между обновлениями CrUX.

Типичные ошибки, которых стоит избегать

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

• Погоня за оценкой 100 в Lighthouse. Идеальный лабораторный балл не гарантирует прохождение на реальных пользователях. Оптимизируйте полевые метрики, а не тщеславный показатель.
• Оптимизация главной страницы, пока денежные шаблоны страдают. Главная часто самая быстрая, а вот страницы товаров или статей приносят трафик и конверсии. Идите туда, где боль.
• Игнорирование разницы между устройствами. Сайт может проходить на десктопе и проваливаться на мобильных. Поскольку Google оценивает мобильный опыт, именно он решает.
• Разовые исправления без мониторинга. Новый сторонний скрипт, тяжёлое изображение или обновление CMS легко откатывают ваш прогресс. Без RUM вы узнаете об этом слишком поздно.
• Восприятие CLS как мелочи. Неожиданные сдвиги разрушают доверие и портят конверсию даже тогда, когда скорость кажется приемлемой.

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

Главный вывод

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