Узнайте, как оптимизировать взаимодействие с сайтом для отображения следующего шага.
Опубликовано: 19 мая 2023 г., Последнее обновление: 2 сентября 2025 г.
Показатель Interaction to Next Paint (INP) — это стабильная метрика Core Web Vital, которая оценивает общую отзывчивость страницы к действиям пользователя, наблюдая за задержкой всех соответствующих взаимодействий , происходящих на протяжении всего времени посещения пользователем страницы. Итоговое значение INP — это самое длительное наблюдаемое взаимодействие (иногда без учета выбросов).
Для обеспечения хорошего пользовательского опыта веб-сайты должны стремиться к тому, чтобы время от взаимодействия до следующей отрисовки составляло 200 миллисекунд или меньше . Для достижения этой цели для большинства пользователей хорошим порогом для измерения является 75-й процентиль времени загрузки страницы , сегментированный по мобильным и настольным устройствам.
В зависимости от веб-сайта, интерактивность может быть минимальной или отсутствовать вовсе — например, страницы, состоящие в основном из текста и изображений с минимальным количеством интерактивных элементов или вовсе без них. Или, в случае таких сайтов, как текстовые редакторы или игры, интерактивность может достигать сотен — даже тысяч. В любом случае, при высоком показателе INP (Inspection Point — количество взаимодействий с пользователем) качество пользовательского опыта находится под угрозой.
Улучшение 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, которые могут вызывать проблему с производительностью компоновки .
Проблема "перегрузки компоновки" (Layout Thrashing) является узким местом в производительности, поскольку обновление стилей и последующий немедленный запрос значений этих стилей в JavaScript вынуждают браузер выполнять синхронную компоновку, которую в противном случае можно было бы отложить до асинхронного выполнения позже, после завершения обработки событий.
Сведите к минимуму задержку презентации.
Задержка отображения меток взаимодействия охватывает период от завершения выполнения обработчиков событий взаимодействия до момента, когда браузер может отобразить следующий кадр, показывающий результирующие визуальные изменения.
Минимизировать размер DOM
Когда DOM-дерево страницы небольшое, отрисовка обычно завершается быстро. Однако, когда DOM-дерево становится очень большим, объем работы по отрисовке, как правило, увеличивается с ростом размера DOM-дерева. Зависимость между объемом работы по отрисовке и размером DOM-дерева не является линейной, но большие DOM-деревья требуют больше работы для отрисовки, чем маленькие. Большой DOM-дерево создает проблемы в двух случаях:
- На этапе первоначальной отрисовки страницы, когда большой DOM-элемент требует значительных усилий для отображения начального состояния страницы.
- В ответ на взаимодействие с пользователем, когда большой DOM-элемент может привести к тому, что обновления рендеринга станут очень затратными, и, следовательно, увеличат время, необходимое браузеру для отображения следующего кадра.
Следует помнить, что существуют случаи, когда большие DOM-деревья невозможно значительно уменьшить. Хотя есть подходы, которые можно использовать для уменьшения размера DOM, например, сглаживание DOM-дерева или добавление элементов в DOM во время взаимодействия с пользователем , чтобы сохранить первоначальный размер DOM небольшим, эти методы могут быть неэффективными.
Используйте content-visibility для отложенной отрисовки элементов, находящихся за пределами экрана.
Один из способов ограничить объем работы по рендерингу как во время загрузки страницы, так и в ответ на действия пользователя — использовать свойство CSS content-visibility , которое фактически означает отложенный рендеринг элементов по мере их приближения к области видимости. Хотя эффективное использование content-visibility может потребовать некоторой практики, стоит изучить, приводит ли это к сокращению времени рендеринга и, следовательно, может улучшить показатель INP вашей страницы.
Учитывайте снижение производительности при рендеринге HTML с помощью JavaScript.
Там, где есть HTML, есть и его парсинг, и после того, как браузер завершит парсинг HTML в DOM, он должен применить к нему стили, выполнить вычисления компоновки и, наконец, отобразить эту компоновку. Это неизбежные затраты, но то, как вы осуществляете отрисовку HTML, имеет значение.
Когда сервер отправляет HTML-код, он поступает в браузер в виде потока. Потоковая передача означает, что HTML-ответ от сервера поступает по частям. Браузер оптимизирует обработку потока, постепенно анализируя по частям этот поток по мере их поступления и отображая их побитово. Это оптимизация производительности, поскольку браузер периодически и автоматически передает управление во время загрузки страницы, и вы получаете это бесплатно.
Хотя первое посещение любого веб-сайта всегда включает в себя некоторое количество HTML-кода, распространенный подход начинается с минимального начального фрагмента HTML, а затем JavaScript используется для заполнения области контента. Последующие обновления этой области контента также происходят в результате взаимодействия пользователя. Обычно это называется моделью одностраничного приложения (SPA) . Одним из недостатков этой модели является то, что, отображая HTML с помощью JavaScript на стороне клиента, вы не только несете затраты на обработку JavaScript для создания этого HTML, но и браузер не будет освобождать место, пока не завершит анализ и отображение этого HTML.
Однако важно помнить, что даже веб-сайты, не являющиеся одностраничными приложениями (SPA), вероятно, будут включать в себя некоторое количество рендеринга HTML с помощью JavaScript в результате взаимодействия с пользователем. В целом это нормально, если вы не рендерите большие объемы HTML на стороне клиента, что может задерживать отображение следующего кадра. Тем не менее, важно понимать влияние такого подхода к рендерингу HTML в браузере на производительность и то, как он может повлиять на отзывчивость вашего веб-сайта к пользовательскому вводу, если вы рендерите много HTML с помощью JavaScript.
Заключение
Улучшение показателя INP вашего сайта — это итеративный процесс. Когда вы устраняете медленную интерактивность в процессе работы, велика вероятность, что — особенно если ваш сайт предоставляет много интерактивных возможностей — вы начнете обнаруживать и другие медленные взаимодействия, и вам также потребуется оптимизировать их.
Ключ к улучшению INP — это настойчивость. Со временем вы сможете добиться такой адаптивности страницы, чтобы пользователи были довольны предоставляемым вами опытом. Велика вероятность, что по мере разработки новых функций для пользователей вам также потребуется пройти тот же процесс оптимизации взаимодействия, специфичного для них. Это потребует времени и усилий, но это время и усилия будут потрачены с пользой.
Главное изображение взято с Unsplash , автор — Дэвид Писной , изменено в соответствии с лицензией Unsplash .