INP: input delay, processing, presentation

Страница результатов поиска ощущается быстрой после нескольких секунд — но в первые 3 секунды после загрузки каждый тап по кнопке занимает почти полсекунды. Сами обработчики работают 8 мс. Остальное время — не в обработчике вообще. Это ловушка INP: симптом в метрике, но причина в архитектуре.

Что измеряет INP — и что заменило FID.

Interaction to Next Paint заменила First Input Delay (FID) как Core Web Vital в марте 2024. FID измерял только задержку до старта обработчика первого ввода — она пропускала весь остальной жизненный цикл страницы и пропускала взаимодействия, которые были медленными потому что сам обработчик или результирующий рендер были тяжёлыми. INP измеряет полную задержку input-to-paint каждого клика, тапа и нажатия клавиши и репортит высокий перцентиль (фактически худший, с малой поблажкой на страницах с многими взаимодействиями). Задержка одного взаимодействия: от момента ввода пользователя до следующего кадра, видимо отражающего изменение. Хорошо: ≤200 мс на p75.

Три части задержки одного взаимодействия.

INP любого взаимодействия раскладывается на три последовательных части:

1. Input delay — время, которое событие ввода ждёт, прежде чем его обработчик вообще сможет стартовать, потому что главный поток занят другой задачей. Это урок event loop напрямую: длинная задача в полёте задерживает ввод. Задача может быть JS, пересчётом стилей или компоновкой — чем угодно, удерживающим поток.

2. Processing time — сколько реально работают обработчики событий. Для большинства взаимодействий на хорошо написанной странице это 10–30 мс. Если 200 мс — обработчик и есть проблема.

3. Presentation delay — время после окончания обработчиков, пока браузер прогоняет стили, компоновку, отрисовку и композитинг и кладёт результат на экран. Обработчик, запускающий ре-рендер 5 000 узлов, имеет большой presentation delay, даже если логика обработчика была быстрой.

Плохой INP всегда одно из этих трёх. Назвать, какая часть доминирует — вся диагностика.

Оптимизация каждой части.

Input delay: Перестаньте слать длинные задачи. Разбивайте работу на куски под 50 мс, дефер-ите несрочный JS, и помните, что гидратация — одна большая длинная задача рано в жизни страницы. Используйте scheduler.yield() между кусками, чтобы вернуть управление браузеру.

Processing time: Держите обработчики маленькими. Если обработчик должен делать тяжёлую работу, делайте минимум синхронно для обновления UI, затем уступайте и продолжайте — или перенесите чистое вычисление в Worker. Мощный паттерн: обновить видимое состояние синхронно и обернуть дорогую работу ниже по потоку в startTransition, чтобы отрисовка, которую ждёт пользователь, не блокировалась ею.

Presentation delay: Избегайте принудительной синхронной компоновки в обработчике (чтение layout-свойства после DOM-записи принуждает браузер немедленно перезапустить компоновку). Держите обновления DOM малыми — обработчик, перерендеривающий 5 000 узлов, имеет тяжёлый presentation delay независимо от скорости логики обработчика.

Окно гидратации — это ловушка INP.

Самый частый INP-провал на server-rendered сайте — взаимодействия, происходящие во время гидратации. Страница отрисована, пользователь видит кнопку и тапает её — но главный поток выполняет длинную задачу гидратации. Обработчик тапа может ещё не быть привязан, и даже когда привяжется, ввод стоит в очереди за остатком гидратации. INP записывает большую задержку для того раннего взаимодействия.

Паттерн характерный: INP плох только для взаимодействий в первые несколько секунд, потом нормален. Если обработчики были причиной, INP был бы плохим для всех взаимодействий. Ограниченный по времени паттерн указывает прямо на гидратацию. Каждый приём, сокращающий гидратацию — Server Components, острова, выборочная и прогрессивная гидратация, code-splitting — одновременно оптимизация INP.