INP реальный (responsive UI)

Что это

INP (Interaction to Next Paint) — метрика Core Web Vitals, измеряющая задержку отклика интерфейса на действия пользователя: клики, нажатия клавиш, тапы. В отличие от лабораторных данных, реальный INP собирается из поля — из отчётов Chrome User Experience Report (CrUX) на основе фактических сессий. Метрика фиксирует худший (или близкий к 98-му перцентилю) показатель задержки за всё время сессии и выражается в миллисекундах.

---

Почему это важно для SEO

С марта 2024 года INP официально заменил FID (First Input Delay) в составе Core Web Vitals. Google напрямую использует CWV в алгоритме Page Experience, а INP — самый сложный для прохождения порог: хорошо ≤ 200 мс, требует улучшения 200–500 мс, плохо > 500 мс. По данным HTTP Archive на начало 2024 года, около 30% сайтов не укладывались в «хороший» диапазон INP — это заметно выше, чем доля провалившихся по FID.

Реальный INP влияет на ранжирование в Google напрямую через сигнал Page Experience. В Google Search Console плохой INP помечает URL как «требующие улучшения» и может привести к понижению в выдаче при прочих равных. Для AI Overviews и Google Discover попадание в хорошие CWV — обязательное условие: страницы с плохими показателями поля значительно реже попадают в блоки с быстрым доступом. Яндекс пока не объявил INP частью формулы, но поведенческие факторы (отказы, глубина, время на сайте) косвенно реагируют на «залипающий» интерфейс — это бьёт по ИКС и позициям.

---

Как проверить вручную

1. Google Search Console → Основные веб-показатели: откройте отчёт, выберите «Мобильные» / «Компьютеры». Найдите группу URL с плохим INP. Данные берутся из реального поля (CrUX), нужно минимум ~100 сессий на URL за 28 дней.

1. PageSpeed Insights: введите URL — в разделе «Данные реальных пользователей» увидите INP по полю. Рядом — лабораторный TBT (Total Blocking Time), который косвенно коррелирует с INP.

1. Chrome DevTools → Performance панель: запишите профиль при взаимодействии с элементами. Ищите длинные «Tasks» (> 50 мс) на треке Main Thread — это прямые кандидаты в источники плохого INP.

1. web-vitals JS библиотека: добавьте на страницу для самостоятельного сбора метрики в реальном времени:

<script type="module">
  import {onINP} from 'https://unpkg.com/web-vitals?module';
  onINP(({value, rating, attribution}) => {
    console.log('INP:', value, rating, attribution);
  });
</script>

1. Screaming Frog: сам INP не измеряет, но помогает найти страницы с тяжёлыми скриптами и большим DOM — косвенные причины плохого INP.

---

Как исправить

Шаг 1. Найдите длинные задачи. В Chrome DevTools → Performance включите Web Vitals и запишите сессию с кликами. Любой блок Main Thread > 50 мс — потенциальная проблема.

Шаг 2. Разбейте длинные задачи через `scheduler.yield`.

async function processItems(items) {
  for (const item of items) {
    processOne(item);
    // Уступаем управление браузеру после каждой итерации
    await scheduler.yield();
  }
}

Шаг 3. Откажитесь от синхронных обработчиков на клик. Выносите тяжёлые вычисления в Web Workers или разбивайте через setTimeout(fn, 0).

Шаг 4. Уменьшите размер DOM. Более 1400 нод замедляют layout-пересчёты. Используйте виртуализацию списков (например, @tanstack/virtual).

Шаг 5. Оптимизируйте сторонние скрипты. Загружайте через async/defer, откладывайте аналитику до requestIdleCallback.

Решения по CMS:

• WordPress: установите плагин Perfmatters или Asset CleanUp, отключите JS плагинов на страницах, где они не нужны.
• Tilda: ограниченные возможности — переносите кастомные скрипты в Zero Block с defer, избегайте сторонних виджетов чата без ленивой загрузки.
• 1C-Bitrix: в настройках компонентов включите «Отложенные функции JS», используйте CDN через модуль «Производительность».
• Webflow: в Project Settings → Custom Code грузите скрипты через defer; тяжёлые взаимодействия выносите на внешний Worker через Cloudflare.

---

Типичные ошибки

1. Путают лабораторный и реальный INP. PageSpeed Insights и Lighthouse дают лабораторный TBT — он коррелирует с INP, но не равен ему. Решения принимайте по данным поля (CrUX / GSC).

1. Оптимизируют только LCP и CLS, игнорируя INP. После введения метрики именно INP стал «узким местом» у большинства интерактивных сайтов.

1. Навешивают обработчики `mousemove` / `scroll` без дебаунса. Это создаёт постоянную нагрузку на Main Thread и ухудшает INP косвенно.

1. Не учитывают мобильный INP отдельно. На слабых устройствах INP может быть в 3–5 раз хуже, чем на десктопе. GSC разделяет отчёты — проверяйте оба.

1. Игнорируют атрибуцию. Библиотека web-vitals с версии 3.x передаёт attribution — конкретный DOM-элемент и фазу задержки (input delay / processing / presentation). Без этого исправление «вслепую».

---

Влияние на разные типы сайтов

Интернет-магазины страдают от плохого INP сильнее всего: фильтры каталога, добавление в корзину, мини-корзина в шапке — каждый клик проходит через INP-измерение. Задержка 400–500 мс при «Добавить в корзину» напрямую бьёт по конверсии и одновременно ухудшает Page Experience-сигнал в Google.

Контентные сайты и медиа рискуют меньше, но виджеты комментариев, поп-апы подписки и ленивые рекламные блоки часто становятся источником плохого INP на мобильных. SaaS и сложные веб-приложения — самые уязвимые: богатый JS-интерфейс, много компонентов, длинные реактивные цепочки во Vue/React. Здесь без профилирования через DevTools и поэтапной оптимизации не обойтись. Лендинги с минимальным JS редко имеют проблемы с INP, если не подключены тяжёлые сторонние скрипты (чаты, ретаргетинг).