Разберём INP и работу с INP Scanner Milten при исследовании медленного отклика. INP заменил FID в составе Core Web Vitals в марте 2024 года. Лабораторный запуск проверяет выполненные действия, а не опыт всех посетителей.
Что такое Interaction to Next Paint (INP)?
Interaction to Next Paint (INP) оценивает отзывчивость страницы при кликах, нажатиях на сенсорный экран и работе с клавиатурой в течение посещения. Задержка взаимодействия включает ожидание обработки ввода, выполнение обработчиков и ожидание следующей отрисовки. FID учитывал только задержку первого ввода, а INP рассматривает подходящие взаимодействия на протяжении посещения. Полное время последующего асинхронного ответа сервера эта метрика не измеряет.
Ключевые особенности INP:
- Агрегация: INP не является средним значением. Обычно он отражает самое медленное взаимодействие, с исключением выбросов при большом числе взаимодействий.
- Пороги: хорошо — не более 200 мс; требуется улучшение — больше 200, но не более 500 мс; плохо — больше 500 мс. Для оценки реальных посещений используют 75-й перцентиль отдельно для мобильных и настольных устройств.
- Учитываемые действия: клики, нажатия на сенсорный экран и ввод с клавиатуры. Прокрутка и наведение сами по себе в INP не входят.
Почему INP важна для вас?
1. Пользовательский опыт (UX)
Если визуальный отклик запаздывает, кнопка может казаться неработающей, и пользователь нажмёт её повторно. Проверяйте конкретное взаимодействие и результат действия. Статистику о времени загрузки страницы нельзя выдавать за измеренное влияние INP на отказы вашего сайта.
2. SEO и ранжирование
INP входит в Core Web Vitals, которые используются системами ранжирования Google. Хорошая оценка не гарантирует высокую позицию, а плохая не доказывает фиксированный штраф. Рассматривайте отзывчивость вместе с полезностью контента и другими составляющими удобства страницы.
3. Конкуренция за скорость
Быстрый визуальный отклик помогает понять, что действие принято. Сравнивайте важные для аудитории сценарии: одинаковая задержка может по-разному влиять на разные задачи.
Как работать с INP Scanner Milten
INP Scanner помогает исследовать отзывчивость в контролируемом браузерном запуске. Прежде чем обобщать выводы, проверьте выполненные действия и ограничения отчёта.
1. Уточните проверенные действия
Выберите характерный сценарий и убедитесь, какие действия действительно выполнены:
- Клики по кнопкам и ссылкам.
- Ввод с клавиатуры в нужные поля.
- Прокрутка для доступа к элементу; сама прокрутка не является взаимодействием INP.
Контролируемый запуск — воспроизводимый сценарий, а не измерение на устройствах всех посетителей. Зафиксируйте фактический браузер, профиль устройства и условия. Важные сценарии, не охваченные запуском, дополните ручной проверкой.
2. Разберите данные о задержке
Для измерения INP используются данные Event Timing. Через PerformanceObserver можно наблюдать поддерживаемые записи event; универсального типа render для этой задачи нет. Группировку событий и расчёт INP выполняет, например, библиотека web-vitals.
- Различайте задержку ввода, выполнение обработчиков и ожидание отрисовки.
- Исследуйте длинные JavaScript-задачи в основном потоке.
- Плавность анимации проверяйте как связанную, но отдельную характеристику.
3. Исследуйте замечания
Опирайтесь на данные, которые действительно есть в отчёте:
- Найдите записанные взаимодействия и их целевые элементы.
- Разберите медленное действие: например, учебную кнопку «Купить» с задержкой 600 мс. Это иллюстрация, а не измерение клиентского проекта.
- Проверьте предполагаемую причину в записи производительности браузера и испытайте ограниченную правку кода.
Границы автоматического запуска
- Условия доступа к сервису и состав отчёта проверяйте по текущему интерфейсу.
- Браузерный тест сам по себе не подтверждает проверку на физических устройствах пользователей.
- Непроверенные действия и отсутствующие данные остаются неподтверждёнными; при наличии дополняйте результат полевыми измерениями.
Частые причины медленного отклика
1. Долгие обработчики событий
Пример:
button.addEventListener('click', () => {
// Синхронная обработка 10 000 строк данных
const result = heavyCalculation(data)
updateUI(result)
})
Проблема: синхронная работа heavyCalculation занимает основной поток и может задержать следующую отрисовку. Решение: сократите вычисления, разбейте их на части или перенесите подходящую работу в Web Worker. Один setTimeout лишь отложит ту же тяжёлую задачу, а не вынесет её из основного потока.
2. Блокирующий рендеринг CSS/JS
Пример:
<link rel="stylesheet" href="large-styles.css" />
<script src="analytics.js" defer></script>
Проблема: блокирующая таблица стилей и дорогое выполнение скриптов могут задерживать отображение или обработку ввода. defer меняет порядок выполнения, но не устраняет его стоимость. В примере таблица применяется к экрану; один media="print" оставил бы экран без этих стилей. Возможные исправления:
- Встраивайте только действительно критический CSS, проверив эффект.
- Удаляйте стили после проверки динамических классов и состояний интерфейса; PurgeCSS требует подходящей настройки.
- Откладывайте некритичные скрипты и сокращайте стоимость их выполнения.
3. Медленные анимации
Пример:
@keyframes fade {
from {
opacity: 0;
transform: translateX(-100px);
}
to {
opacity: 1;
transform: translateX(0);
}
}
Проблема: Анимация на opacity и transform обычно быстрая, но при большом количестве элементов она может «проседать».
Решение:
- Упростите анимацию и уменьшите число одновременно анимируемых элементов.
- При необходимости применяйте
will-change: transformнезадолго до изменения. Это подсказка браузеру, а не гарантия GPU-ускорения; избыток таких подсказок расходует ресурсы. Измеряйте результат.
4. Повторный принудительный расчёт макета (layout thrashing)
Пример:
for (let i = 0; i < 100; i++) {
element.style.height = `${i}px`
console.log(element.offsetHeight) // Принудительный пересчёт макета
}
Проблема: чередование записи стилей и чтения геометрии, например offsetHeight, может вызывать повторные расчёты макета. Расчёт макета и отрисовка — разные операции. Решение:
- По возможности группируйте чтения геометрии до записей.
- Планируйте визуальные изменения через
requestAnimationFrame, когда это уместно. Сам перенос того же цикла чтения и записи в этот callback проблему не устраняет.
Как улучшить INP: 5 практических рекомендаций
1. Оптимизируйте обработку событий
- Разбивайте длинные задачи и отдавайте браузеру управление между частями через подходящий механизм планирования, например
setTimeout. queueMicrotaskне создаёт возможности для отрисовки: цепочка микрозадач может продолжать блокировать страницу.- Оставляйте в обработчике только необходимую немедленную работу и показывайте быстрый отклик.
2. Уменьшите размер JavaScript
- Удалите неиспользуемые библиотеки (например, через Webpack Bundle Analyzer).
- Применяйте code splitting для динамической загрузки модулей.
3. Используйте Debouncing и Throttling
Для поиска при вводе и частых событий применяйте debounce или throttle, если это допускает задача. В примере функция debounce должна быть определена или импортирована. Само поле должно отвечать сразу; 300 мс — учебный выбор задержки запроса, а не целевое значение INP:
const debouncedSearch = debounce((query) => {
fetchResults(query)
}, 300)
4. Оптимизируйте рендеринг
- Уменьшайте ненужную сложность DOM.
- Измеряйте стоимость стилей и макета, а не считайте сложность селекторов причиной заранее.
- Для разделов вне экрана рассмотрите
content-visibility: auto, проверив макет, фокус и доступность.
5. Тестируйте на слабых устройствах
По возможности проверяйте характерные слабые устройства. В инструментах разработчика можно эмулировать замедление CPU и сети, например замедление CPU в четыре раза и ограниченное мобильное соединение. Это пример лабораторных условий, а не утверждение о фиксированном профиле 3G в сервисе или проверке физических устройств.
Повторите взаимодействие после публикации исправления в сопоставимых условиях. Проверьте время отклика и правильность результата: ускоренная корзина должна по-прежнему содержать нужный товар.
Используйте INP Scanner Milten как часть этого исследования:
- Зафиксируйте проверенные действия и пробелы в данных.
- Сравните воспроизводимый сценарий до и после исправления.
- Для оценки реальных посещений используйте соответствующие измерения: хороший лабораторный результат не доказывает хороший INP у всех пользователей.
Выберите одно важное медленное взаимодействие, определите возможную причину и проверьте ограниченную правку. Разделяйте успешные, упавшие и невыполненные проверки.
Подробнее о метрике — в руководстве по измерению INP и рекомендациях по оптимизации INP.