Узнайте, как оптимизировать взаимодействие вашего веб-сайта с Next Paint.
Опубликовано: 19 мая 2023 г., Последнее обновление: 3 июня 2025 г.
Interaction to Next Paint (INP) — это стабильная метрика Core Web Vital, которая оценивает общую отзывчивость страницы на взаимодействие с пользователем, отслеживая задержку всех квалификационных взаимодействий , которые происходят на протяжении всего времени посещения страницы пользователем. Конечное значение INP — это самое продолжительное наблюдаемое взаимодействие (иногда без учета выбросов).
Чтобы обеспечить хороший пользовательский опыт, веб-сайты должны стремиться к Interaction to Next Paint в 200 миллисекунд или меньше . Чтобы достичь этой цели для большинства ваших пользователей, хорошим порогом для измерения является 75-й процентиль загрузок страниц , сегментированных по мобильным и настольным устройствам.
В зависимости от веб-сайта, может быть мало или вообще не быть взаимодействий — например, страницы, состоящие в основном из текста и изображений с малым количеством или вообще без интерактивных элементов. Или, в случае таких веб-сайтов, как текстовые редакторы или игры, могут быть сотни — даже тысячи — взаимодействий. В любом случае, если есть высокий INP, пользовательский опыт находится под угрозой.
Для улучшения INP требуются время и усилия, но наградой является лучший пользовательский опыт. В этом руководстве будет рассмотрен путь к улучшению INP.
Выясните, что является причиной низкого INP
Прежде чем вы сможете исправить медленное взаимодействие, вам понадобятся данные, чтобы узнать, является ли INP вашего веб-сайта плохим или нуждается в улучшении. Как только у вас будет эта информация, вы сможете перейти в лабораторию, чтобы начать диагностику медленного взаимодействия и двигаться к решению.
Найдите медленные взаимодействия в поле
В идеале ваш путь к оптимизации INP начнется с полевых данных . В лучшем случае полевые данные от поставщика Real User Monitoring (RUM) предоставят вам не только значение INP страницы, но и контекстные данные, которые показывают, какое конкретное взаимодействие было ответственно за само значение INP, произошло ли взаимодействие во время или после загрузки страницы, тип взаимодействия (щелчок, нажатие клавиши или касание) и другую ценную информацию.
Если вы не полагаетесь на поставщика RUM для получения полевых данных, руководство по полевым данным INP рекомендует использовать PageSpeed Insights для просмотра данных отчета Chrome User Experience Report (CrUX), чтобы помочь заполнить пробелы. CrUX — это официальный набор данных программы Core Web Vitals, который предоставляет высокоуровневую сводку показателей для миллионов веб-сайтов, включая INP. Однако CrUX часто не предоставляет контекстные данные, которые вы получили бы от поставщика RUM, чтобы помочь вам проанализировать проблемы. По этой причине мы по-прежнему рекомендуем сайтам использовать поставщика RUM, когда это возможно, или внедрять собственное решение RUM для дополнения того, что доступно в CrUX.
Диагностируйте медленные взаимодействия в лаборатории
В идеале вам следует начать тестирование в лаборатории, как только у вас появятся полевые данные, которые предполагают, что у вас медленные взаимодействия. При отсутствии полевых данных существуют некоторые стратегии для выявления медленных взаимодействий в лаборатории. Такие стратегии включают в себя следование общим потокам пользователей и тестирование взаимодействий по пути, а также взаимодействие со страницей во время загрузки — когда основной поток часто наиболее загружен — для выявления медленных взаимодействий во время этой важной части пользовательского опыта.
Оптимизируйте взаимодействие
После того, как вы определили медленное взаимодействие и можете вручную воспроизвести его в лаборатории , следующим шагом будет его оптимизация. Взаимодействия можно разбить на три подчасти:
- Задержка ввода , которая начинается, когда пользователь инициирует взаимодействие со страницей, и заканчивается, когда начинают выполняться обратные вызовы событий для взаимодействия.
- Длительность обработки , которая состоит из времени, необходимого для завершения обратных вызовов событий.
- Задержка представления — это время, необходимое браузеру для представления следующего кадра, содержащего визуальный результат взаимодействия.
Сумма этих трех подчастей — это общая задержка взаимодействия. Каждая отдельная подчасть взаимодействия вносит определенный вклад в общую задержку взаимодействия, поэтому важно знать, как можно оптимизировать каждую часть взаимодействия, чтобы оно выполнялось как можно меньше времени.
Определить и уменьшить задержку ввода
Когда пользователь взаимодействует со страницей, первой частью этого взаимодействия является задержка ввода . В зависимости от другой активности на странице задержки ввода могут быть значительными по продолжительности. Это может быть связано с активностью, происходящей в основном потоке (возможно, из-за загрузки скриптов, разбора и компиляции), обработкой выборки, функциями таймера или даже с другими взаимодействиями, которые происходят в быстрой последовательности и перекрывают друг друга.
Независимо от источника задержки ввода при взаимодействии, вам следует свести задержку ввода к минимуму, чтобы взаимодействия могли начать выполнять обратные вызовы событий как можно скорее.
Связь между оценкой скрипта и длительными задачами при запуске
Критический аспект интерактивности в жизненном цикле страницы — это запуск. По мере загрузки страницы она сначала отображается, но важно помнить, что даже если страница отображается , это не означает, что ее загрузка завершена. В зависимости от того, сколько ресурсов требуется странице для полной функциональности, пользователи могут попытаться взаимодействовать со страницей, пока она еще загружается.
Одна из вещей, которая может увеличить задержку ввода взаимодействия при загрузке страницы, — это оценка скрипта. После того, как файл JavaScript был извлечен из сети, браузеру еще предстоит выполнить работу, прежде чем этот JavaScript сможет запуститься; эта работа включает в себя разбор скрипта для проверки его синтаксиса на допустимость, компиляцию его в байт-код и, наконец, его выполнение.
В зависимости от размера скрипта эта работа может вводить длительные задачи в основной поток, что задержит реакцию браузера на другие взаимодействия пользователя. Чтобы ваша страница оставалась отзывчивой на ввод пользователя во время загрузки страницы, важно понимать, что вы можете сделать, чтобы снизить вероятность длительных задач во время загрузки страницы, чтобы страница оставалась быстрой.
Оптимизируйте обратные вызовы событий
Задержка ввода — это только первая часть того, что измеряет INP. Вам также нужно будет убедиться, что обратные вызовы событий, которые запускаются в ответ на взаимодействие с пользователем, могут завершаться как можно быстрее.
Чаще возвращайтесь к основной теме
Лучший общий совет по оптимизации обратных вызовов событий — делать в них как можно меньше работы. Однако логика вашего взаимодействия может быть сложной, и вы можете лишь незначительно сократить объем работы, которую они выполняют.
Если вы обнаружили, что это относится к вашему веб-сайту, следующее, что вы можете попробовать, — разбить работу в обратных вызовах событий на отдельные задачи. Это предотвращает превращение коллективной работы в длинную задачу, которая блокирует основной поток, что позволяет другим взаимодействиям, которые в противном случае ожидали бы в основном потоке, выполняться раньше.
setTimeout — один из способов разбить задачи, поскольку переданный ему обратный вызов выполняется в новой задаче. Вы можете использовать setTimeout сам по себе или абстрагировать его использование в отдельную функцию для более эргономичного yielding .
Уступать управление без разбора лучше, чем не уступать вообще. Однако существует более тонкий способ уступать управление основному потоку, который подразумевает уступать управление только сразу после обратного вызова события, обновляющего пользовательский интерфейс, чтобы логика рендеринга могла быть запущена раньше.
Выход, позволяющий быстрее приступить к рендерингу
Более продвинутая техника yielding подразумевает структурирование кода в обратных вызовах событий, чтобы ограничить то, что запускается, только логикой, необходимой для применения визуальных обновлений для следующего кадра. Все остальное можно отложить до последующей задачи. Это не только делает обратные вызовы легкими и гибкими, но и улучшает время рендеринга для взаимодействий, не позволяя визуальным обновлениям блокировать код обратного вызова событий.
Например, представьте себе текстовый редактор с расширенным набором данных, который форматирует текст по мере ввода, но также обновляет другие аспекты пользовательского интерфейса в ответ на то, что вы написали (например, количество слов, выделение орфографических ошибок и другая важная визуальная обратная связь). Кроме того, приложению может также потребоваться сохранять то, что вы написали, чтобы, если вы выйдете и вернетесь, вы не потеряли свою работу.
В этом примере следующие четыре действия должны произойти в ответ на символы, набранные пользователем. Однако только первый элемент должен быть выполнен до того, как будет представлен следующий кадр.
- Обновите текстовое поле, указав введенную пользователем информацию, и примените необходимое форматирование.
- Обновите часть пользовательского интерфейса, отображающую текущее количество слов.
- Запустите логику, чтобы проверить наличие орфографических ошибок.
- Сохраните последние изменения (локально или в удаленной базе данных).
Код для этого может выглядеть примерно так:
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 или добавление к DOM во время взаимодействия с пользователем, чтобы сохранить небольшой начальный размер DOM, эти методы могут дать лишь ограниченный эффект.
Используйте content-visibility для ленивой отрисовки элементов, находящихся за пределами экрана
Один из способов ограничить объем как рендеринга во время загрузки страницы, так и рендеринга в ответ на взаимодействие с пользователем — это положиться на свойство CSS content-visibility , которое фактически сводится к ленивому рендерингу элементов по мере их приближения к окну просмотра. Хотя для эффективного использования content-visibility может потребоваться некоторая практика, стоит изучить, является ли результатом сокращение времени рендеринга, что может улучшить INP вашей страницы.
Помните о потерях производительности при рендеринге HTML с использованием JavaScript
Где есть HTML, там есть парсинг 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 .