Допустим, у нас уже есть сбор метрик. И на основе них мы понимаем, что есть проблемы с INP.
Как понять, что является триггером большого INP?
Можно подебажить локально.
Что учитывает INP?
INP учитывает три вида интеракций:
- клик мышкой;
- тап на тач-устройствах;
- нажатие клавиши на клавиатуре.
Ищем проблемные места
Можно составить список всех элементов на странице, с которыми пользователь может взаимодействовать через эти интеракции.
Далее открываем DevTools, вкладка Performance. Выставляем троттлинг CPU, чтобы сэмулировать слабое устройство. И начинаем совершать интеракции с нужными нам элементами. После каждой интеракции браузер выведет interaction latency и подсветит, если оно является INP (самое большое interaction latency).
Ок. Проблемные места нашли.
Осталось понять, что с ними не так.
DevTools -> Performance
Тут нужно будет погрузиться во вкладку Performance чуть глубже.
Запускаем запись профайла. Совершаем самую проблемную интеракцию, которую мы нашли на предыдущем этапе. Останавливаем запись профайла. Открываем панель Insights. Выбираем INP by phase. DevTools на таймлайне подсветят границы INP и его составные части.
На основе размера составных частей можно понять, какой этап является самым проблемным:
- input delay — задержка до начала обработки;
- processing duration — время исполнения обработчиков;
- presentation delay — задержка до отрисовки результата.
Далее анализируем график таймлайна, находим блок с самой широкой функцией (чем шире, тем дольше исполняется). Думаем, почему оно медленное. Исправляем.
Больше инфы про оптимизацию INP можно найти в статье и в видео от Google.