INP под микроскопом: как добиться < 200 ms в проде

INP (interaction to next paint) отражает, насколько сайт отзывчив к пользователю.
Когда интерфейс реагирует с задержкой, падает конверсия и растёт показатель отказов.
Google считает значение до 200 ms отличным результатом — всё, что выше, снижает пользовательский опыт и SEO-метрики.

Почему возникают лаги

Главная причина низкого INP — длинные задачи на основном потоке: рендер, тяжёлые скрипты, синхронные обработчики событий.
Даже мощный сервер и кэш не помогут, если фронтенд блокирует отрисовку.
К этому добавляются тяжёлые сторонние виджеты, не оптимизированные изображения и отсутствие приоритезации процессов.

Как добиться INP < 200 ms без рефактора

Разрубаем long tasks.
Разносим инициализацию по этапам, тяжёлые вычисления переносим в web workers или выполняем через requestIdleCallback.
Главное — не блокировать интерфейс и отдавать приоритет взаимодействию.

Снижаем нагрузку JavaScript.
Удаляем мёртвый код, включаем code splitting, настраиваем ленивую загрузку не-критичных компонентов.
Это сокращает время выполнения скриптов и уменьшает вес страницы.

Оптимизируем обработчики событий.
Используем делегирование, пассивные слушатели ({ passive: true }) для скролла и тача,
отказываемся от синхронных XHR в пользу async/await и AbortController.

Ускоряем рендер.
Избегаем layout-thrashing — объединяем измерения и стили, используем CSS-транзиции вместо JS-анимаций и skeleton-прелоадеры для плавного UX.

Чистим 3rd-party.
Виджеты и пиксели подключаем по взаимодействию (idle/visible),
исключаем блокирующие скрипты и оставляем только асинхронную загрузку.

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

Используем RUM (real user monitoring) и синтетические тесты (Lighthouse, Web Vitals).
Отслеживаем показатели по ключевым страницам — карточке товара, корзине, checkout.
Для стабильности задаём алерты:
— INP p75 < 200 ms;
— сегменты: мобайл / десктоп / регионы.