Оптимизация INP: метрика Core Web Vitals, которую игнорируют

Оптимизация INP сводится к трём вещам: разбить длинные задачи JavaScript, разгрузить обработчики событий и убрать лишний код с пути взаимодействия. Порог для INP - 200 миллисекунд на 75-м процентиле визитов. Пока LCP и CLS чинятся заменой картинки и резервированием места под блоки, INP требует переписывать логику отклика интерфейса - поэтому её чаще всего откладывают.

По сводке CrUX-отчёта Google за май 2026 года у INP самый высокий индивидуальный показатель прохождения среди трёх Core Web Vitals - 86,6% против 68,6% для LCP, по данным обзора DigitalApplied. Из этого не следует, что INP - лёгкая метрика: просто на неё реже смотрят. LCP правится заменой одной картинки и preload-тегом, а на INP нужно перепроектировать обработку кликов.

В проектах миграции на headless-стек мы регулярно видим один и тот же паттерн: LCP и CLS выправляются в первую неделю после запуска, а INP остаётся плохим ещё месяцами. Причина не в стеке - Astro и Next.js сами по себе быстрые. Причина в стороннем коде и обработчиках событий, которые никто не профилировал.

Дальше - что такое INP технически, почему она заменила FID в марте 2024 года, и как её чинить на конкретных причинах: длинные задачи, обработчики событий, сторонние скрипты и гидратация фреймворков.

Проблема ощущается не на графике Lighthouse, а в реальном использовании. Пользователь нажимает кнопку «Добавить в корзину», интерфейс не отвечает 400-500 миллисекунд, и на мобильном устройстве это читается как зависание. Google использует INP как часть сигналов page experience при ранжировании, а конверсия проседает раньше, чем это заметит SEO-отчёт.

INP (Interaction to Next Paint): метрика Core Web Vitals, которая измеряет время от начала любого взаимодействия пользователя со страницей - клика, тапа, нажатия клавиши - до момента, когда браузер отрисовывает видимый результат этого действия.

Как измерить INP: полевые данные и лабораторные тесты

INP нельзя достоверно измерить одним прогоном в лабораторных условиях - метрике нужны реальные взаимодействия пользователя на реальном устройстве.

Полевые данные (CrUX) собираются из реального трафика Chrome за скользящее окно 28 дней. Именно их видит Google Search Console в разделе «Core Web Vitals» и именно они влияют на ранжирование. Lighthouse в DevTools или PageSpeed Insights - лабораторный тест: он показывает оценочный INP по эмулированным взаимодействиям, но не заменяет полевые данные.

Для точного профилирования в продакшене используйте библиотеку web-vitals от Google: она отправляет реальные значения INP с устройств пользователей в вашу аналитику. Для отладки конкретного взаимодействия - вкладка Performance в Chrome DevTools: запишите сессию, кликните по проблемному элементу и найдите красные блоки в треке Main.

Пороговые значения, актуальные на середину 2026 года:

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

LCP и CLS исправить просто, INP - нет: в чём разница

LCP и CLS решаются декларативно: один раз настроил preload и width/height у изображений - показатель зафиксирован. С INP так не работает, поэтому команды сайта чинят первые две метрики и оставляют третью без внимания.

Быстрые победы для LCP: preload hero-изображения, конвертация в WebP, font-display: swap для шрифтов, ускорение TTFB через CDN. Быстрые победы для CLS: атрибуты width и height у всех изображений, зарезервированное место под баннеры и виджеты. Это разовые инфраструктурные правки.

INP так не чинится. Она требует работы с каждым интерактивным элементом на каждой странице: фильтром, кнопкой, полем формы, чат-виджетом. Единой галочки «включить в настройках» для этого не существует.

Если у вас сайт именно на WordPress, LCP и CLS для этой платформы разобраны отдельно - в гайде по Core Web Vitals для WordPress есть конкретные причины для Elementor и типичных плагинов. Здесь фокус - на INP и на том, что работает одинаково на WordPress, Astro, Next.js и любом headless-стеке.

Три фазы INP: где теряется время отклика

INP - это не одно число, а сумма трёх фаз. Для оптимизации важно понимать, в какой из них теряется время конкретного взаимодействия.

Задержка ввода (input delay) - время от нажатия до начала работы обработчика события. Растёт, если main thread в этот момент занят другой задачей: загрузкой скрипта, рендерингом, обработкой предыдущего события.

Время обработки (processing time) - выполнение самого обработчика события: обновление состояния, вычисления, синхронные запросы к DOM.

Задержка отрисовки (presentation delay) - время от завершения обработчика до момента, когда браузер отрисовывает новый кадр. Растёт при сложном дереве DOM, дорогих CSS-вычислениях или больших списках, которые пересчитывают layout целиком.

Сумма трёх фаз и есть INP конкретного взаимодействия. Метрика страницы - это худшее (или близкое к худшему) значение среди всех взаимодействий за сессию, а не среднее.

Длинные задачи - главная причина плохого INP

Длинная задача (long task): любой фрагмент JavaScript, который выполняется в main thread дольше 50 миллисекунд, не передавая управление браузеру. Пока такая задача выполняется, браузер не может обработать клик пользователя - это и есть задержка ввода.

Основные источники длинных задач: тяжёлые JS-бандлы, которые выполняются синхронно при загрузке, циклы без разбивки на части, дорогие пересчёты состояния при каждом изменении, синхронное чтение и запись DOM подряд (layout thrashing - когда браузер вынужден пересчитывать раскладку страницы несколько раз за один кадр).

Разбивка длинной задачи на части возвращает управление браузеру между итерациями, и он успевает обработать клик пользователя вовремя.

// Плохо: длинная задача блокирует main thread целиком
function processItems(items) {
  for (const item of items) {
    updateDOM(item); // например, 10 000 итераций синхронно
  }
}

// Лучше: задача разбивается через scheduler.yield()
async function processItems(items) {
  for (const item of items) {
    updateDOM(item);
    if (navigator.scheduling?.isInputPending()) {
      await scheduler.yield();
    }
  }
}

scheduler.yield() - актуальный API от Chrome для этой задачи. В браузерах без поддержки работает fallback через setTimeout(fn, 0) или requestIdleCallback - эффект слабее, но принцип тот же: не удерживать main thread дольше 50 миллисекунд за раз.

Обработчики событий, которые сами создают задержку

Второй по частоте источник плохого INP - обработчики, которые делают слишком много работы на каждое срабатывание события, а не только на клик.

Обработчики input для поиска или живой валидации формы часто выполняют тяжёлые вычисления на каждое нажатие клавиши. Обработчики scroll и resize без ограничения частоты срабатывают десятки раз в секунду и каждый раз пересчитывают layout.

Что помогает на практике: debounce для полей ввода (задержка 150-250 миллисекунд перед реакцией на ввод), throttle для scroll и resize, пассивные слушатели событий ({ passive: true }) для touch и wheel, чтобы браузер не ждал завершения обработчика перед скроллом. Изменения DOM стоит группировать через requestAnimationFrame, а не применять по одному сразу при каждом событии.

Отдельная частая ошибка - чтение геометрии элемента (offsetWidth, getBoundingClientRect) сразу после изменения стиля. Это форсирует синхронный пересчёт layout и добавляет задержку отрисовки именно в момент взаимодействия.

Сторонние скрипты - тихий источник плохого INP

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

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

Найти виновника можно через вкладку Performance в Chrome DevTools: длинные задачи там подписаны источником скрипта, а в PageSpeed Insights есть раздел «Уменьшите влияние стороннего кода» с конкретным списком доменов и временем блокировки.

Рабочий приём - отложенная загрузка («facade»): вместо реального виджета на странице сначала показывается лёгкая заглушка, а полный скрипт подгружается только после первого скролла, клика или через несколько секунд простоя. Пользователь видит интерфейс сразу, а тяжёлый код не конкурирует за main thread в момент, когда странице важнее всего быть отзывчивой.

Гидратация Astro, Next.js и headless-сайтов

На headless-сайтах есть отдельная причина плохого INP - гидратация: страница выглядит готовой визуально, но клики по ней ещё не обрабатываются.

Сервер отдаёт готовый HTML быстро, поэтому LCP выглядит хорошо. Но браузеру ещё нужно скачать и выполнить JS-бандл, который «оживляет» интерфейс. Если фреймворк гидратирует всё дерево компонентов целиком, клики во время этого процесса встают в очередь и обрабатываются с опозданием - INP в 500 и больше миллисекунд получается именно так, а не из-за одного тяжёлого обработчика.

Astro решает это архитектурой островов: JavaScript отправляется в браузер только для по-настоящему интерактивных компонентов, остальная разметка остаётся статическим HTML без гидратации вообще. Next.js с React Server Components и селективной или потоковой гидратацией даёт похожий эффект: интерактивные части получают приоритет, а не весь дерево страницы целиком помечается директивой use client.

Если вы ещё выбираете стек для миграции с WordPress или Tilda, разница между headless CMS ощутимо влияет на итоговый INP - подробнее в сравнении Sanity, Contentful и Strapi для B2B-сайта.

Реальный кейс: INP от 480 до 140 миллисекунд

В типовом проекте миграции интернет-магазина на headless-стек INP был худшей из трёх метрик, несмотря на быстрый LCP: 480 миллисекунд на 75-м процентиле мобильных визитов.

Профилирование в DevTools показало три источника. Чат-виджет поддержки инициализировался синхронно при загрузке и занимал main thread больше 300 миллисекунд. Фильтры каталога пересчитывали весь список товаров на каждый клик по чекбоксу без debounce. Карточки товаров гидратировались целиком, хотя интерактивным в них была только кнопка «В корзину».

За три недели применили три точечных исправления: перевели чат-виджет на facade-загрузку после первого скролла, добавили debounce 150 миллисекунд на фильтры каталога, перешли на островную гидратацию для карточек товара. INP на полевых данных снизился до 140 миллисекунд в течение месяца - именно столько нужно скользящему окну CrUX, чтобы полностью отразить изменения.

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

Для кого актуальна оптимизация INP

Сильнее всего от плохого INP страдают сайты с частыми интерактивными действиями: интернет-магазины с фильтрами и корзиной, SaaS-панели с формами и таблицами, лендинги с живой валидацией полей. На мобильном трафике задержка ощущается острее, потому что процессоры слабее, а пользователь держит палец на экране и физически видит паузу перед откликом.

Отдельная категория - компании, у которых на сайте уже накопился набор маркетинговых и аналитических скриптов: чат, несколько пикселей, форма опроса, виджет отзывов. Каждый из них по отдельности незаметен, а вместе они создают INP выше 400 миллисекунд даже на быстром хостинге. Это типично для компаний от 15 сотрудников, где сайтом одновременно управляют маркетинг, продажи и поддержка.

Часто задаваемые вопросы

Что считается хорошим показателем INP?

Хорошим считается INP ниже 200 миллисекунд на 75-м процентиле визитов, отдельно для мобильных и десктопных пользователей. Диапазон 200-500 миллисекунд Google помечает как «требует улучшения», а выше 500 миллисекунд - как «плохо». Порог измеряется по полевым данным CrUX за скользящее окно 28 дней, а не по одному лабораторному прогону Lighthouse.

Почему INP заменила FID в марте 2024 года?

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

Сколько времени занимает оптимизация INP на сайте с большим количеством сторонних скриптов?

Аудит и точечные исправления - facade-загрузка виджетов, debounce обработчиков, разбивка длинных задач - обычно занимают от одной до трёх недель на типовом проекте, в зависимости от количества стороннего кода. После деплоя изменений полевые данные CrUX обновляются постепенно: полную картину в Search Console стоит ждать через 28 дней, потому что метрика считается по скользящему окну.

Можно ли улучшить INP без миграции на другой фреймворк?

Да, для большинства сайтов основной прирост даёт не смена стека, а работа с конкретными причинами: аудит длинных задач, facade-загрузка сторонних виджетов, debounce и throttle для обработчиков событий. Проблема гидратации специфична для headless-сайтов на React-подобных фреймворках без селективной гидратации - на WordPress или классическом сервер-рендеринге её просто не существует в таком виде.

Влияет ли INP на позиции сайта в поиске Google?

Да, INP входит в сигналы page experience наряду с LCP и CLS, которые Google учитывает при ранжировании. Влияние на позиции меньше, чем у релевантности контента, но при прочих равных сайт с хорошими Core Web Vitals получает преимущество, особенно в мобильной выдаче. Более прямой эффект INP даёт на конверсию: пользователи уходят со страницы, если интерфейс не отвечает на действия быстро.

Что стоит сделать в первую очередь:

• Проверить INP по полевым данным в Search Console или PageSpeed Insights, а не только по лабораторному Lighthouse-скору
• Найти длинные задачи через вкладку Performance в Chrome DevTools и привязать их к конкретному скрипту
• Перевести тяжёлые сторонние виджеты на facade-загрузку, а обработчики событий - на debounce и throttle
• Для headless-сайтов на Astro или Next.js отдельно проверить стратегию гидратации - это не решается теми же приёмами, что LCP

Если у вас сайт на Astro, Next.js или другом headless-стеке и полевые данные показывают INP выше 200 миллисекунд - опишите задачу команде Exceltic.dev. Разберём длинные задачи, обработчики событий и стратегию гидратации, предложим конкретный план исправления. Это часть разработки и оптимизации сайтов, которой занимается Exceltic.dev.