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

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. Каталоги без виртуализации и «бесконечные» ленты — главные нарушители.

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

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

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

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

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

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

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

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

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

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