# INP вместо FID: как мы готовили сайты к новой метрике

> Interaction to Next Paint строже предшественника и ловит проблемы, которые FID пропускал. Что пришлось чинить на десятке проектов и какие приёмы сработали.

Адрес: https://egerpro.ru/blog/inp-vmesto-fid-podgotovka/
Обновлено: 2026-09-27

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

## Почему сайты, «зелёные» по FID, оказались красными по INP

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

Из десяти проектов, которые мы проверили, семь укладывались в FID и только четыре — в INP. Пороговые значения: до 200 мс хорошо, 200–500 мс требует внимания, больше 500 мс плохо.

## Четыре причины, которые встретились чаще всего

### 1. Обработчик делает слишком много за раз

Классика — фильтр каталога, который на каждый клик пересобирает весь список из тысячи позиций. Решение: разбить работу и отдать браузеру возможность отрисовать кадр.

```
// Было: всё в одном обработчике, экран замирает
button.addEventListener('click', () => {
  applyFilter(items)      // тяжёлый пересчёт
  renderList(items)       // и сразу перерисовка
})

// Стало: сначала отклик, потом работа
button.addEventListener('click', () => {
  setActiveState(button)  // мгновенная реакция
  requestAnimationFrame(() => {
    applyFilter(items)
    renderList(items)
  })
})
```

### 2. Сторонние скрипты занимают главный поток

Чаты, пиксели, виджеты отзывов. Каждый по отдельности незаметен, вместе они дают сотни миллисекунд. Мы выносим их загрузку на момент первого скролла или взаимодействия — до этого они не нужны.

### 3. Анимации, которые перерисовывают макет

Анимировать можно `transform` и `opacity` — они не заставляют браузер пересчитывать положение элементов. Анимация `width`, `top` или `margin` запускает перерасчёт всей страницы на каждом кадре.

### 4. Слишком большой DOM

Страница на 6 000 узлов пересчитывается заметно дольше, чем на 1 500. Каталоги без виртуализации и «бесконечные» ленты — главные нарушители.

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

Лабораторные инструменты INP не покажут: метрика собирается с реальных пользователей. Смотрите Chrome UX (удобство для пользователя) Report или подключите сбор web-vitals на своём сайте — только так увидите настоящие цифры.

## Что дало наибольший эффект

- Отложенная загрузка сторонних виджетов: **−120 мс** к INP в среднем
- Разбиение тяжёлых обработчиков: **−90 мс** на страницах каталога
- Замена анимаций макета на `transform`: **−40 мс**
- Сокращение DOM на страницах категорий: **−60 мс**

## Порядок работы, который мы используем

1. Собираем реальные INP с пользователей минимум две недели.
2. Находим страницы и элементы с худшими значениями — метрика умеет отдавать селектор.
3. Профилируем именно эти взаимодействия в DevTools на медленном устройстве.
4. Чиним по одному и снова замеряем: без замеров легко «оптимизировать» не туда.

## Что на самом деле мерит INP

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

Сама задержка складывается из трёх частей, и полезно понимать, какая именно у вас длинная. Input delay — время, пока браузер вообще не мог заняться событием, потому что главный поток был занят. Processing time — работа самого обработчика. Presentation delay — время до того, как результат появился на экране.

Разница практическая: если велик input delay, чинить надо не обработчик, а то, что занимает поток до него, — чаще всего сторонние скрипты. Если велико presentation delay, дело в перерисовке: слишком большой DOM или анимация свойств, которые заставляют пересчитывать макет.

## Что мы пробовали и отбросили

Первым побуждением было завернуть все обработчики в requestIdleCallback. На бумаге красиво, на практике интерфейс начал отвечать с заметной задержкой даже там, где всё было быстро: браузер откладывал работу, когда откладывать было нечего. Оставили только для действительно необязательных вещей — отправки аналитики, предзагрузки.

Второй тупик — оптимизация по лабораторным замерам. Lighthouse показывает Total Blocking Time, и его легко улучшить до отличных цифр, не сдвинув INP ни на миллисекунду. Причина простая: лаборатория не знает, куда на самом деле нажимают люди. Пока не собрали полевые данные, оптимизация была стрельбой в темноте.

- Виртуализация списков помогает, но только начиная примерно с тысячи элементов
- Debounce на вводе улучшает ощущение, но не INP: задержка считается от первого события
- Web Workers дают выигрыш там, где есть настоящие вычисления, а не работа с DOM

## Частые вопросы

**Какое значение INP считается хорошим?**

До 200 мс — хорошо, от 200 до 500 — требует улучшения, свыше 500 — плохо. Оценка идёт по 75-му процентилю реальных пользователей за 28 дней, поэтому единичные всплески погоду не делают, а систематические — делают.

**Можно ли посмотреть INP до запуска сайта?**

Полноценно — нет, метрика собирается только с реальных посетителей. Но приблизиться можно: откройте страницу в Chrome с включённым замедлением процессора в четыре раза и покликайте по интерфейсу. Если при таком замедлении отклик заметен глазом, у части аудитории он будет заметен и без него.

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

Он входит в набор сигналов о качестве страницы. Прямого веса, который перевесил бы релевантность, у него нет: плохой INP не выкинет вас из выдачи, если материал лучший по теме. Но при сопоставимом качестве страниц он работает как аргумент в пользу более отзывчивой.

INP — редкий случай, когда метрика напрямую отражает то, что чувствует человек. Сайт, который отвечает на клик мгновенно, воспринимается быстрым, даже если картинки грузятся дольше.