Диагностика медленных взаимодействий вручную в лаборатории

Узнайте, как перенести полевые данные в лабораторию, чтобы воспроизвести и выявить причины медленного взаимодействия с помощью ручного тестирования.

Jeremy Wagner

Сложная часть оптимизации взаимодействия с следующей отрисовкой (INP) — выяснить, что является причиной плохого INP. Существует множество потенциальных причин, таких как сторонние сценарии, которые планируют множество задач в основном потоке, большие размеры DOM , дорогостоящие обратные вызовы событий и другие причины.

Улучшение INP может быть трудным. Для начала вам нужно знать, какие взаимодействия обычно отвечают за INP страницы. Если вы не знаете, какие взаимодействия на вашем веб-сайте, как правило, самые медленные с точки зрения реального пользователя, прочтите статью « Найдите медленные взаимодействия в полевых условиях» . Если у вас есть полевые данные, которые помогут вам, вы можете протестировать эти конкретные взаимодействия вручную с помощью лабораторных инструментов, чтобы выяснить, почему эти взаимодействия происходят медленно.

Что делать, если у вас нет данных о полях?

Наличие полевых данных жизненно важно, поскольку они экономят много времени, пытаясь выяснить, какие взаимодействия необходимо оптимизировать. Однако вы можете оказаться в ситуации, когда у вас нет данных о полях. Если это описывает вашу ситуацию, все равно можно найти взаимодействия, которые можно улучшить, хотя это требует немного больше усилий и другого подхода.

Общее время блокировки (TBT) — это лабораторный показатель, который оценивает реакцию страницы во время загрузки и хорошо коррелирует с INP . Если на вашей странице высокий показатель TBT, это потенциальный сигнал о том, что ваша страница может не очень реагировать на действия пользователя при ее загрузке.

Чтобы выяснить TBT вашей страницы, вы можете использовать Lighthouse . Если TBT страницы высокий, существует вероятность того, что основной поток слишком занят во время загрузки страницы, и это может повлиять на скорость реагирования страницы в этот решающий момент ее жизненного цикла.

Чтобы обнаружить медленные взаимодействия после загрузки страницы, вам могут потребоваться другие типы данных, например общие потоки пользователей, которые вы, возможно, уже определили в аналитике вашего веб-сайта. Например, если вы работаете на веб-сайте электронной коммерции, обычным пользовательским потоком будут действия, которые они выполняют, когда добавляют товары в онлайн-корзину и оформляют заказ.

Независимо от того, есть ли у вас полевые данные или нет, следующим шагом будет вручную протестировать и воспроизвести медленное взаимодействие, потому что только тогда, когда вы сможете воспроизвести медленное взаимодействие, вы сможете его исправить.

Воспроизводите медленные взаимодействия в лаборатории

Существует несколько способов воспроизвести медленное взаимодействие в лаборатории с помощью ручного тестирования, но вы можете попробовать следующую структуру.

Записать след

Профилировщик производительности Chrome — рекомендуемый инструмент для диагностики и устранения неполадок медленного взаимодействия. Чтобы профилировать взаимодействие в профилировщике производительности Chrome, выполните следующие действия:

1. Откройте страницу, которую хотите протестировать.
2. Откройте Chrome DevTools и перейдите на панель «Производительность» .
3. Нажмите кнопку «Запись» в левом верхнем углу панели, чтобы начать трассировку.
4. Выполните действия, которые вы хотите устранить.
5. Нажмите кнопку «Запись» еще раз, чтобы остановить отслеживание.

Когда профилировщик заполнится, в первую очередь следует просмотреть сводку действий в верхней части профилировщика. В сводке активности вверху отображаются красные полосы там, где в записи произошли длительные задачи. Это позволяет быстро увеличить проблемные области.

Вы можете быстро сосредоточиться на проблемных областях, перетащив и выбрав область в сводке действий. При желании вы можете использовать функцию «хлебные крошки» в профилировщике, чтобы сузить временную шкалу и игнорировать несвязанные действия.

После того как вы сосредоточились на том, где произошло взаимодействие, дорожка «Взаимодействия» поможет вам выровнять взаимодействие и действие, произошедшее на дорожке основного потока под ней:

Вы можете получить дополнительную информацию о том, какая часть взаимодействия была самой продолжительной, наведя указатель мыши на итерацию на дорожке взаимодействий:

Полосатая часть взаимодействия показывает, сколько времени взаимодействие превысило 200 миллисекунд, что является верхним пределом «хорошего» порога для INP страницы. Перечисленные части взаимодействия:

1. Входная задержка — отображается левым усом.
2. Продолжительность обработки — отображается сплошным блоком между левым и правым усами.
3. Задержка презентации — визуализируется правым усом.

Отсюда следует углубиться в проблему(ы), вызывающую медленное взаимодействие, которая рассматривается далее в этом руководстве.

Расширение Chrome Web Vitals

Профилировщик производительности — это рекомендуемый подход к диагностике заведомо медленных взаимодействий, но выявление медленных взаимодействий может занять некоторое время, если вы не знаете, какие взаимодействия являются для вас проблемными. Один из подходов, который следует рассмотреть, — использовать расширение Chrome Web Vitals . Это расширение можно использовать для быстрой проверки ряда взаимодействий и поиска проблемных, прежде чем переходить к профилировщику производительности.

После установки расширение Web Vitals отображает данные взаимодействия в консоли DevTools, если вы выполните следующие действия:

1. В Chrome щелкните значок расширения справа от адресной строки.
2. Найдите расширение Web Vitals в раскрывающемся меню.
3. Нажмите значок справа, чтобы открыть настройки расширения.
4. Нажмите «Параметры» .
5. Установите флажок «Ведение журнала консоли» на появившемся экране и нажмите « Сохранить» .

Выполнив эти действия, откройте консоль в Chrome DevTools и начните тестирование подозрительных взаимодействий на странице. По мере взаимодействия в консоли будут появляться диагностические данные:

Хотя расширение Web Vitals помогает выявлять медленные взаимодействия и предоставляет некоторые подробности, которые помогут вам отладить INP, вам все равно может потребоваться использовать профилировщик производительности для диагностики медленных взаимодействий , поскольку он предоставляет подробные данные, которые вам понадобятся для навигации по рабочей части вашего веб-сайта. код, чтобы найти причины медленного взаимодействия.

Как определить, какая часть взаимодействия происходит медленно

Взаимодействия состоят из трех частей: задержки ввода, продолжительности обработки и задержки представления. То, как вы оптимизируете взаимодействие для снижения INP страницы, зависит от того, какая его часть занимает больше всего времени.

Как определить длительные задержки ввода

Задержки ввода могут привести к высокой задержке взаимодействия. Задержка ввода — это первая часть взаимодействия. Это период времени с момента, когда действие пользователя впервые получено операционной системой, до момента, когда браузер может начать обработку первого обратного вызова обработчика событий этого взаимодействия.

Определить задержки ввода в профилировщике производительности Chrome можно, найдя взаимодействие на дорожке взаимодействий. Длина левого уса указывает на часть задержки ввода взаимодействия, а точное значение можно найти во всплывающей подсказке, наведя курсор на взаимодействие в профилировщике производительности.

Входные задержки никогда не могут быть равны нулю, но у вас есть некоторый контроль над длительностью входной задержки. Ключевым моментом является выяснить, есть ли работа в основном потоке, которая препятствует выполнению ваших обратных вызовов так быстро, как они должны.

На предыдущем рисунке задача из стороннего скрипта выполняется, когда пользователь пытается взаимодействовать со страницей, и, следовательно, увеличивает задержку ввода. Расширенная задержка ввода влияет на задержку взаимодействия и, следовательно, может повлиять на INP страницы.

Как определить длительную продолжительность обработки

Обратные вызовы событий запускаются сразу после задержки ввода, и время, необходимое для их завершения, называется длительностью обработки . Если обратные вызовы событий выполняются слишком долго, они задерживают представление браузером следующего кадра и могут значительно увеличить общую задержку взаимодействия. Длительная длительность обработки может быть результатом дорогостоящего использования собственного или стороннего JavaScript, а в некоторых случаях и того, и другого. В профилировщике производительности это представлено сплошной частью взаимодействия на дорожке взаимодействий.

Обнаружение дорогостоящих обратных вызовов событий можно выполнить, наблюдая за следующим в трассировке конкретного взаимодействия:

1. Определите, является ли задача, связанная с обратными вызовами событий , длинной задачей . Чтобы более надежно отображать длинные задачи в лабораторных условиях, вам может потребоваться включить регулирование ЦП на панели производительности или подключить Android-устройство низкого или среднего уровня и использовать удаленную отладку .
2. Если задача, запускающая обратные вызовы событий, является длинной задачей, найдите записи обработчика событий — например, записи с такими именами, как «Событие: щелчок» , — в стеке вызовов, которые имеют красный треугольник в правом верхнем углу записи.

Вы можете попробовать одну из следующих стратегий, чтобы сократить продолжительность обработки взаимодействия:

1. Делайте как можно меньше работы. Все ли, что происходит при дорогостоящем обратном вызове события, строго необходимо? Если нет, рассмотрите возможность полного удаления этого кода, если это возможно, или отложите его выполнение на более поздний момент, если вы не можете. Вы также можете воспользоваться функциями платформы. Например, функция запоминания React может пропустить ненужную работу по рендерингу компонента, если его реквизиты не изменились.
2. Отложите работу, не связанную с рендерингом, в обратном вызове события на более поздний момент времени. Длинные задачи можно разбить, передав их основному потоку . Всякий раз, когда вы уступаете основному потоку, вы завершаете выполнение текущей задачи и разбиваете оставшуюся часть работы на отдельную задачу. Это дает средству визуализации возможность обрабатывать обновления пользовательского интерфейса, которые были выполнены ранее в обратном вызове события. Если вы используете React, его функция переходов может сделать это за вас.

Эти стратегии должны помочь вам оптимизировать обратные вызовы событий, чтобы их запуск занимал меньше времени.

Как определить задержки презентации

Длительные задержки ввода и длительность обработки — не единственные причины плохого INP. Иногда обновления рендеринга, которые происходят в ответ даже на небольшие объемы кода обратного вызова событий, могут быть дорогостоящими. Время, необходимое браузеру для отображения визуальных обновлений пользовательского интерфейса, отражающих результат взаимодействия, называется задержкой представления .

Работа по рендерингу чаще всего состоит из таких задач, как пересчет стиля, компоновка, покраска и компоновка, и представлена ​​фиолетовыми и зелеными блоками на диаграмме пламени профилировщика. Общая задержка представления представлена ​​правым усом взаимодействия на дорожке взаимодействий.

Из всех возможных причин высокой задержки взаимодействия задержки презентации сложнее всего устранить и устранить. Чрезмерная работа по рендерингу может быть вызвана любой из следующих причин:

• Большие размеры DOM. Работа по рендерингу, необходимая для обновления представления страницы, часто увеличивается вместе с размером DOM страницы. Дополнительные сведения см. в статье «Как большие размеры DOM влияют на интерактивность и что с этим можно сделать» .
• Принудительная перекомпоновка. Это происходит, когда вы применяете изменения стиля к элементам в JavaScript, а затем немедленно запрашиваете результаты этой работы. В результате браузер должен выполнить работу по макету, прежде чем делать что-либо еще, чтобы браузер мог вернуть обновленные стили. Дополнительные сведения и советы о том, как избежать принудительного перекомпонования, см. в статье «Избегайте больших, сложных макетов и их искажений» .
• Чрезмерная или ненужная работа в обратных вызовах requestAnimationFrame . Обратные вызовы requestAnimationFrame() запускаются на этапе рендеринга цикла событий и должны завершиться, прежде чем можно будет представить следующий кадр. Если вы используете requestAnimationFrame() для выполнения работы, не связанной с изменением пользовательского интерфейса, помните, что вы можете задержать следующий кадр.
• Обратные вызовы ResizeObserver . Такие обратные вызовы выполняются до рендеринга и могут задержать представление следующего кадра, если работа над ними дорогая. Как и в случае с обратными вызовами событий, отложите любую ненужную логику для следующего кадра.

Что делать, если вы не можете воспроизвести медленное взаимодействие?

Что, если ваши полевые данные показывают, что конкретное взаимодействие происходит медленно, но вы не можете вручную воспроизвести проблему в лаборатории? Есть несколько причин, почему это может быть так.

Во-первых, ваши обстоятельства при тестировании взаимодействия зависят от вашего оборудования и сетевого подключения. Вы можете использовать быстрое устройство с быстрым соединением, но это не значит, что ваши пользователи тоже. Вы можете попробовать одну из трех вещей, если это применимо к вам:

1. Если у вас есть физическое устройство Android, используйте удаленную отладку , чтобы открыть экземпляр Chrome DevTools на вашем хост-компьютере и попытаться воспроизвести там медленное взаимодействие. Мобильные устройства зачастую не так быстры, как ноутбуки или настольные компьютеры, поэтому на этих устройствах легче наблюдать медленное взаимодействие.
2. Если у вас нет физического устройства, включите функцию регулирования ЦП в Chrome DevTools .

Другая причина может заключаться в том, что вы ждете загрузки страницы, прежде чем взаимодействовать с ней, а ваши пользователи этого не делают. Если вы используете быструю сеть, смоделируйте более медленную сеть, включив регулирование сети , а затем взаимодействуйте со страницей, как только она отобразится. Это следует сделать, поскольку основной поток часто бывает наиболее загружен во время запуска, и тестирование в этот период времени может выявить, что испытывают ваши пользователи.

Устранение неполадок INP — это итеративный процесс.

Выяснение того, что вызывает высокую задержку взаимодействия, которая способствует плохому INP, требует большой работы, но если вы сможете точно определить причины, вы уже на полпути. Следуя методическому подходу к устранению неполадок INP, вы сможете точно определить причину проблемы и быстрее найти правильное решение. Чтобы просмотреть:

• Полагайтесь на полевые данные, чтобы обнаружить медленные взаимодействия .
• Вручную проверьте проблемные взаимодействия полей в лаборатории, чтобы убедиться, что они воспроизводимы.
• Определите, связана ли причина с длительной задержкой ввода, дорогостоящими обратными вызовами событий или дорогостоящими работами по рендерингу.
• Повторить.

Последнее из них является самым важным. Как и большинство других работ, которые вы выполняете для улучшения производительности страниц, устранение неполадок и улучшение INP — это циклический процесс. Когда вы исправите одно медленное взаимодействие, переходите к следующему и повторяйте, пока не начнете видеть результаты.