Узнайте, как оптимизировать показатель Interaction to Next Paint для своего сайта.
Дата публикации: 19 мая 2023 г. Последнее обновление: 2 сентября 2025 г.
Interaction to Next Paint (INP) – это стабильный показатель Core Web Vitals, который позволяет оценить, насколько быстро страница реагирует на действия пользователя в целом. Для этого измеряется задержка всех подходящих взаимодействий, которые пользователь выполняет, когда находится на странице. Итоговое значение INP представляет собой минимальную скорость отклика (иногда без учета выбросов).
Чтобы сайтом было удобно пользоваться, значение Interaction to Next Paint должно составлять не более 200 мс. Чтобы целевой результат достигался для большинства посетителей, используйте пороговое значение 75-го процентиля загрузок страниц, сегментированных по мобильным устройствам и настольным компьютерам.
На некоторых сайтах, например на страницах, где в основном представлены текст и изображения, взаимодействий может быть мало или не быть вообще. А на сайтах с текстовыми редакторами или играми взаимодействий могут быть сотни и даже тысячи. В любом случае высокий показатель INP означает, что у пользователей могут возникнуть проблемы.
Улучшение показателя INP требует времени и усилий, но в результате вы сможете повысить удобство сайта для пользователей. В этом руководстве мы расскажем, как улучшить INP.
Как выяснить, что вызывает низкое значение INP
Прежде чем исправлять медленные взаимодействия, вам понадобятся данные, которые покажут, является ли INP вашего сайта низким или требует улучшения. Получив эту информацию, вы можете перейти в лабораторию, чтобы начать диагностику медленных взаимодействий и найти решение.
Как найти медленные взаимодействия в полевых условиях
В идеале оптимизацию INP следует начинать с данных наблюдений. В идеале полевые данные от поставщика RUM должны содержать не только значение INP страницы, но и контекстные данные, которые указывают, какое именно взаимодействие отвечало за само значение INP, произошло ли взаимодействие во время или после загрузки страницы, тип взаимодействия (клик, нажатие клавиши или касание) и другую ценную информацию.
Если вы не используете поставщика RUM для получения полевых данных, в руководстве по полевым данным INP рекомендуется использовать PageSpeed Insights для просмотра данных Chrome User Experience Report (CrUX), чтобы заполнить пробелы. CrUX – это набор данных Google, который используется в программе Core Web Vitals и содержит сводную информацию о показателях миллионов сайтов, включая INP. Однако в CrUX часто нет контекстных данных, которые можно получить от поставщика RUM и которые помогают анализировать проблемы. Поэтому мы рекомендуем владельцам сайтов по возможности пользоваться услугами поставщиков RUM или внедрять собственные решения RUM, чтобы дополнять данные, доступные в CrUX.
Как диагностировать медленные взаимодействия в лаборатории
В идеале, вы должны начать тестирование в лаборатории, как только у вас появятся полевые данные, указывающие на медленные взаимодействия. При отсутствии полевых данных существуют некоторые стратегии выявления медленных взаимодействий в лаборатории. Например, можно следовать распространенным путям пользователей и тестировать взаимодействия на них, а также взаимодействовать со страницей во время загрузки, когда основной поток часто наиболее загружен. Это поможет выявить медленные взаимодействия на важном этапе работы пользователя.
Оптимизация взаимодействий
После того как вы определили медленное взаимодействие и можете вручную воспроизвести его в лаборатории, следующим шагом будет его оптимизация.
Взаимодействия можно разделить на три подчасти:
- Задержка ввода – время между началом взаимодействия пользователя со страницей и запуском обратных вызовов событий для этого взаимодействия.
- Продолжительность обработки – время, необходимое для выполнения обратных вызовов событий.
- Задержка показа – время, которое требуется браузеру, чтобы показать следующий кадр с визуальным результатом взаимодействия.
Сумма этих трех частей и составляет общую задержку взаимодействия. Каждая отдельная подчасть взаимодействия вносит определенное количество времени в общую задержку взаимодействия, поэтому важно знать, как можно оптимизировать каждую часть взаимодействия, чтобы она выполнялась как можно меньше времени.
Как выявить и уменьшить задержку ввода
Когда пользователь взаимодействует со страницей, первая часть этого взаимодействия – задержка ввода. В зависимости от других действий на странице задержки ввода могут быть значительными. Это может быть связано с действиями в основном потоке (например, загрузкой, синтаксическим анализом и компиляцией скриптов), обработкой запросов, функциями таймера или даже другими взаимодействиями, которые происходят быстро и накладываются друг на друга.
Независимо от источника задержки ввода взаимодействия, вы захотите свести задержку ввода к минимуму, чтобы взаимодействия могли начать выполнять обратные вызовы событий как можно скорее.
Связь между оценкой скриптов и длительными задачами при запуске
Важный аспект интерактивности в жизненном цикле страницы – это запуск. При загрузке страницы сначала выполняется ее отрисовка, но это не означает, что страница загружена полностью. Если для полной загрузки страницы требуется много ресурсов, пользователи могут попытаться взаимодействовать с ней до того, как она будет полностью загружена.
Одной из причин задержки ввода при загрузке страницы может быть выполнение скриптов. После того как файл JavaScript был получен из сети, браузеру все равно нужно выполнить определенную работу, прежде чем этот JavaScript можно будет запустить. Эта работа включает в себя синтаксический анализ скрипта для проверки правильности его синтаксиса, компиляцию его в байт-код и, наконец, его выполнение.
В зависимости от размера скрипта это может привести к длительным задачам в основном потоке, из-за чего браузер будет медленнее реагировать на действия пользователя. Чтобы страница реагировала на действия пользователя во время загрузки страницы, важно понимать, как снизить вероятность длительных задач в этот период, чтобы страница оставалась быстрой.
Оптимизация обратных вызовов событий
Задержка ввода – это только первая часть того, что измеряет INP. Также необходимо убедиться, что обратные вызовы событий, которые выполняются в ответ на взаимодействие с пользователем, могут завершиться как можно быстрее.
Часто передавайте управление основному потоку
Лучший совет по оптимизации обратных вызовов событий – выполнять в них как можно меньше работы. Однако логика взаимодействия может быть сложной, и вы сможете лишь незначительно сократить объем работы, которую они выполняют.
Если это так, попробуйте разбить работу в обратных вызовах событий на отдельные задачи. Это предотвращает превращение коллективной работы в длительную задачу, которая блокирует основной поток, что позволяет быстрее выполнять другие взаимодействия, которые в противном случае ожидали бы запуска основного потока.
setTimeout – один из способов разбивать задачи, поскольку обратный вызов, переданный в него, выполняется в новой задаче. Вы можете использовать setTimeout отдельно или абстрагировать его использование в отдельную функцию для более эргономичного уступки.
Беспорядочная уступка лучше, чем отсутствие уступки вообще, однако существует более тонкий способ уступки основному потоку, который включает в себя уступку только сразу после обратного вызова события, который обновляет пользовательский интерфейс, чтобы логика рендеринга могла работать быстрее.
Уступайте, чтобы ускорить отрисовку
Более продвинутый метод уступки заключается в структурировании кода в обратных вызовах событий, чтобы ограничить то, что запускается, только логикой, необходимой для применения визуальных обновлений для следующего кадра. Все остальное можно отложить до следующей задачи. Это не только делает обратные вызовы легкими и быстрыми, но и сокращает время отрисовки для взаимодействий, не позволяя визуальным обновлениям блокировать код обратного вызова события.
Например, представьте себе редактор форматированного текста, который форматирует текст по мере ввода, а также обновляет другие аспекты пользовательского интерфейса в ответ на то, что вы написали (например, количество слов, выделение орфографических ошибок и другую важную визуальную обратную связь). Кроме того, приложению может потребоваться сохранить написанное вами, чтобы вы не потеряли свою работу, если выйдете и вернетесь.
В этом примере в ответ на ввод символов пользователем должны произойти четыре действия. Однако только первый пункт должен быть выполнен до того, как будет представлен следующий фрейм.
- Обновите текстовое поле, добавив в него введенный пользователем текст, и примените необходимое форматирование.
- Обновите часть пользовательского интерфейса, в которой отображается текущее количество слов.
- Запустите логику, чтобы проверить наличие орфографических ошибок.
- Сохраните последние изменения (локально или в удаленной базе данных).
Код для этого может выглядеть примерно так:
textBox.addEventListener('input', (inputEvent) => {
// Update the UI immediately, so the changes the user made
// are visible as soon as the next frame is presented.
updateTextBox(inputEvent);
// Use `setTimeout` to defer all other work until at least the next
// frame by queuing a task in a `requestAnimationFrame()` callback.
requestAnimationFrame(() => {
setTimeout(() => {
const text = textBox.textContent;
updateWordCount(text);
checkSpelling(text);
saveChanges(text);
}, 0);
});
});
На следующей визуализации показано, как откладывание некритичных обновлений до следующего кадра может сократить время обработки и, следовательно, общую задержку взаимодействия.
Хотя использование setTimeout() внутри вызова requestAnimationFrame() в предыдущем примере кода может показаться немного сложным, это эффективный метод, который работает во всех браузерах и предотвращает блокировку следующего кадра некритичным кодом.
Избегайте перекомпоновки макета
Перекомпоновка макета, также называемая принудительной синхронной компоновкой, – это проблема с производительностью рендеринга, при которой компоновка макета происходит синхронно. Это происходит, когда вы обновляете стили в JavaScript, а затем считываете их в той же задаче. В JavaScript есть много свойств, которые могут вызвать перегрузку макета.
Перекомпоновка макета снижает производительность, поскольку при обновлении стилей и немедленном запросе их значений в JavaScript браузер вынужден выполнять синхронную компоновку макета, которую в противном случае он мог бы отложить и выполнить асинхронно после завершения обратных вызовов событий.
Минимизировать задержку вывода на экран
Задержка показа – это время с момента завершения обратных вызовов событий взаимодействия до момента, когда браузер может отрисовать следующий кадр, показывающий визуальные изменения.
Уменьшите размер DOM-дерева
Если DOM страницы небольшой, отрисовка обычно выполняется быстро. Однако если DOM-дерево очень большое, то и объем работы по отрисовке увеличивается. Связь между объемом работы по отрисовке и размером DOM не является линейной, но для отрисовки больших DOM требуется больше работы, чем для маленьких. Большое дерево DOM может вызывать проблемы в двух случаях:
- При первоначальной отрисовке страницы, когда для отображения ее исходного состояния требуется большой объем работы с DOM.
- При взаимодействии с пользователем, когда из-за большого размера DOM-дерева обновление отрисовки может быть очень ресурсоемким и, следовательно, увеличивать время, необходимое браузеру для представления следующего кадра.
Учтите, что в некоторых случаях значительно уменьшить размер DOM невозможно. Существуют способы уменьшить размер DOM, например сделать DOM плоским или добавлять элементы в DOM во время взаимодействия с пользователем, чтобы сохранить небольшой размер исходного DOM. Однако эти методы могут быть неэффективными.
Используйте content-visibility для отложенной отрисовки элементов за пределами экрана
Один из способов ограничить объем работы по отрисовке как во время загрузки страницы, так и в ответ на действия пользователя – использовать свойство CSS content-visibility, которое фактически сводится к отложенной отрисовке элементов по мере их приближения к области просмотра. Хотя для эффективного использования content-visibility может потребоваться некоторая практика, стоит изучить, приведет ли результат к сокращению времени отрисовки, что может улучшить INP вашей страницы.
Учитывайте, что отрисовка HTML с помощью JavaScript может снизить производительность
После того как браузер завершит синтаксический анализ HTML в DOM, он должен применить к нему стили, выполнить расчеты макета и впоследствии отобразить этот макет. Это неизбежные затраты, но способ отрисовки HTML имеет значение.
Когда сервер отправляет HTML, он поступает в браузер в виде потока. Потоковая передача означает, что HTML-ответ от сервера поступает частями. Браузер оптимизирует обработку потока, постепенно анализируя фрагменты этого потока по мере их поступления и отображая их по частям. Это оптимизация производительности, поскольку браузер неявно периодически и автоматически уступает во время загрузки страницы, и вы получаете это бесплатно.
При первом посещении любого сайта всегда загружается некоторое количество HTML-кода. Обычно сначала загружается минимальный объем HTML-кода, а затем для заполнения области контента используется JavaScript. Последующие обновления этой области контента также происходят в результате действий пользователя. Такая модель называется одностраничным приложением. Один из недостатков этого шаблона заключается в том, что при рендеринге HTML с помощью JavaScript на клиенте вы не только несете затраты на обработку JavaScript для создания этого HTML, но и браузер не уступит, пока не закончит синтаксический анализ этого HTML и его рендеринг.
Однако важно помнить, что даже на сайтах, не являющихся одностраничными приложениями, в результате действий пользователя может выполняться отрисовка HTML-кода с помощью JavaScript. Обычно это не вызывает проблем, если только вы не отрисовываете большие объемы HTML на стороне клиента, что может задерживать показ следующего кадра. Однако важно понимать, как такой подход к отрисовке HTML в браузере влияет на производительность и как он может повлиять на скорость реагирования вашего сайта на действия пользователя, если вы отрисовываете много HTML с помощью JavaScript.
Заключение
Улучшение INP сайта – это итеративный процесс. Когда вы исправите медленное взаимодействие в полевых условиях, скорее всего, вы начнете находить другие медленные взаимодействия, особенно если ваш сайт предоставляет много возможностей для взаимодействия, и вам также потребуется их оптимизировать.
Ключ к улучшению INP – настойчивость. Со временем вы сможете улучшить отзывчивость страницы, чтобы пользователи были довольны. По мере разработки новых функций для пользователей вам, скорее всего, придется пройти через тот же процесс оптимизации взаимодействий, характерных для этих функций. Это потребует времени и усилий, но они окупятся.