Core Web Vitals 2026: почему INP ухудшается и что делать с сайтом

В августе 2026 года все три метрики Core Web Vitals проходили лишь 55,6 % сайтов в мире. Показатель INP, отвечающий за скорость реакции на действия пользователя, снижается уже несколько месяцев подряд: с 87,2 % сайтов с «хорошим» INP в марте до 85,3 % в августе. В релизе Chrome UX Report Google признаёт, что окончательной причины этого падения у него пока нет.

Для владельца бизнеса это не повод паниковать. Но это хороший повод проверить, как ведёт себя ваш сайт на телефоне, и исправить то, что действительно влияет на посетителей.

55,6 %

сайтов проходят все три метрики

август 2026

85,3 %

сайтов с «хорошим» INP

в марте было 87,2 %

48 %

мобильных сайтов проходят Core Web Vitals

в 2024 году — 44 %

Три метрики и пороги, которые стоит запомнить

Core Web Vitals — три измерения пользовательского опыта. Google оценивает их по 75-му перцентилю реальных визитов, отдельно для мобильных и десктопов. Страница «проходит», если все три показателя в зелёной зоне.

Метрика	Что измеряет	«Хорошо»
LCP (Largest Contentful Paint)	Как быстро появляется главный элемент страницы	до 2,5 с
INP (Interaction to Next Paint)	Как быстро сайт реагирует на клик, касание, ввод	до 200 мс
CLS (Cumulative Layout Shift)	Не «прыгает» ли вёрстка при загрузке	до 0,1

Google заявляет, что определения и пороги будут меняться не чаще раза в год и с предупреждением. Это стабильная цель, а не движущаяся мишень.

Что показывают данные

Есть два независимых источника, и они описывают одну и ту же картину с разных сторон.

Chrome UX Report (CrUX), август 2026. Среди более чем 18 миллионов сайтов «хороший» LCP у 68,1 %, CLS — у 81,5 %, INP — у 85,3 %. Все три вместе проходят 55,6 %. INP — единственная метрика, которая заметно снижается с начала года.

Web Almanac 2025 от HTTP Archive. Доля прохождения на мобильных — 48 % (в 2024-м было 44 %), на десктопе — 56 %. Самое слабое звено на мобильных — LCP:

2025 2024 (где есть данные)

• LCP 62 %
• INP 77 %
  74 %
• CLS 81 %
• Все три метрики вместе 48 %
  44 %

Источник: HTTP Archive Web Almanac 2025, раздел Performance

Есть и практически важная деталь: главные страницы хуже внутренних — 45 % против 56 % на мобильных. А на главную нередко попадают именно с рекламы и по поиску названия компании.

Источники не противоречат друг другу: Almanac описывает 2025 год, а CrUX даёт текущий месячный срез. Из-за разных выборок и методики числа отличаются, сравнивать их «цифра в цифру» не стоит.

Влияет ли это на позиции в Google

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

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

LCP: почти всегда это картинка

По данным Web Almanac, на мобильных страницах самый крупный элемент — изображение в 76 % случаев (на десктопе — 85 %). Формат этих картинок — в основном старые JPG и PNG, а современного WebP немного:

• JPG 57 %
• PNG 26 %
• WebP 11 %

Источник: HTTP Archive Web Almanac 2025

Отсюда практический порядок действий, совпадающий с рекомендациями web.dev:

1. Не загружайте главное изображение лениво. Атрибут loading="lazy" на первом экране откладывает запрос и ухудшает LCP.
2. Дайте браузеру приоритет. Для одного-двух главных изображений добавьте fetchpriority="high". Если пометить так десять картинок, эффекта не будет.
3. Сделайте картинку видимой в HTML. Если её подставляет JavaScript или она только в CSS, браузер узнаёт о ней поздно.
4. Сжимайте и подбирайте размер. WebP или AVIF в том размере, который реально показывается, а не оригинал с камеры на 5000 пикселей.
5. Посмотрите, из чего состоит LCP. От этого зависит, куда вкладывать усилия.

• Ответ сервера (TTFB) ≈ 40 %
• Загрузка ресурса ≈ 40 %
• Задержка до начала загрузки до 10 %
• Задержка перед отрисовкой до 10 %

Источник: web.dev, Optimize Largest Contentful Paint

INP: почему он падает и что с этим делать

INP состоит из трёх частей, и каждую можно ускорять отдельно:

1. 1
   Задержка ввода
   от действия пользователя до начала обработки
   ↓ →
2. 2
   Обработка
   выполнение обработчиков событий
   ↓ →
3. 3
   Отрисовка
   появление следующего кадра с результатом

Источник: web.dev, Optimize Interaction to Next Paint

Типичные причины плохого INP по web.dev:

• длинные задачи в главном потоке, чаще всего из-за разбора и выполнения скриптов при загрузке;
• «тяжёлые» обработчики событий, которые делают больше, чем нужно до следующего кадра;
• принудительные пересчёты вёрстки;
• большое количество элементов DOM;
• отрисовка большого объёма HTML на стороне клиента через JavaScript.

Что делать на практике:

• Разбивайте длинные задачи. Отдавайте управление браузеру между частями работы, пусть даже простым setTimeout. В web.dev об этом сказано прямо: лучше отдавать управление без разбора, чем не отдавать вовсе.
• Оставляйте в обработчике клика только то, что меняет картинку на экране. Остальное откладывайте.
• Уменьшайте DOM. Сложную страницу с тысячами элементов обновлять всегда дороже.
• Выносите тяжёлые вычисления в веб-воркеры.
• Используйте content-visibility, чтобы браузер не отрисовывал то, что за пределами экрана.

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

CLS: самое дешёвое исправление

По Web Almanac, большинство страниц не указывает размеры изображений. Задать width и height или соотношение сторон — один из самых простых способов убрать «прыжки» вёрстки. Так же на большинстве страниц нет подсказок для загрузки шрифтов (preload, preconnect), хотя они помогают и LCP.

Как проверить свой сайт за 10 минут

1. Откройте PageSpeed Insights и вставьте адрес главной и одной-двух внутренних страниц.
2. Смотрите на блок с данными реальных пользователей (CrUX за последние 28 дней). Именно они решают, проходит ли страница Core Web Vitals. Лабораторный тест Lighthouse полезен для поиска причин, но оценкой не является.
3. Переключите вкладку на мобильные: они хуже.
4. Если данных реальных пользователей нет, PageSpeed Insights покажет данные по всему сайту. Если нет и их, трафика пока недостаточно для оценки, смотрите лабораторные результаты.
5. Запишите три значения (LCP, INP, CLS) и повторите проверку через месяц.

Что делать дальше

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

Хотите знать, что именно тормозит ваш сайт? Напишите нам: посмотрим показатели и скажем, что исправлять в первую очередь.

Автор: Сергей Филатьев — основатель авторской студии Veb-Dev.