INP: третья метрика Core Web Vitals — как перестать быть красным в 2026

Смотришь PageSpeed Insights, все метрики зелёные — LCP, CLS в норме — а сайт всё равно ощущается тормозящим. Клик по кнопке, задержка на полсекунды, потом реакция. Меню открывается через тап. Форма отправляется — но кнопка «залипает» на секунду.

Именно это и меряет INP. В марте 2024 Google похоронил FID (First Input Delay) — старая метрика измеряла только задержку на первый клик, чего было мало. Реальный пользователь взаимодействует со страницей десятки раз: скроллит, тапает, вводит текст. INP берёт худшую 98-ю перцентиль от всех interactions на странице — и это уже честная картина, а не одиночный красивый замер.

Разбираем: что она реально измеряет, откуда берутся плохие цифры на .by/.ru/.kz-сайтах, чем мерить в 2026, и семь конкретных правок, отсортированных по «работы на час → работа на неделю».

Что такое INP и почему он заменил FID

INP = Interaction to Next Paint. Каждый раз, когда пользователь взаимодействует со страницей — клик, тап, нажатие клавиши — браузер засекает время от начала интеракции до следующего кадра, где отрисовался видимый ответ. Не «когда обработчик отработал», не «когда JS закончил» — именно когда пользователь увидел изменение на экране.

Дальше берётся худшая задержка за всю сессию на странице (с небольшой поправкой на выбросы — Google использует 98-й перцентиль при 50+ interactions). Это и есть INP.

Почему это важнее старого FID:

• FID мерил только первый клик. Первый клик почти всегда быстрый — страница ещё не нагружена. Проблемы начинаются на 10-м клике, когда сработали все ленивые скрипты. FID это игнорировал.
• FID не мерил рендер. Только задержку до начала обработчика. То есть если обработчик отработал за 10 мс, но React отрисовал ответ через 400 мс — FID показывал «10 мс, зелёно». Пользователь при этом ждал полсекунды.
• FID не мерил клавиши и тапы после первого. INP берёт всё: скролл, ввод, тап, повторные клики.

Результат: у 90% сайтов при переходе с FID на INP цифры резко ухудшились. Не потому что сайт стал хуже — а потому что FID врал. По данным CrUX от Google за первый квартал 2026, доля мобильных сайтов с зелёным INP — около 62% (против 92% зелёного FID в 2023).

Первоисточник: web.dev/articles/inp — Google описывает метрику детально.

Пороги: где зелёная зона, где красная

Актуальные значения на 2026:

Пороги считаются отдельно для мобилы и десктопа. У мобилы почти всегда хуже — процессор слабее, JS-парсинг дольше, тапы вместо кликов (тап дольше клика на 100-300 мс из-за 300ms delay в старых движках, хотя на iOS 15+ и Android Chrome 88+ это уже неактуально).

Важно: чтобы страница считалась «прошла Core Web Vitals», нужно чтобы минимум 75% реальных пользователей за 28 дней получили INP в зелёной зоне. Это данные из CrUX (Chrome User Experience Report) — из настоящих браузеров, не из синтетики. Ты можешь в лаборатории иметь идеальные цифры, а в CrUX — красный. И CrUX Google ранжирует, а не твой PageSpeed.

Чем мерить INP

Пять инструментов, в порядке «от простого к глубокому»:

1. PageSpeed Insights + CrUX

pagespeed.web.dev — вставляешь URL, получаешь оба среза: реальные пользователи (CrUX, 28 дней) и лабораторный тест (Lighthouse, синтетика). Смотри именно CrUX-блок — там INP как «полевой» показатель. Если полевых данных нет (мало трафика), Google покажет только лабораторный — но лабораторный INP всегда занижен, потому что Lighthouse делает один-два клика, а не 50.

2. Search Console → «Основные интернет-показатели»

Если сайт верифицирован — GSC показывает распределение URL по трём зонам за 90 дней, отдельно для мобилы и десктопа. Это тот же CrUX, только агрегированный. Заходишь → «Опыт» → «Основные интернет-показатели» → смотришь количество страниц в красном и жёлтом. Больше — про GSC в отдельном посте GSC vs Яндекс.Вебмастер.

3. Chrome DevTools → Performance panel

Открой сайт в Chrome, F12 → Performance → Record → покликай по кнопкам, поменяю фильтры, отправь форму — Stop. В таймлайне появятся «Interaction» события с их длительностью. Ищи оранжевые/красные полоски > 200 мс. Это единственный способ понять, какая конкретно интеракция тормозит.

4. Расширение Web Vitals для Chrome

Web Vitals extension от Google — показывает live-цифры LCP, CLS, INP пока ходишь по сайту. Клик, тап, ввод — цифра обновляется в углу браузера. Очень удобно для проверки конкретной интеракции: «а если так тапнуть — тормозит?».

5. RUM (Real User Monitoring)

Собственный сбор INP с живых пользователей через web-vitals.js — легковесная библиотека Google, ~2 КБ. Кидаешь в DOM, она репортит цифры в твоё аналитическое хранилище (GA4, Метрика, свой endpoint). Даёт распределение по страницам, устройствам, соединениям. У .by-бизнеса на 100-500 визитов в сутки — избыточно (мало данных, шум). У .ru-магазинов на 10k+/день — обязательно.

Ты вообще смотрел DevTools Performance-таймлайн на своей главной? Или так, по цифре в PageSpeed? Если по цифре — 90% шансов, что ты не знаешь, что тормозит.

Что чаще всего делает INP красным

По моему опыту аудитов за последний год, красный INP на .by/.ru/.kz-сайтах бывает по пяти причинам. По убыванию частоты:

1. Жирные сторонние скрипты (60% случаев). Битрикс с 15 подключёнными модулями. WordPress с 8 включёнными плагинами. Виджеты онлайн-чатов (Jivo, LiveTex, Tawk, ВКонтакте виджет). Ретаргетинг-пиксели (Facebook Pixel, ВК Pixel, Яндекс.Аудитории). Каждый третий сайт услуг РБ имеет по 3-4 виджета, которые вместе крадут по 200-400 мс на интеракцию.
2. Обработчики кликов, которые синхронно делают тяжёлую работу (20%). Классика: клик по «Добавить в корзину» — синхронный вызов API, парсинг ответа, ререндер большого куска DOM. 400-800 мс легко.
3. Layout thrashing (10%). Обработчик читает element.offsetHeight, потом пишет element.style.width, потом снова читает — браузер вынужден пересчитывать layout после каждой записи. Заметно на слабых устройствах.
4. Тяжёлый JS-фреймворк с ненужной гидрацией (5%). Next.js/Nuxt на лендинге, где JS вообще не нужен — но фреймворк грузит 300 КБ и гидрирует всю страницу, блокируя main thread.
5. Всё остальное (5%). Собственные плохие обработчики, тяжёлые CSS-анимации через JS, редкий баг в проде.

Семь правок: от 30 минут до недели работы

1. Отложи сторонние скрипты (30 минут)

Самая частая победа. Все теги <script> сторонних сервисов — Jivo, ретаргетинг, ВК-виджеты — обязаны иметь атрибут defer или async. Если стоит без — переставь на defer. Это не решит INP полностью, но освободит main thread во время загрузки.

Для чатов и виджетов, которые появляются с задержкой: загружай их через setTimeout на 3-5 секунд после DOMContentLoaded. Или ещё лучше — по первому scroll/click событию. Виджет чата, который появляется через 2 секунды после первой активности пользователя — норм. Виджет, который блокирует main thread во время загрузки страницы — говно.

2. Разбей длинные задачи на куски (2-4 часа)

Google называет это yielding to main thread. Если у тебя обработчик клика делает 500 мс работы — разбей его через await scheduler.yield() или, если не Chrome-only, через setTimeout(fn, 0). Смысл: браузер получает возможность отрендерить кадр между кусками работы. Пользователь видит первый визуальный отклик через 50-100 мс, а не через 500.

Практический паттерн под React/Vue: startTransition из React 18+ помечает ререндер как «неспешный», и браузер сможет отрисовать первую реакцию до полного ререндера.

3. Дебаунс инпутов поиска и фильтров (1-2 часа)

Поле поиска, которое дёргает API на каждой букве, — топ-1 источник красного INP на e-commerce. Ставь дебаунс 300 мс: пользователь начал печатать → запрос уходит только через 300 мс после последней буквы. Просто и работает.

Ещё лучше: throttle на скролл-эвентах (например, sticky-нав, которая пересчитывает состояние на каждом скролле).

4. Убери synchronous layout из обработчиков (2-3 часа)

В коде обработчика клика/тапа не читай offsetHeight, getBoundingClientRect, scrollTop после того, как что-то записал в стили. Собери все чтения — потом все записи. Или используй requestAnimationFrame, чтобы отложить запись до следующего кадра.

Если пишешь на своём JS без фреймворка — грех первого свидания. Если пишешь на React/Vue — обычно фреймворк это разруливает сам, но не всегда.

5. Замени тяжёлые виджеты на лёгкие альтернативы (3-6 часов)

Jivo подключает 200+ КБ JS и в фоне пингует свой сервер каждые несколько секунд. В моём опыте — Jivo стабильно съедает 150-300 мс от INP. Альтернативы:

• Крипт кнопки WhatsApp/Telegram — 0 КБ JS, чистая ссылка. Работает у 80% сайтов услуг лучше, чем чат.
• Ленивая инициализация чата — показывай не сам виджет, а свою маленькую кнопку «Написать», по клику на которую грузишь чат. Пользователь ждёт 200 мс на первом клике, но 99% пользователей вообще не кликают на чат — их INP чистый.
• Chatwoot / self-hosted — если чат реально нужен и трафик большой, вложись в self-hosted решение.

6. Разгрузи основной поток через web workers (день-два)

Если у тебя реально тяжёлые вычисления в обработчиках (сортировка большого списка, парсинг JSON на 100 КБ, работа с датами по большому массиву) — вынеси в Web Worker. Main thread будет свободен для рендера, worker работает параллельно, ты получаешь результат через postMessage.

Не для лендингов. Для веб-приложений — обязательно.

7. Отрефачь гидрацию SPA (2-3 дня)

Крайняя мера. Если у тебя Next.js/Nuxt-лендинг с гидрацией на 500+ КБ JS, и INP красный по всем страницам — есть два пути:

• Partial hydration — не гидрируй компоненты, которые не интерактивны. Astro, Fresh, Qwik делают это по умолчанию. Next.js — через React Server Components и use client локально.
• Смена стека — если сайт по факту статичный (лендинг + форма + карусель), переезжай на Astro. Разница по INP на слабом Android — 500-700 мс. Не преувеличиваю.

Кейсы из живых аудитов

Автосалон в областном центре РБ, сайт на Битриксе. INP в CrUX — 620 мс (красный, мобильный). Причина: 4 виджета — Jivo, Яндекс.Диалоги, Facebook Pixel, ВК-пиксель — плюс собственный «фильтр по параметрам» с синхронным ререндером на каждой галочке. Убрал Jivo и Яндекс.Диалоги (клиент подтвердил, что лидов оттуда 2-3 в месяц), добавил debounce 300 мс на фильтр — через 4 недели CrUX показал 310 мс (жёлтый). Ещё через месяц — 240 мс (жёлтый, ближе к зелёному). Не эталон, но из 620 в 240 — уже победа.

Интернет-магазин мебели, ~800 SKU, WordPress + WooCommerce. INP 780 мс на мобильном. Причина: WooCommerce на каждый клик по фильтру делал полный AJAX-ререндер каталога через админ-ajax.php. Плюс 6 включённых плагинов, из которых 3 — «оптимизаторы», которые конкурируют друг с другом. Заменил стандартный фильтр на кастомный на Alpine.js с локальной фильтрацией уже загруженных SKU (первые 24 карточки), убрал 3 конкурирующих плагина, оставил только Autoptimize. INP через 6 недель — 195 мс (зелёный). Дало +18% к времени на сайте по Метрике.

Что не помогает и почему

• «Ускорить хостинг». INP — про main thread в браузере пользователя, а не про сервер. Ускоришь TTFB — не поможет.
• «Включить кэширование через WP Rocket / Битрикс-акселератор». Кэширование ускоряет отдачу HTML, но не то, что делает JS после загрузки. INP не двинется.
• «Минифицировать CSS/JS». Экономит 5-15% размера. INP это не меняет — там дело не в размере, а в блокировках main thread во время интеракции.
• «Добавить CDN». То же самое: быстрее загрузка, INP тот же.
• «Ускорить картинки, поставить WebP». Это про LCP, а не INP. Оба важные, но не путайте.

Правило: INP не чинится через «оптимизацию хостинга и картинок». Чинится через разгрузку main thread во время интеракции. Совсем другой уровень стека.

Как связать INP с реальным SEO-результатом

Тут будет прямо: INP как отдельный фактор ранжирования — слабый. Google подтвердил, что Core Web Vitals это тайбрейкер, а не топовый сигнал. Прямого «упал в топ-3 из-за INP» я в аудитах не видел.

Но есть косвенный эффект и он реальный:

• CTR из выдачи. На поиске Google показывает бейджик «Slow» на мобилах для страниц с плохим CWV. Пока не всегда и не для всех запросов, но бывает — и CTR падает.
• Поведенческие. Пользователь пришёл на страницу, потыкал, «залипло» — ушёл назад в выдачу. Google это видит, ранжирование медленно ползёт вниз.
• Конверсия. Здесь эффект самый большой. По моим замерам, при снижении INP с 600 до 200 мс конверсия форм на сайтах услуг растёт на 5-15%.

То есть INP чинить надо. Но не ради «попадания в топ», а ради того, чтобы твой пришедший трафик конвертил, а не отваливался от лагов.

Инструменты, которые реально стоит открыть

• PageSpeed Insights — быстрый чек, реальные CrUX + лабораторный Lighthouse.
• GSC → Core Web Vitals — где красных страниц больше всего.
• Chrome DevTools → Performance — найти конкретный обработчик, который тормозит.
• web-vitals.js — для сайтов с трафиком > 1000 визитов/сутки, собирать RUM в свою аналитику.
• WebPageTest — глубокая лабораторная диагностика через прокси, с фильмами загрузки. Бесплатно 300 тестов/мес.

FAQ

INP не всесильный фактор — но реально ощутимый. Пользователь, который тапает по кнопке и получает моментальный ответ, кликает по следующей. Пользователь, который тапает и ждёт 700 мс — уходит на maps.google.com искать конкурента, у которого не тормозит. Это не про Google — это про твою конверсию.

Хочешь разобраться с CWV системно — начни с общего обзора Core Web Vitals в 2026: LCP, INP, CLS. Плюс подтяни техничку: Robots.txt и Schema.org микроразметка.